Net framework 5, а также среды Visual Studio 2012 и C#

Глава.27 .Асинхронные.вычислительные.операции
памяти, в 32-разрядном процессе допустимо примерно 1360 потоков. Попытки соз-
дать большее количество потоков приведут к исключению 
OutOfMemoryException
. 
64-разрядный процесс предлагает 8 Тбайт адресного пространства, так что теорети-
чески вы можете создавать сотни тысяч потоков. Но это будет пустая трата ресур-
сов, особенно с учетом того факта, что идеальное количество потоков совпадает с 
количеством процессоров. По идее разработчикам CLR следует убрать ограничения, 
но в настоящий момент это невозможно, так как в результате прекратят свою ра-
боту приложения, разработанные в предположении об ограниченном количестве 
потоков в пуле.
Класс 
System.Threading.ThreadPool
предлагает несколько статических мето-
дов для управления количеством потоков в пуле: 
GetMaxThreads
, 
SetMaxThreads
, 
GetMinThreads
, 
SetMinThreads
и 
GetAvailableThreads
. Впрочем, я не рекомендую 
ими пользоваться. Попытки менять заданные по умолчанию ограничения обычно 
ухудшают работу приложений. Если вы считаете, что вашему приложению требу-
ются сотни или даже тысячи потоков, скорее всего, что-то не так с архитектурой 
приложения или механизмом использования потоков. О том, как правильно при-
менять потоки, мы поговорим в этой главе и в главе 28.
Управление рабочими потоками
На рис. 27.1 показаны различные структуры данных, делающие рабочие потоки 
частью пула. Метод 
ThreadPool.QueueUserWorkItem
и класс 
Timer
всегда помеща-
ют рабочие элементы в глобальную очередь. Рабочие потоки берут элементы для 
обработки из очереди по алгоритму «первым пришел — первым ушел». А так как 
при наличии нескольких потоков элементы из глобальной очереди могут удаляться 
одновременно, все рабочие потоки конкурируют за право на блокировку в рамках 
синхронизации потоков, которое гарантирует, что никакие два или более потока 
не смогут одновременно обрабатывать один и тот же элемент. В некоторых прило-
жениях это право на блокировку становится узким местом, до некоторой степени 
ограничивающим масштабируемость и производительность.
Рассмотрим процесс планирования заданий с помощью заданного по умолчанию 
планировщика (его можно получить через статическое свойство 
Default
класса 
TaskScheduler
)
1
. При планировании задания для нерабочего потока объект 
Task
добавляется в глобальную очередь. При этом каждый рабочий поток обладает 
собственной локальной очередью, в которую и добавляются планируемые задания.
Рабочий поток, готовый к обработке элементов, сначала проверяет наличие 
объектов 
Task
в локальной очереди. Обнаружив такой объект, он изымает его из 
очереди и обрабатывает. Изъятие производится по алгоритму «последним при-
шел — первым ушел». Так как доступ к началу локальной очереди имеет только 
рабочий поток, блокировка в рамках синхронизации потоков больше не требуется, 
1
Поведение других объектов, производных от класса TaskScheduler, может отличаться от 
описываемого в данном разделе.

---

785
Как.пул.управляет.потоками
а добавление заданий в очередь и изъятие их из нее происходят очень быстро. По-
бочным эффектом такого поведения является то, что выполнение заданий идет 
в порядке, обратном порядку их постановки в очередь.