Когда я не должен использовать ThreadPool в .Net?

@Eric, мне придется согласиться с Дином. Нитки стоят дорого. Вы не можете считать, что ваша программа является единственной запущенной. Когда все жадничают с ресурсами,проблема множится.

Я предпочитаю создавать свои потоки вручную и управлять ими самостоятельно. Он сохраняет код очень легким для понимания.

Это прекрасно, когда это уместно. Однако если вам нужна куча рабочих потоков, все, что вы сделали, - это усложнили свой код. Теперь вам нужно написать код, чтобы управлять ими. Если бы вы просто использовали пул потоков, вы бы получили все управление потоками бесплатно. И пул потоков, предоставляемый языком, очень вероятно, будет более надежным, более эффективным и менее глючным, чем все, что вы катите для себя.

Thread t = new Thread(new ThreadStart(DoSomething));  
t.Start();  
t.Join();  

Я надеюсь, что у вас обычно будет какой-то дополнительный код между Start() и Join() . В противном случае дополнительный поток бесполезен, и вы тратите ресурсы без всякой причины.

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

Миллисекунда - это очень много времени на современном оборудовании. Это 3 миллиона циклов на машине с частотой 3 ГГц. И опять же, вы не единственный, кто создает потоки. Ваши потоки конкурируют за CPU вместе с потоками любой другой программы. Если вы используете not-quite-too-many поток, а также другую программу, то вместе вы использовали слишком много потоков.

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

Действительно. Не усложняйте себе жизнь. Если вашей программе требуется несколько рабочих потоков, не изобретайте велосипед заново. Используйте пул потоков. Вот почему он здесь. А вы бы сами скрутили свой собственный класс струн?

Единственная причина, по которой я не буду использовать ThreadPool для дешевой многопоточности, - это если мне нужен to…

1. взаимодействуйте с запущенным методом (например, чтобы убить его)
2. запустите код в потоке STA (это случилось со мной)
3. сохраняйте поток живым после того, как мое приложение умерло ( ThreadPool потоков являются фоновыми потоками)
4. на случай, если мне понадобится изменить приоритет потока. Мы не можем изменить приоритет потоков в ThreadPool, который по умолчанию является нормальным.

P.S.: Статья MSDN "The Managed Thread Pool" содержит раздел, озаглавленный "When Not to Use Thread Pool Threads", с очень похожим, но немного более полным списком возможных причин отказа от использования пула потоков.

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

Кроме того , посмотрите на новую платформу параллельных расширений, в которой есть некоторые аккуратные вещи, которые могут удовлетворить ваши потребности без необходимости использовать ThreadPool .

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

Пулы потоков не имеют смысла, когда вам нужен поток, который выполняет совершенно разные и несвязанные действия,которые не могут рассматриваться как "jobs"; например, один поток для обработки событий GUI, другой для внутренней обработки. Пулы потоков также не имеют смысла при обработке форм конвейера.

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

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

Разумеется, с двумя оговорками:

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

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

Ах, аргумент от власти - но всегда будьте начеку для людей, которые могли бы быть в команде Windows kernel.

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

Значительные затраты на создание потока в raison d'etre для ThreadPool в первую очередь. Я не хочу, чтобы мои машины были заполнены кодом, написанным людьми, которые были дезинформированы о расходах на создание потока, и, например, не знают, что это приводит к вызову метода в каждом отдельном DLL, который прикреплен к процессу (некоторые из которых будут созданы третьими сторонами), и который вполне может разогреть загрузку кода, который вообще не должен быть в RAM и почти наверняка не должен быть в L1.

Форма иерархии памяти в современной машине означает, что 'distracting' a CPU-это самое худшее, что вы можете сделать, и все, кто заботится о своем ремесле, должны усердно работать, чтобы избежать этого.

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

MSDN имеет список некоторых причин здесь:

http://msdn.microsoft.com/en-us/library/0ka9477y.aspx

Существует несколько сценариев, в которых целесообразно создать и управляйте своими собственными потоками вместо использования потоков пула потоков:

• Вам требуется нить переднего плана.
• Вам требуется, чтобы поток имел определенный приоритет.
• У вас есть задачи, которые вызывают блокировку потока на длительные периоды времени. Пул потоков имеет максимальное количество потоков, поэтому большое количество потоков может быть количество заблокированных потоков пула потоков может препятствовать выполнению задач начало.
• Вам нужно разместить резьбу в однопоточной квартире. Все потоки ThreadPool находятся в многопоточной квартире.
• Вам необходимо иметь стабильное удостоверение, связанное с потоком, или посвятить поток задаче.

Потоки Threadpool подходят для задач, удовлетворяющих обоим следующим критериям:

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

Использование потока threadpool вместо создания нового потока позволит сэкономить значительное, но ограниченное количество времени. Если это время значительно по сравнению со временем, которое потребуется для выполнения задачи, то задача threadpool, скорее всего, подходит. Однако чем больше времени требуется для выполнения задачи, тем меньше польза от использования threadpool и тем больше вероятность того, что задача будет препятствовать эффективности threadpool.

@Eric

@Derek, я не совсем согласен со сценарием, который вы используете в качестве примера. Если вы не знаете точно, что работает на вашем компьютере и сколько всего потоков, дескрипторов, CPU time, RAM и т. д., которые ваше приложение будет использовать при определенной нагрузке, вы в беде.

Вы единственный целевой клиент для программ, которые вы пишете? Если нет, то вы не можете быть уверены в большей части этого. Как правило, вы понятия не имеете, когда пишете программу, будет ли она эффективно выполняться соло, или если она будет работать на webserver, будучи забита атакой DDOS. Вы не можете знать, сколько CPU времени у вас будет.

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

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

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

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

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

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

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

Большая часть моего профессионального опыта была связана с многопоточными и многопроцессорными программами. Я часто нуждался в том, чтобы свернуть свое собственное решение. Это не означает, что пул потоков не является полезным или подходящим во многих случаях. Пул потоков создан для обработки рабочих потоков. В тех случаях, когда требуется несколько рабочих потоков, предоставленный пул потоков должен, как правило, быть первым подходом.