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

Ответ 1

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

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

PS: Статья MSDN "Пул управляемых потоков" содержит раздел под заголовком "Когда не использовать потоки пула потоков" с очень похожим, но немного более полным списком возможных причин не использовать пул потоков.

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

В качестве альтернативы рассмотрите новую Parallel Extensions Framework, в которой есть некоторые аккуратные вещи, которые могут удовлетворить ваши потребности, не используя ThreadPool.

Ответ 2

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

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

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

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

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

Люди слишком боятся ресурсов, используемых потоками. Я никогда не видел создания и начала потока, чтобы занять более миллисекунды. Не существует жесткого ограничения на количество потоков, которые вы можете создать. Использование ОЗУ минимально. После того, как у вас есть несколько сотен потоков, CPU становится проблемой из-за контекстных переключателей, поэтому в этот момент вы можете захотеть получить представление о своем дизайне.

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

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

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

Ответ 3

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

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

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

Ответ 4

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

Два оговорки, конечно:

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

Ответ 5

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

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

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

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

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

Ответ 6

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

Ответ 7

В MSDN есть список причин:

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

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

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

Ответ 8

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

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

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

Ответ 9

@Eric

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

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

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

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

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

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

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

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

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

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