Должны ли задачи .Net 4.0 всегда быть предпочтительным методом для многопоточных приложений?

Question

Я читал о параллельной библиотеке задач , и в статье говорилось:

В .NET Framework 4 задачи являются предпочтительным API для написания многопоточных, асинхронныхи параллельный код

Но это также говорит о том, что они используют ThreadPool за кулисами.Что мне трудно понять, так это то, что если Задачи следует использовать только тогда, когда вы используете ThreadPool (и поэтому «Поток против Задачи» будет эквивалентен «Поток против Потока»), или если Microsoft намеревается использовать Задачивезде, где требуется несколько потоков, без учета соображений, присущих дилемме «Поток против ThreadPool».

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

Answer 1

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

Переключение на эту модель аналогично переключению на управляемый GC-ed язык по сравнению с языком, который требует от вас очистки собственной памяти. Всегда будут аргументы в пользу последнего, но Сборка мусора становится настолько оптимизированной, что это практически не проблема. В идеале механизм переключения во время выполнения задач будет развиваться и улучшаться. Таким образом, теоретически ваше приложение, написанное и скомпилированное для .NET 4, могло бы работать быстрее с лучшими реализациями среды выполнения без дальнейшей перекомпиляции. Кроме того, многопоточность кода, как известно, трудно понять правильно, поэтому любой механизм, скрывающий эти детали, полезен для программиста.

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

Answer 2

Вы можете использовать TaskCreationOptions.LongRunning как подсказку, чтобы сообщить TPL, что ваша задача может быть более сложной, чем то, для чего настроен ThreadPool. Но, да, TPL, кажется, является предпочтительным методом для многопоточного программирования в будущем. Microsoft даже опирается на него, чтобы поддерживать новые ключевые слова async и await, которые предлагаются в Async CTP . Это не значит, что вам придется полностью отказаться от API Thread и ThreadPool старого стиля. Тем не менее, я лично обнаружил, что TPL выполняет большую часть того, что я хочу, в более элегантном API, и я склонен полагаться на него почти исключительно сейчас.

Answer 3

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

Используя задачи, разработчик создает столько задач, сколько необходимо, объединяет их в цепочку для создания потоков (рабочие процессы в F #) и контролирует их отмену, не заботясь о том, как потоки выделяются или используются.Время выполнения зависит от выбора наилучшего способа выполнения всех задач с использованием ограниченного числа потоков.

Задачи значительно упрощают реализацию шаблонов параллельного программирования.Библиотека ParallelExtensionExtras предоставляет методы для преобразования пар Begin / EndXXX в задачи, которые можно объединить в цепочку, и предварительную версию идиомы итерации задачи, которая используется Async CTP для обеспечения синтаксиса async / await.Вы можете использовать ConcurrentCollection задач для создания очереди заданий, аналогично примеру AsyncCall в ParallelExtensionExtras, или пойти еще дальше и создать агентов, похожих на Scala, Erlang или F #.DataFlow в Async CTP - это еще один пример того, что вы можете создавать с помощью задач.

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