Зачем использовать APM вместо отдельного потока?

Question

Если я хочу прочитать или записать файл, я может использовать stream.BeginRead и stream.EndRead, но для этого требуются обратные вызовы и МНОГО уродливого, сложного кода с использованием модели асинхронного программирования.

Зачем мне хотеть использовать эти асинхронные методы ввода-вывода (которые используют скрытый пул потоков .NET), чем писать тот же код в синхронном стиле и передавать , который , в пул потоков. (Вместо того, чтобы рубить мой метод обратными вызовами.)

Обновление:

Некоторые (хорошие) ответы показывают, что использование APM избавляет меня от создания потока - с чем я согласен, поскольку каждый новый поток имеет свой собственный стек 2 МБ. Но где выполняются BeginRead и Endread? Пул потоков? Является ли повторное использование потока, который уже был выделен, единственным преимуществом?

Answer 1

Прежде всего, вы также должны взглянуть на APM на основе событий .

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

С APM потоки вообще не блокируются. Из пула потоков нет ничьей. Это особенно важно для серверных приложений, таких как ASP.NET, поскольку это означает, что блокирующий поток не будет препятствовать обработке запросов.

Answer 2

У Джеффа Рихтера очень умный и чистый способ использовать APM.

Answer 3

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

Тем не менее, да, Begin-End APM ужасно использовать. Если вам нужен неблокирующий ввод-вывод и вы можете использовать другой язык для части своего приложения, попробуйте F #. «Асинхронные рабочие процессы» облегчают написание асинхронного кода.