#c #multithreading #threadpool
#c #многопоточность #пул потоков
Вопрос:
Стандартная идиома, по-видимому, заключается в создании n = std::thread::hardware_concurrency()
потоков и размещении их в пуле потоков. Но основной поток — это такой же поток, как и любой другой, поэтому мы могли бы создавать только n - 1
потоки и рассматривать основной поток как часть пула потоков и экономить некоторые ресурсы. Есть ли какая-либо причина, по которой этого не следует делать?
Комментарии:
1. Я думаю, что ваше предположение о создании потоков в соответствии с аппаратным параллелизмом неверно. Сначала подумайте, почему вы это делаете, некоторые ответы затем встанут на свои места автоматически.
2. @UlrichEckhardt о, я вижу, вы хотите, чтобы я динамически балансировал нагрузку.
3. Основной поток не является «потоком, подобным любому другому». Он не управляется
std::thread
объектом, и когда он завершает работу, приложение завершается.4. @PeteBecker в этом весь смысл моего вопроса, избегая необходимости создавать
std::thread
экземпляр.
Ответ №1:
Если вы также выполняете вычисления в основном потоке, тогда конечно.
Но чаще всего идиома, которую я вижу, заключается в том, что основной поток отправляет работу в пул потоков, а затем просто ожидает завершения пула потоков. Если это ожидание выполняется не с помощью busy-waiting, а что-то вроде a condition_variable
, то оно не занимает ядро процессора очень долго.
Также часто основной поток используется для обработки сигналов операционной системы. Особенно в случае приложения пользовательского интерфейса, основной поток должен оставаться отзывчивым, поэтому его использование для потенциально более длительных задач приводит к ухудшению работы пользователя.
Комментарии:
1. о, я просто имел в виду «быстрые» задачи, которые требуют обновления менее 1 кадра, как вы видите в играх. Кажется пустой тратой времени использовать основной поток только для обработки входных событий. Если вы обрабатываете их слишком долго, это тоже может привести к блокировке.