Разница между [...] 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.