Максимальное количество элементов очереди в ThreadPool.Метод queueuserworkitem

Я установил максимальный поток в 10. Затем я добавил задачу 22000 с помощью ThreadPool.Метод queueuserworkitem. Весьма вероятно, что не все задачи 22000 были завершены после запуска программы. Есть ли ограничение, сколько задач можно поставить в очередь для доступных потоков?

4 ответов


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


Если вам нужно подождать, пока все задачи будут обработаны, вам нужно справиться с этим самостоятельно. Потоки ThreadPool-это все фоновые потоки и не будут поддерживать работу приложения.

Это относительно чистый способ справиться с этим типом ситуации:

 using (var mre = new ManualResetEvent(false))
 {
      int remainingToProcess = workItems.Count(); // Assuming workItems is a collection of "tasks"
      foreach(var item in workItems)
      {
           // Delegate closure (in C# 4 and earlier) below will 
           // capture a reference to 'item', resulting in
           // the incorrect item sent to ProcessTask each iteration.  Use a local copy
           // of the 'item' variable instead.
           // C# 5/VS2012 will not require the local here.
           var localItem = item;
           ThreadPool.QueueUserWorkItem(delegate
           {
               // Replace this with your "work"
               ProcessTask(localItem);

               // This will (safely) decrement the remaining count, and allow the main thread to continue when we're done
               if (Interlocked.Decrement(ref remainingToProcess) == 0)
                      mre.Set();
           });
      }
      mre.WaitOne();
 }

это, как говорится, обычно лучше "группировать" вместе ваши рабочие элементы, если у вас есть тысячи из них, а не рассматривать их как отдельные рабочие элементы для threadpool. Это накладные расходы. участвуйте в управлении списком элементов, и поскольку вы не сможете обрабатывать 22000 за раз, вам лучше группировать их в блоки. Наличие отдельных рабочих элементов каждый процесс 50 или около того, вероятно, поможет вашей общей пропускной способности совсем немного...


Это вопрос, зависящий от реализации, и реализация этой функции со временем немного изменилась. Но в .Net 4.0 вы существенно ограничены объемом памяти в системе, поскольку задачи хранятся в очереди в памяти. Вы можете увидеть это, копаясь в реализации в reflector.


с документация ThreadPool:

Примечание: потоки в управляемом пуле потоков являются фоновыми. То есть их свойства IsBackground истинны. Это означает, что поток ThreadPool не будет поддерживать работу приложения после выхода всех потоков переднего плана.

возможно ли, что вы выходите до того, как все задачи были обработаны?