Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

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?

share|improve this question

closed as primarily opinion-based by Snowman, durron597, Kilian Foth, GlenH7, JB King Nov 5 at 18:14

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

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 '11 at 18:24
@JB King I think most concurrent programming has used threading or process models. This model works differently:… – Jeremy Jul 8 '11 at 18:31
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 '11 at 19:02
I remember using callbacks and non-blocking system calls on VMS back in (gulp!) the early 80s. – TMN Jul 8 '11 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 '11 at 2:07

4 Answers 4

up vote 16 down vote accepted

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.

share|improve this answer
+1: I don't have to finish writing my answer ;) – Demian Brecht Jul 8 '11 at 18:25
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 '11 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 '11 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.

share|improve this answer
Again, this isn't a threading model.… – Jeremy Jul 8 '11 at 18:36

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#.

share|improve this answer

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. :)

share|improve this answer
This isn't a threading model and cannot take advantage of multiple cores.… – Jeremy Jul 8 '11 at 18:41

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