Разъяснение .NET ThreadPool - Доступно против свободных потоков

Question

Я немного запутался в одном аспекте .NET ThreadPool: а именно, как вы можете определить, сколько из его «Доступных» потоков простаивает, ожидающих повторного использования, и сколько еще не было создано.

В сводке по методу GetAvailableThreads() указано, что:

Получает разницу между максимальное количество потоков пула потоков возвращается методом GetMaxThreads, и номер в настоящее время активен.

Любой «активный» поток занят работой и, следовательно, недоступен для повторного использования, но сколько из них «доступно» для повторного использования по сравнению с «доступным», поскольку они не были созданы?

Я знаю, что метод GetMinThreads() возвращает абсолютное минимальное количество потоков, которые фреймворк будет поддерживать в пуле для повторного использования, но это не обязательно соответствует текущему количеству свободных потоков - не так ли? У меня сложилось впечатление, что свободные потоки будут висеть в ThreadPool и будут сокращены до минимума, если они не будут использоваться в течение некоторого времени.

Это важно, потому что, согласно документам:

Когда все потоки пула потоков назначены задачам, пул потоков не сразу начинает создавать новые свободные потоки. Чтобы избежать ненужного выделения стекового пространства для потоков, он создает новые незанятые потоки через определенные промежутки времени. Интервал в настоящее время составляет полсекунды, хотя он может измениться в будущих версиях .NET Framework.

Я хочу проверить, должно ли мое приложение создавать чрезмерное количество «новых» потоков в пуле - замедляя его - но я не уверен, как это сделать, не имея возможности выяснить, сколько простоя, готовые к повторному использованию темы, которые у меня есть.

Любые идеи приветствуются. Спасибо!

Answer 1

ThreadPool не может определить, сколько потоков в данный момент простаивает. То есть создан, но на самом деле ничего не делает.

Мой опыт работы с ThreadPool показывает, что очень хорошо хранить темы вокруг. Я не знаю, применили ли они логику для отслеживания среднего числа используемых потоков, но я никогда не замечал, что мои программы ожидают создания потока. За исключением запуска, конечно. Одна из моих программ часто создает и запускает десятки параллельных потоков, и я не вижу никакой задержки при запуске их, даже если рабочая нагрузка была низкой в ​​течение определенного периода времени.

Я бы посоветовал вам использовать инструмент в своем приложении, отслеживая, когда вы делаете вызов ThreadPool.QueueUserWorkItem, и когда рабочий элемент фактически запускается. Как то так:

DateTime queueTime = DateTime.Now;
ThreadPool.QueueUserWorkItem(WorkItemProc, queueTime);

void WorkItemProc(object state)
{
    DateTime startTime = DateTime.Now;
    DateTime queueTime = (DateTime)state;
    TimeSpan elapsed = startTime - queueTime;
    // At this point, elapsed.TotalMilliseconds will tell you how long it took
    // between queuing the item and it actually being started.
    ...
}

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

Answer 2

Я бы предположил, что это случай «Если вы спрашиваете, вы не используете его правильно». Если проблема заключается в управлении ресурсами, то вам следует создать собственное решение, специально предназначенное для вашей производительности. .Net threadpool - это общий инструмент.

предназначен для коллекции самостоятельные краткосрочные задачи.

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

Я бы посоветовал вам прочитать пост Раймонда Чена, который я связал выше. И этот пост Эрика Липперта .