Многопоточные библиотеки для .NET
Лично я украл модуль HTParse.c из W3C (например, он используется в веб-браузере lynx ). Затем вы можете делать такие вещи, как:
strncpy(hostname, HTParse(url, "", PARSE_HOST), size)
. Важно использовать хорошо зарекомендовавшуюся и отладочную библиотеку, так это то, что вы не попадаете в типичные ловушки синтаксического анализа URL (много регулярных выражений терпят неудачу, если хост является IP-адресом, например, специально для IPv6).
10 ответов
Существуют различные причины использования нескольких потоков в приложении:
- Скорость отклика UI
- Параллельные операции
- Параллельное ускорение
Подход, который нужно выбрать, зависит от того, что Вы пытаетесь сделать. Для скорости отклика UI рассмотреть использование BackgroundWorker, например.
Для параллельных операций (например, сервер: что-то, что не должно быть параллельным, но вероятно должно быть параллельным даже в одножильной системе), рассматривает использование пула потоков или, если задачи долговечны, и Вы нуждаетесь в большом количестве из них, рассматриваете использование одного потока на задачу.
Если у Вас есть так называемое, смущающе параллельны проблеме, которая может быть легко разделена в небольшие подпроблемы, рассмотреть использование пула рабочих потоков (как много потоков как ядра процессора) что задачи получения по запросу от очереди. Microsoft Task Parallel Library (TPL) может помочь здесь. Если задание может быть легко выражено как одноместное потоковое вычисление (т.е. с запросом в LINQ с работой в преобразованиях и агрегированиях и т.д.), Параллельный LINQ (та же ссылка), который работает сверху TPL, может помочь.
Существуют другие подходы, такие как параллелизм стиля Агента, как замечено в Erlang, которые более трудно реализовать эффективно в.NET из-за отсутствия зеленой модели потоков или средств реализовать то же, такое как поддерживаемые CLR продолжения.
Мне нравится этот http://www.codeplex.com/smartthreadpool
Мой советовать должен был бы стать довольным пулом потоков перед перемещением в любые другие библиотеки. Много кода платформы использует пул потоков, поэтому даже если Вы, оказывается, находите Лучший Threads Library(TM), необходимо будет все еще работать с пулом потоков, таким образом, действительно необходимо понять это.
Необходимо также иметь в виду, что большая работа была помещена в реализацию пула потоков и настройку его. Следующей версии.NET инициировала многочисленные улучшения разработка параллельные библиотеки.
В моей точке зрения многие "проблемы" с пулом текущего потока могут быть исправлены путем знания его достоинств и недостатков.
Я записал большую поточную обработку кода в мои дни, даже реализовали мое собственное объединение поточной обработки и диспетчера. Многое из него документируется здесь:
http://web.archive.org/web/20120708232527/http://devplanet.com/blogs/brianr/default.aspx
Просто поймите, что я записал их в очень определенных целях и протестировал их в тех условиях, и нет никакой реальной серебряной пули.
Вы не должны использовать пул потоков явно, можно использовать BeginInvoke-EndInvoke при необходимости в асинхронных вызовах. Это использует пул потоков негласно. Посмотрите здесь: http://msdn.microsoft.com/en-us/library/2e08f6yc.aspx
Необходимо смотреть на Время выполнения Параллелизма и Координации. CCR может быть небольшим укрощением сначала, поскольку это требует немного отличающегося набора ума. Это видео имеет довольно хорошее задание объяснения его работ...
По-моему, это было бы способом пойти, и я также слышу, что он будет использовать тот же планировщик в качестве TPL.
Следует иметь в виду, что действительно необходимо закрывать обсуждения (или позволять пулу потоков располагать), когда Вам больше не нужны они, если Вам не будут нужны они снова скоро. Причина я говорю это, состоит в том, что каждый поток требует стековой памяти (обычно 1 МБ), поэтому когда у Вас есть приложения, находящиеся на потоках, но не использующие их, Вы тратите впустую память.
Для экс-клена Outlook на моей машине прямо сейчас имеет 20 открытых потоков и использует 0% ЦП. Это - просто трата (наименьшее) 20 МБ памяти. Word также использует еще 10 потоков с 0% ЦП. 30 МБ не могут походить на много, но что, если каждое приложение тратило впустую 10-20 потоков?
Снова, если необходимо получить доступ к пулу потоков регулярно затем, Вы не должны закрывать его (создающие/уничтожающие потоки имеет издержки).
Для меня встроенные классы Платформы более чем достаточно. Threadpool является нечетным и хромым, но можно записать собственное легко.
Я часто использовал BackgroundWorker класс для Frontends, причина, это делает жизнь намного легче - вызов, сделан автоматически для eventhandlers.
Я регулярно запускаю потоков вручную и безопасный их в словаре с a ManualResetEvent смочь исследовать, кто из них уже закончился. Я использую WaitHandle.WaitAll() Метод для этого. Проблема там, тот WaitHandle. WaitAll не принимает Массивы больше чем с 64 WaitHandles сразу.
Вы могли бы хотеть посмотреть на ряд статей о поточной обработке шаблонов. Прямо сейчас это имеет примеры кода для реализации WorkerThread и ThreadedQueue.
http://devpinoy.org/blogs/jakelite/archive/tags/Threading+Patterns/default.aspx