The first thing to bear in mind when talking about asynchronous programming is what the market actually perceives as asynchronous programming (also because Microsoft tends to drive people in this direction with its frameworks) is the ability to keep the UI unlinked to the code behind the waiting time. A strong proof of such a direction is the obligation to use asynchronous programming for any Windows Phone and Windows Store application. Although this choice is understandable because it drives programmers to create apps as the market expects, it also misguides programmers regarding the concept of asynchronous programming theory.

In multi-threaded programming, we create multiple virtual processors (threads) able to execute our code for long-time operations and without the need to participate in the same job. This means that different threads may do different things. In multi-threading, any thread does its job while trying to avoid any resource sharing with other threads, because of the cost of lock synchronization this sharing will imply, as seen in the Multithreading synchronization section in Chapter 3, CLR Internals. It is like executing multiple applications in the same process or dividing macro features of the same application across available cores.

In asynchronous programming, we create multiple threads to execute a single short-timed job (usually involving different external systems) that must end (or continue) all together.

A chat application is an example of a multi-threaded program, an application that consists of two threads. A thread for read data from other participants, and another to write data back to the participants. The two threads have different goals, although they can sometimes exchange or share data. Those threads have a long life and behave as two different applications each integrating with the other only when needed.

An asynchronous programmed example application, instead, creates four threads to save data in four different CSV streams, later compressed into a single ZIP file. What makes such an example perfect for asynchronous programming is the short life of each single thread, the unified software barrier where all threads wait for each other to produce a single ZIP file, and the completely cohesive thread behavior.

Two main asynchronous programming designs are available to developers. A blocking one, which happens when the calling thread waits for all asynchronous threads to proceed all together, or an event signaling based one, where each asynchronous thread acknowledges the main thread by invoking CLR events.

Asynchronous programming approaches – blocking vs. event signaling

As visible in the preceding figure, asynchronous execution may happen in a blocking way with multiple threads that are waited for by the main thread, with signalers such as the WaitHandle hierarchy, as seen in the Multithreading synchronization section Chapter 3, CLR Internals.

Obviously, the .NET framework's observer pattern implementation made with delegates and events is usable and thus, an asynchronous callback handler may be invoked in an operation-starting instance to complete the whole job. If desired, another signaling lock may be used here to continue all together in the blocking way, but again, on another thread.

Before .NET 4, Microsoft allowed asynchronous programming with two main different techniques, one for desktop class applications and another more generic one. Although when programming for .NET 4.5.x, the new frameworks do exist, a lot of SDKs, from Microsoft and other vendors, still support the legacy pattern. Thus, a good knowledge of those techniques is still needed for any programmer who wants to be compliant with all asynchronous designs from Microsoft and also wants to understand the architectural concerns that lie behind the mere technical skill.

Let's look at them in detail.