основные потоки и пулы потоков

#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 кадра, как вы видите в играх. Кажется пустой тратой времени использовать основной поток только для обработки входных событий. Если вы обрабатываете их слишком долго, это тоже может привести к блокировке.