Почему ThreadPool по умолчанию имеет 250 рабочих потоков на процессор?

Question

Взято из документации Microsoft:

По умолчанию пул потоков имеет 250 рабочих потоков на каждый доступный процессор.Вы можете изменить этот параметр, используя метод ThreadPool.SetMaxThreads.

Также, как известно, есть некоторые издержки:

Потоки имеют некоторый уровеньнакладные расходы.Поэтому, если на компьютере установлено несколько процессоров, а вы разбиваете обработку на два потока, вы не увидите 100-процентного улучшения производительности.

Из некоторого опыта и большего из предположений, я бы сказалбыло что-то вроде 1 до 4 потоков на процессор, а не 250 !Кто-то знает почему 250?Это какое-то значение, которое должно дать лучшую общую производительность , или , чтобы оно позволяло обрабатывать практически все задачи, которые вы даете этому пулу потоков, без обработки ожидание для завершения других задач?

Answer 1

Мотивация не производительность. Как вы упомянули, слишком большое количество потоков может легко привести к снижению производительности (из-за переключения контекста, перебора кэша, конфликтов и т. Д.).
Идея этого магического числа - попытка избежать появления тупиковых ситуаций в коде пользователя. Разработчик может вызвать взаимоблокировку, если он помещает многочисленные рабочие элементы в пул потоков, который ожидает других элементов, которые также были в очереди в пул потоков. Если возникает ситуация, когда в пуле потоков используется максимальное количество потоков (все они находятся в состоянии ожидания), тогда вы получаете deadlock .

Конечно, нет ничего особенного с числом «250», и могут возникнуть взаимные блокировки, если разработчик настаивает на использовании такой проблематичной схемы использования пула потоков. Однако в таких сценариях это должно снизить вероятность зайти в тупик.

Джо Даффи более подробно объясняет эти рассуждения в своем посте: Почему максимальное количество потоков в CLR 2.0 SP1 по умолчанию было увеличено до 250 / CPU .