Какие ресурсы используют заблокированные потоки

Question

Одной из основных целей написания кода в модели асинхронного программирования (более конкретно - использование обратных вызовов вместо блокирования потока) является минимизация количества блокирующих потоков в системе.

Для запущенных потоков,Эта цель очевидна из-за переключения контекста и затрат на синхронизацию.

Но как быть с заблокированными потоками?почему так важно уменьшить их количество?

Например, при ожидании ответа от веб-сервера поток блокируется и не занимает процессорное время и не участвует в переключении контекста..

Итак, мой вопрос: кроме ОЗУ (около 1 МБ на поток?) Какие другие ресурсы используются для блокировки заблокированных потоков?

И еще один более субъективный вопрос: в каких случаях это будет стоитьдействительно оправдывает необходимость написания асинхронного кода (цена может быть, например, разделением вашего приятного связного метода на множество методов beginXXX и EndXXX и переносом параметров и локальных переменных в поля класса).

UPDATE -дополнительные причины, которые я не упомянул или не дал достаточного веса:

1. Больше потоков означает больше блокировки общих ресурсов

2. Больше потоковозначает больше создания и утилизации потоков, что дорого

3. Система может определенно исчерпать потоки / ОЗУ, а затемоперации по обслуживанию клиентов (в сценарии с веб-сервером это может привести к отключению службы)

Answer 1

Итак, мой вопрос: кроме ОЗУ (около 1 МБ на поток?) Какие другие ресурсы используются заблокированными потоками?

Это один из крупнейших.При этом существует причина, по которой ThreadPool в .NET допускает так много потоков на ядро ​​- в 3.5 по умолчанию было 250 рабочих потоков на ядро ​​в системе .(В .NET 4 это зависит от системной информации, такой как размер виртуального адреса, платформа и т. Д. - сейчас нет фиксированного значения по умолчанию.) Потоки, особенно заблокированные, на самом деле не так уж и дороги ...

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

И еще один более субъективный вопрос: в каких случаях эти затраты действительно оправдают хлопоты по написанию асинхронного кода (цена может бытьнапример, разделение вашего хорошего связного метода на множество методов beginXXX и EndXXX и перемещение параметров и локальных переменных в поля класса).

Прямо сейчас это часто вызывает боль.Это сильно зависит от сценария.Однако класс Task<T> в .NET 4 значительно улучшает это для многих сценариев.Используя TPL, это гораздо менее болезненно, чем раньше, когда он использовал APM (BeginXXX / EndXXX) или даже EAP.

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

Answer 2

Я хотел бы отметить, что цифра в 1 МБ для стековой памяти (или 256 КБ, или как она установлена) является резервной;в то время как он забирает доступное адресное пространство, фактическая память выделяется только по мере необходимости.

С другой стороны, наличие очень большого числа потоков неизбежно приводит к некоторому отставанию планировщика задач, так какотслеживать их (которые стали работоспособными с последнего тика и т. д.).

Answer 3

Помимо любых ресурсов заблокированный поток может удерживать блокировку, также учитывается размер пула потоков.Если вы достигли максимального размера пула потоков (если я правильно помню, что для .NET 4 максимальное число потоков равно 100 на процессор), вы просто не сможете заставить что-либо еще работать в пуле потоков, пока не будет получен хотя бы один потокосвобожден.