Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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?
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.
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. :)
IAsyncResulthave 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.