Один маленький недостаток пула потоков

Один маленький недостаток пула потоков

Пул потоков в. Net framework представляет собой довольно мощный и хорошо отлаженный механизм управления потоками. Каждый раз при выполнении новой задачи новый поток не создается, вместо этого он берется из пула за символическое время. Таким образом минимизируется воздействие на производительность, которое было бы недопустимо значимым, если бы каждый раз поток создавался заново.

Работа с пулом потоков в. Net проста и заключается в вызове метода

ThreadPool. QueueUserWorkItem(SomeAction, data);

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

Однако, есть в Threads pool и один недостаток, который делает невозможным его использования в некоторых сложных системах. Заключается этот недостаток в том, что пул потоков в. Net имеет внутреннее ограничение на максимальное число потоков и не позволяет его изменять извне. Сделано это по ряду причин. По умолчанию это ограничение составляет 1000 потоков. Предполагается, что больше 1000 нитей создавать нет смысла, да и не получится это. Ведь максимальное адресное пространство, доступное для процесса под управлением 32-разрядной системы составляет 2 гигабайта. А с учетом того, что каждый поток использует как минимум 1 мегабайт оперативной памяти для хранения своих системных данных, то получается что 1000 потоков уже займет не менее 1 гигабайта памяти. Плюс еще приложение расходует память на свои основные задачи. Вот и получается, что больше 1000 потоков создать на 32-разрядной системе может и не получится.

Однако, что если вы разрабатываете серверное приложение, которой скорей всего будет крутиться на 64-разрядной оси. В этом случае никаких ограничений на максимальное число потоков у вас нет (в практическом смысле). И теоретически для мощного многоядерного сервера может быть написано приложение, которое будет выполнять задачи, скажем в 50-100 потоков. Причем одновременно в некоторые моменты может пытаться выполнять несколько десятков таких задач. И в один прекрасный момент получится ситуация, когда все потоки тред пула будут заняты, и для новой задачи не останется свободного обработчика. Здесь мы получим в лучшем случае задержку при обработке определенного таска, в худшем deadlock.

Поэтому при проектировании системы следует учесть, а подходит ли вам стандартный пул потоков. Net framework для ваших конкретных задач, или имеет смысл написать свой.


Карта сайта


Информационный сайт Webavtocat.ru