Чтобы воскресить эту старую нить, я только что сделал простой код тест:
#include <thread>
int main(int argc, char** argv)
{
for (volatile int i = 0; i < 500000; i++)
std::thread([](){}).detach();
return 0;
}
Я скомпилировал его g++ test.cpp -std=c++11 -lpthread -O3 -o test. Затем я запускал его три раза подряд на старом (ядро 2.6.18), сильно загруженном (выполняющем восстановление базы данных) медленном ноутбуке (Intel Core i5-2540M). Результаты трех последовательных прогонов: 5.647s, 5.515s и 5.561s. Таким образом, мы рассматриваем чуть более 10 микросекунд на поток на этой машине, возможно, гораздо меньше на вашем.
Это не так много накладных расходов, учитывая, что последовательные порты max превышают около 1 бит за 10 микросекунд. Теперь, конечно, есть различные дополнительные потери потоков, которые можно получить с участием переданных/захваченных аргументов (хотя вызовы функций могут накладывать некоторые), замедления кэша между ядрами (если несколько потоков на разных ядрах сражаются по одной и той же памяти одновременно) и т. д. Но в целом я очень сомневаюсь, что прецедент, который вы представили, будет отрицательно влиять на производительность вообще (и может обеспечить выгоды, в зависимости), несмотря на то, что вы уже предварительно упреждали обозначение понятия «действительно ужасный код», даже не зная, сколько времени потребуется запустите поток.
Независимо от того, хорошо ли это или нет, многое зависит от деталей вашей ситуации. На что еще ответственен вызывающий поток? Что конкретно связано с подготовкой и записью пакетов? Как часто они выписываются (с каким распределением? Равномерным, сгруппированным и т. Д.?) И какова их структура? Сколько ядер имеет система? И т. Д. В зависимости от деталей оптимальное решение может быть от «нитей» вообще до «общего пула потоков» до «потока для каждого пакета».
Обратите внимание, что пулы потоков не являются волшебными и в некоторых случаях могут быть замедлением по сравнению с уникальными потоками, поскольку одно из самых больших замедлений с потоками - синхронизация кешированной памяти, используемой несколькими потоками одновременно, и пулы потоков по их очень необходимо искать и обрабатывать обновления из другого потока. Таким образом, ваш основной поток или поток дочерних процессов может застрять, если ждать, если процессор не будет уверен, изменил ли другой процесс раздел памяти. Напротив, в идеальной ситуации уникальный поток обработки для заданной задачи должен только разделить память с ее вызывающей задачей (когда она запущена), а затем они больше не будут мешать друг другу.
Какая реализация pthread? –
Один рабочий поток поможет с некоторыми другими видами конкуренции ресурсов, которые могут иметь несколько потоков (чередующиеся записи и т. Д.). – msandiford
Я хотел бы прокомментировать, что да, это, наверное, ужасная вещь, которая приводит к моему вопросу, сколько накладных расходов возникает при создании потока (в общем) Честно говоря, я не знаю, как определить или даже измерьте реализацию библиотеки pthread – jdt141