There are many things that can be caught in terms of asynchronous development.
Firstly, you can execute the code in the background thread. I recently updated my blog post , contrasting several common approaches to running code in the background. Here is a list so that from the most desired to the smallest:
Task (as used by async / await).Task (as used by the parallel task library).BackgroundWorker .Delegate.BeginInvoke .ThreadPool.QueueUserWorkItem .Thread
On the other hand, you might want to imagine an asynchronous operation (which may or may not be the actual execution of the code in the background thread). In this case, there are several approaches for which the smallest is most desirable:
(As a side note, BackgroundWorker is EAP, and Delegate.BeginInvoke is APM).
On the other hand, you could mean asynchronous programming as a whole, which could be construed as a reactive approach. In this case, I know only two approaches:
However, you can make sure that any event-driven program reacts to some extent, so just handling the user interface events is a (simple) form of "asynchronous programming."
In addition, these are only general models. Any platform or library can add more. Here are some of my legs:
- The
Socket class has a special APM form that can be used to minimize memory allocation. It is very similar to APM, but does not match the pattern. - WinRT runtime (included with Windows 8) has its own representations of asynchronous operations (
IAsyncOperation<TResult> and IAsyncInfo ). - Windows Phone has special background agent support, which allows you to run code in the background, even if your application is not currently running.
Stephen cleary
source share