It was started with C# 5's new keyword "async". And now I see this async programming everywhere from Javascript to C++, mostly from Microsoft. And from various discussions I came to know, this is a very useful technique to avoid threading yet keep CPU working while other things are fetched form hard disk or network.

My question is, why such an important topic was ignored all these days? Or it's just a hype from Microsoft?

  • 5
    Have you looked into the history of concurrent programming? I think this kind of stuff has been around a long time though you may not have seen it unless you knew what you wanted to see about it.
    – JB King
    Jul 8, 2011 at 18:24
  • 1
    @JB King I think most concurrent programming has used threading or process models. This model works differently: stackoverflow.com/questions/4047427/…
    – Jeremy
    Jul 8, 2011 at 18:31
  • 5
    Uh... it wasn't even ignored by Microsoft before C# 5. Async patterns based on delegates and IAsyncResult have been in the framework since I think 1.1 (maybe 2.0), as have async pages in ASP.NET. Many if not most of these are based on thread pools and I/O completion ports, which have been in the Windows operating system for, like, forever.
    – Aaronaught
    Jul 8, 2011 at 19:02
  • 3
    I remember using callbacks and non-blocking system calls on VMS back in (gulp!) the early 80s.
    – TMN
    Jul 8, 2011 at 19:19
  • Ditto on Mac OS 3 through 9. If you did much in the way of blocking disk access calls, the user interface bogged down.
    – Bob Murphy
    Jul 9, 2011 at 2:07

4 Answers 4


It's certainly not new, it's just where the industry (not just MS) has been making a lot of progress lately in terms of making it more accessible to sub-geniuses.

Historically doing async programming was more cumbersome and difficult, consider the async socket api in windows for example.

With the new tools & abstractions coming out, it gets easier every day. Take a look at how easy it is with node.js, for example.

  • +1: I don't have to finish writing my answer ;) Jul 8, 2011 at 18:25
  • 1
    Although they are promising to extend node.js to a multi-process model. While it may give you an asynchronous programming model it cannot take advantage of multiple processors, hyperthreading, etc.
    – Jeremy
    Jul 8, 2011 at 18:40
  • @Jeremy Of course it can. Run multiple node instances. There's a child process API you can hook into. Rather then doing multi-processing using "method X" by default, node gives you the flexibility to handle it however you want.
    – Raynos
    Jul 9, 2011 at 10:19

You do realize the first A of AJAX is Asynchronous, right? That is one source of it for the past decade. Multi-core CPUs may be another reason for some of this as more threads can be handled at once the problem of synchronization which has been around for a while, see Two Generals' Problem which had a proof written in 1975.

Asynchrony in C# 5.0 part Four: It's not magic has this point that I think is relevant:

A number of people have asked me "so does this mean that the Task Asynchrony Pattern only works on UI threads that have message loops?" No. The Task Parallel Library was explicitly designed to solve problems involving concurrency; task asynchrony extends that work. There are mechanisms that allow asynchrony to work in multithreaded environments without message loops that drive user interfaces, like ASP.NET.

Thus points on concurrency are relevant here. If you want to suggest that isn't the case, please back up that argument as concurrency seems relevant here. I will concede that Asynchrony isn't exactly concurrency.


Looks similar to what some Lisp dialects call futures, although the syntactic restriction (plus some of the discussion links) imply that they're doing it via a local CPS (continuation-passing style) transformation.

As to why it's taken so long, if you come from a C/C++ mindset, you probably think "the stack" is real; you expect variables to live there, you might even create pointers to stack-allocated things. Whereas in a higher-level language, you think about the program context (or continuation), which might live on "the stack", but might be copied or moved when the language runtime feels like it to implement things like first-class continuations, lightweight threads, deep recursion, and proper tail recursion on unfriendly platforms. It sounds like .NET is just taking some of the techniques developed for implementing higher-level languages and bringing them, conservatively, into C#.


Multiple cores have made it async a much more useful language feature. Instead of being merely a way of easily swapping out tasks, it is an easy way to have multiple tasks going on at the same time. The greater value has lead to greater use.

Plus from a marketing point of view, you have to have something radically new when releasing a new version of a product. :)


Not the answer you're looking for? Browse other questions tagged or ask your own question.