Разница между [...] Async и Begin [...].net асинхронными API

Может кто-нибудь объяснить мне, в чем разница между шаблоном Begin [...]/End [...] асинхронного API и более поздним [...] шаблоном Async в .NET 3.5?

  • Почему было создано позднее?
  • Почему вы предпочитаете один шаблон над другим?

Например, Socket.BeginAccept() и Socket.AcceptAsync().

Ответы

Ответ 1

MSDN ответит на это лучше меня:

http://msdn.microsoft.com/en-us/library/system.net.sockets.socketasynceventargs.aspx

Основная особенность этих улучшений является предотвращение повторного распределения и синхронизации объекты при больших объемах асинхронный ввод-вывод. Начало/конец модель проектирования классом System.Net.Sockets.Socket требуется объект System.IAsyncResult выделяться для каждого асинхронного сокет.

Ответ 2

Обратите внимание, что большинство методов *Async (с соответствующими событиями *Completed) используют Асинхронный шаблон на основе событий. Более старые (но все же совершенно корректные) Begin* и End* - это шаблон, называемый модель асинхронного программирования. Класс Socket является исключением из этого правила; его методы *Async не имеют соответствующих событий; это по сути просто APM, сделанное таким образом, чтобы избежать чрезмерных распределений памяти.

Самая большая разница между APM и EBAP - это поток, используемый для уведомления о завершении. APM обратится к потоку пула потоков (если запрос не завершится синхронно). EBAP будет использовать межплатформенную стратегию для возврата к потоку пользовательского интерфейса (если операция была запущена из потока пользовательского интерфейса).

Однако как APM, так и EBAP заменяются гораздо более гибким подходом, основанным на параллельной библиотеке задач. Поскольку TPL может легко переносить APM, старые классы, скорее всего, не будут обновляться напрямую; методы расширения используются для предоставления эквивалентов Task для старых методов APM.

Обновление 2012-07-14: Я ошибся, когда заявил, что "старые классы, скорее всего, не будут обновляться напрямую". По соображениям производительности команды BCL/TPL решили просмотреть каждый тип BCL и добавить методы TAP напрямую вместо использования методов расширения. Эти изменения будут в .NET 4.5.