Я тоже не очень разбираюсь в этом, хотя я сам немного пытался использовать pthread
.
Чтобы продемонстрировать мое понимание затрат времени, давайте возьмем пример простой однопоточной программы для вычисления суммы массива:
for(i=0;i<NUM;i++) {
sum += array[i];
}
В простой [разумно выполненной] многопоточной версии этого кода массив может быть разбит на один кусок на поток, каждый поток сохраняет свою собственную сумму, а после того, как потоки выполнены, суммы суммируются.
В очень плохо написанной многопоточной версии массив можно разбить, как и раньше, и каждый поток может atomicAdd
получить глобальную сумму.
В этом случае атомарное сложение может выполняться только одним потоком за раз. Я полагаю, что накладные расходы являются мерой того, сколько времени все другие потоки тратят на ожидание выполнения своих собственных atomicAdd
(вы можете попробовать написать эту программу, чтобы проверить, хотите ли вы быть уверенными).
Конечно, он также учитывает время, необходимое для переключения семафоров и мьютексов. В вашем случае это, вероятно, означает, что значительное количество времени тратится на внутренние компоненты mutex.lock и mutex.unlock.
Некоторое время назад я распараллелил часть программного обеспечения (используя pthread_barrier
), и у меня были проблемы, когда для запуска барьеров требовалось больше времени, чем для использования одного потока. Оказалось, что цикл, в котором должно быть 4 барьера, был выполнен достаточно быстро, чтобы лишние затраты не стоили.