Библиотека параллели задачи по сравнению с асинхронными рабочими процессами
Для особого случая, который Вы обеспечили в своем примере, самый ясный код, вероятно:
if (RequiresSpecialEvent(numError))
fire_special_event();
, Очевидно, это просто перемещает проблему в другую область кода, но теперь у Вас есть возможность снова использовать этот тест. У Вас также есть больше опций для того, как решить его. Вы могли использовать станд.:: набор, например:
bool RequiresSpecialEvent(int numError)
{
return specialSet.find(numError) != specialSet.end();
}
я не предполагаю, что это - лучшая реализация RequiresSpecialEvent, просто что это - опция. Можно все еще использовать переключатель или если еще цепочка, или таблица поиска или некоторая побитовая обработка на значении, безотносительно. Чем более неясным Ваш процесс принятия решений становится, тем больше значения Вы получите на наличие его в изолированной функции.
2 ответа
Название в значительной степени отражает разницу: асинхронное программирование против параллельного программирования. Но в F # вы можете смешивать и сопоставлять.
Асинхронные рабочие процессы F #
Асинхронные рабочие процессы F # полезны, когда вы хотите, чтобы код выполнялся асинхронно, то есть запускает задачу, а не ждет окончательного результата. Наиболее частое использование этого - операции ввода-вывода. Если ваш поток находится в цикле ожидания, ожидая, пока ваш жесткий диск закончит запись, тратит ресурсы.
Если вы начали операцию записи асинхронно, вы можете приостановить поток и разбудить его позже из-за аппаратного прерывания.
Task Parallel Library
Task Parallel Library в .NET 4.0 абстрагирует понятие задачи: например, декодирование MP3 или чтение некоторых результатов из базы данных. В этих ситуациях вы действительно хотите получить результат вычисления и в какой-то момент позже ждете результата операции. (Получив доступ к свойству .Result.)
Вы можете легко комбинировать и сочетать эти концепции. Например, выполнение всех ваших операций ввода-вывода в объекте TPL Task. Для программиста вы абстрагировались от необходимости «иметь дело с» этим дополнительным потоком, но при этом вы тратите ресурсы впустую.
Подобным образом вы можете создать серию асинхронных рабочих процессов F # и запускать их параллельно (Async.Parallel ), но тогда вам нужно дождаться окончательного результата (Async.RunSynchronously). Это освобождает вас от необходимости явно запускать все задачи, но на самом деле вы просто выполняете вычисления параллельно.
По своему опыту я считаю, что TPL более полезен, потому что обычно я хочу выполнять N операций параллельно. Однако асинхронные рабочие процессы F # идеальны, когда что-то происходит «за кулисами», например, реактивный агент или почтовый ящик. (Вы отправляете что-то сообщение, оно обрабатывает его и отправляет обратно.)
Надеюсь, что это поможет.
В 4.0 я бы сказал:
- Если ваша функция является последовательной, используйте асинхронные рабочие процессы. Они просто лучше читают.
- Используйте TPL для всего остального.
Также можно смешивать и сочетать. Они добавили поддержку для запуска рабочего процесса как задачи и создания задач, которые следуют шаблону async Begin / End с использованием TaskFactory.FromAsync , TPL-эквивалента Async.FromBeginEnd или ] Async.BuildPrimitive .
let func() =
let file = File.OpenRead("foo")
let buffer = Array.zeroCreate 1024
let task1 = Task.Factory.FromAsync(file.BeginRead(buffer, 0, buffer.Length, null, null), file.EndRead)
task1.Start()
let task2 = Async.StartAsTask(file.AsyncRead(1024))
printfn "%d" task2.Result.Length
Также стоит отметить, что как среда выполнения Async Workflows, так и TPL собираются создать дополнительный примитив ядра (событие) и использовать WaitForMultipleObjects для отслеживания ввода-вывода завершение, а не использование портов завершения и обратных вызовов. В некоторых приложениях это нежелательно.