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

Как пул управляет потоками
В этом разделе я хотел бы остановиться на том, каким образом пул управляет ра-
бочими потоками и потоками ввода-вывода. Глубоко погружаться в детали мы не 
будем, так как внутренняя реализация этого процесса менялась при переходе от 
одной версии CLR к другой и наверняка изменится в будущем. Поэтому пул по-
токов можно представить в виде черного ящика. Вряд ли он окажется идеальным 
решением для какого-то конкретного приложения, так как эта технология пла-
нирования потоков общего назначения рассчитана на работу в широком спектре 
приложений. Для некоторых приложений она подходит лучше, чем для других. 
Впрочем, на сегодняшний день она прекрасно справляется со своими задачами, 
и я рекомендую отнестись к ней с доверием. Вряд ли вы сможете самостоятельно 
написать пул потоков, который будет функционировать лучше, чем поставляемый 
в составе CLR. Так как с течением времени внутренняя система управления пото-
ками у пула меняется, многие приложения начинают работать лучше.
Ограничение количества потоков в пуле
CLR позволяет указать максимально возможное количество потоков, создавае-
мых пулом. Однако возникает ощущение, что задавать верхний предел для пула 
не стоит, потому что это может привести к зависанию или взаимной блокировке. 
Представьте очередь из 1000 рабочих элементов, заблокированную сигнальным 
событием элемента под номером 1001. Если верхний предел для количества пото-
ков равен 1000, этот новый поток исполнен не будет, а значит, вся тысяча потоков 
навсегда окажется заблокированной. Конечному пользователю останется только 
завершить работу приложения, потеряв несохраненные данные. Разработчики 
обычно не накладывают искусственных ограничений на доступные для приложения 
ресурсы. Кому захочется при запуске приложения ограничивать объем используемой 
им памяти или пропускную способность канала связи? И все же по каким-то при-
чинам некоторые разработчики считают возможным ограничивать максимальное 
количество потоков в пуле.
Из-за проблем, связанных с зависаниями и взаимными блокировками, разработ-
чики CLR постоянно увеличивают заданное по умолчанию максимально возможное 
количество потоков в пуле. В настоящее время предел составляет 1000 потоков, что 
для 32-разрядного процесса, имеющего не менее 2 Гбайт адресного пространства, 
может рассматриваться как отсутствие ограничений. После загрузки библиотек 
Win32 и библиотек CLR, а также выделения собственной и управляемой кучи 
остается примерно 1,5 Гбайт адресного пространства. Так как каждый поток требует 
для стека в пользовательском режиме и блока окружения (TEB) более 1 Мбайт 

---

784