Difference between […]Async and Begin[…] .net asyn

Question

Can anybody explain me what is the difference between the Begin[...]/End[...] asynchronous API pattern and the later [...]Async pattern in .NET 3.5?

• Why was the later created?
• Why would one prefer one pattern over another?

For example, Socket.BeginAccept() and Socket.AcceptAsync().

Answer 1

Note that most *Async methods (with corresponding *Completed events) are using the Event-Based Asynchronous Pattern. The older (but still perfectly valid) Begin* and End* is a pattern called the Asynchronous Programming Model. The Socket class is an exception to this rule; its *Async methods do not have any corresponding events; it's essentially just APM done in a way to avoid excessive memory allocations.

The biggest difference between APM and EBAP is the thread used for completion notification. APM will call back on a thread pool thread (unless the request completes synchronously). EBAP will use a cross-framework strategy to call back on a UI thread (if the operation was started from a UI thread).

However, both APM and EBAP are being replaced with a much more flexible approach based on the Task Parallel Library. Since the TPL can wrap APMs easily, older classes will likely not be updated directly; extension methods are used to provide Task equivalents for the old APM methods.

Update 2012-07-14: I was wrong when I stated "older classes will likely not be updated directly". For performance reasons, the BCL/TPL teams decided to review each BCL type and add TAP methods directly instead of using extension methods. These changes will be in .NET 4.5.

Answer 2

MSDN will answer that better than me:

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

The main feature of these enhancements is the avoidance of the repeated allocation and synchronization of objects during high-volume asynchronous socket I/O. The Begin/End design pattern currently implemented by the System.Net.Sockets.Socket class requires a System.IAsyncResult object be allocated for each asynchronous socket operation.