Я очищаю старый код, преобразуя его для работы в асинхронном режиме.

psDelegate.GetStops decStops = psLoadRetrieve.GetLoadStopsByLoadID;
var arStops = decStops.BeginInvoke(loadID, null, null);
WaitHandle.WaitAll(new WaitHandle[] { arStops.AsyncWaitHandle });
var stops = decStops.EndInvoke(arStops);

Выше приведен единственный пример того, что я делаю для асинхронной работы. Мой план состоит в том, чтобы работать около 20 разных делегатов. Все вызовут BeginInvoke и дождутся завершения, прежде чем вызывать EndInvoke.

У меня вопрос: вызовет ли такое большое количество делегатов проблемы? Я понимаю, что BeginInvoke использует ThreadPool для работы и имеет ограничение в 25 потоков. 20 ниже этого предела, но весьма вероятно, что другие части системы также могут использовать любое количество потоков из ThreadPool.

Благодарность!

3
stewsha 12 Июн 2010 в 22:00
Предел ThreadPoolLimit составляет 25 НА ЯДРО ПРОЦЕССОРА;)
 – 
TomTom
12 Июн 2010 в 22:02

2 ответа

Лучший ответ

Нет, диспетчер ThreadPool был разработан, чтобы справиться с этой ситуацией. Это не позволит всем потокам пула потоков работать одновременно. Он начинается с того, что позволяет запускать столько потоков, сколько у вас ядер ЦП. Как только один завершается, он позволяет запускать другой.

Каждые полсекунды он включается, если активные потоки не завершаются. Предполагается, что они застряли, и позволяет запускать еще один. На двухъядерном процессоре у вас теперь будет работать 3 потока.

Чтобы достичь максимума, 500 потоков на 2-ядерном процессоре, потребуется довольно много времени. У вас должны быть потоки, которые не завершаются более 4 минут. Если ваши потоки ведут себя таким образом, вы не хотите использовать потоки пула потоков.

2
Hans Passant 12 Июн 2010 в 22:26
Не говоря уже о том, что 500 управляемых потоков займут 500 МБ пространства стека.
 – 
Brian Rasmussen
12 Июн 2010 в 22:31

Текущее значение MaxThreads по умолчанию составляет 250 на процессор, поэтому ограничений быть не должно, если только ваше приложение не отправляет вызовы BeginInvoke. См. http://msdn.microsoft.com/en-us /library/system.threading.threadpool.aspx. Кроме того, пул потоков будет пытаться повторно использовать существующие потоки перед созданием новых, чтобы уменьшить накладные расходы на создание новых потоков. Если все вызовы выполняются быстро, вы, вероятно, не увидите, что пул потоков создает много потоков.

Для длительных задач или задач блокировки обычно лучше избегать пула потоков и управлять потоками самостоятельно.

Однако попытка запланировать такое количество потоков, вероятно, не даст наилучших результатов на большинстве современных машин.

1
Brian Rasmussen 12 Июн 2010 в 22:15