ThreadPool против выделенной темы - когда отдавать предпочтение какой

Question

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

Но где магический барьер? Как мне решить, какой подход использовать?

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

Answer 1

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

Я не знаю, как это масштабируется с более мощным оборудованием. Это легко проверить, просто запустите 16 потоковых процессов и попросите их написать DateTime.Now и Sleep (8001).

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

Answer 2

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

Используйте потоки, если вам нужна длительная задача или вам нужно установить некоторые свойства потока, такие как приоритет, приоритет, культура и т. Д.

Если возможно, используйте класс Task в .NET 4.Планировщик по умолчанию использует пул потоков, но вы можете предоставить свой собственный планировщик и, таким образом, точно контролировать, как задачи отображаются на потоки.

Answer 3

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

Производительность должна быть одинаковой. Параллельная библиотека задач в .NET 4.0 Framework использует только ThreadPool, поэтому это не должно быть проблемой для вашего проекта.

Answer 4

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