Многопоточные библиотеки для .NET

Question

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

Какие многопоточные библиотеки для C # /. NET существуют и какие преимущества имеет одна перед другой?

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

Какой .NET Integratet (например, ThreadPool) вы используете периодически? С какими проблемами вы столкнулись?

Answer 1

Существуют различные причины использования нескольких потоков в приложении:

• Отзывчивость интерфейса
• Параллельные операции
• Параллельное ускорение

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

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

Если у вас есть так называемая смущающая параллельная проблема, которую можно легко разделить на небольшие подзадачи, рассмотрите возможность использования пула рабочих потоков (столько же потоков, сколько ядер ЦП), которые извлекают задачи из очереди. Microsoft Task Parallel Library (TPL) может помочь здесь. Если задание может быть легко выражено как вычисление монадического потока (т. Е. С помощью запроса в LINQ с работой в преобразованиях, агрегациях и т. Д.), Может помочь Parallel LINQ (та же ссылка), которая выполняется поверх TPL.

Существуют и другие подходы, такие как Параллелизм в стиле актера , как в Erlang, которые сложнее эффективно реализовать в .NET из-за отсутствия модели «зеленого потока» или средств для ее реализации, например как CLR-поддерживаемые продолжения.

Answer 2

Мне нравится этот http://www.codeplex.com/smartthreadpool

Answer 3

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

http://web.archive.org/web/20120708232527/http://devplanet.com/blogs/brianr/default.aspx

Просто поймите, что я написал их для очень конкретных целей и проверил их в этих условиях, а настоящей серебряной пули нет.

Answer 4

Проверьте Power Threading библиотеку.

Answer 5

Вы должны взглянуть на Параллелизм & Координация Runtime . Поначалу CCR может показаться немного сложным, поскольку требует немного другого мышления. Это видео довольно хорошо объясняет его работу ...

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

Answer 6

Вам не нужно явно использовать пул потоков, вы можете использовать BeginInvoke-EndInvoke, если вам нужны асинхронные вызовы. За кулисами он использует пул потоков. Смотрите здесь: http://msdn.microsoft.com/en-us/library/2e08f6yc.aspx

Answer 7

Имейте в виду, что вы действительно должны закрывать потоки (или разрешать пулу потоков избавляться), когда они вам больше не нужны, если только они вам не понадобятся снова в ближайшее время. Причина, по которой я это говорю, заключается в том, что каждому потоку требуется стековая память (обычно 1 МБ), поэтому, когда у вас есть приложения, сидящие в потоках, но не использующие их, вы теряете память.

Например, Outlook на моем компьютере сейчас имеет 20 открытых потоков и использует 0% ЦП. Это просто пустая трата (минимум) 20 Мб памяти. Word также использует еще 10 потоков с 0% CPU. 30 МБ может показаться не таким уж большим, но что, если каждое приложение тратит 10-20 потоков?

Опять же, если вам нужен доступ к пулу потоков на регулярной основе, вам не нужно закрывать его (создание / удаление потоков сопряжено с накладными расходами).

Answer 8

Я бы посоветовал освоиться с пулом потоков, прежде чем переходить в другие библиотеки. Большая часть кода платформы использует пул потоков, поэтому даже если вам удастся найти The Best Threads Library (TM), вам все равно придется работать с пулом потоков, поэтому вам действительно нужно это понять.

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

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

Answer 9

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

http://devpinoy.org/blogs/jakelite/archive/tags/Threading+Patterns/default.aspx

Answer 10

Для меня встроенных классов Framework более чем достаточно. Threadpool странный и отстойный, но вы можете легко написать свой собственный.

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

Я регулярно запускаю потоки вручную и сохраняю их в словаре с ManualResetEvent, чтобы иметь возможность проверить, кто из них уже закончил. Я использую метод WaitHandle.WaitAll() для этого. Проблема в том, что WaitHandle.WaitAll не принимает массивы с более чем 64 WaitHandles одновременно.