Back in March 2005 when herb Sutter published its famous article “The free lunch is over” and predicted a Concurrent Programming Revolution as big as Object-Oriented Revolution. And here’s a short explanation from the article about the prediction motivation :
The major processor manufacturers and architectures, from Intel and AMD to Sparc and PowerPC, have run out of room with most of their traditional approaches to boosting CPU performance. Instead of driving clock speeds and straight-line instruction throughput ever higher, they are instead turning en masse to hyperthreading and multicore architectures. Both of these features are already available on chips today; in particular, multicore is available on current PowerPC and Sparc IV processors, and is coming in 2005 from Intel and AMD. Indeed, the big theme of the 2004 In-Stat/MDR Fall Processor Forum was multicore devices, as many companies showed new or updated multicore processors. Looking back, it’s not much of a stretch to call 2004 the year of multicore.
Currently, we know that Moore’s law can’t continue forever as explained here
Most semiconductor industry forecasters, including Gordon Moore,expect Moore’s law will end by around 2025.
In April 2005, Gordon Moore stated in an interview that the projection cannot be sustained indefinitely: “It can’t continue forever. The nature of exponentials is that you push them out and eventually disaster happens.” He also noted that transistors eventually would reach the limits of miniaturization at atomic levels
And on the other side, we know that the processor manufacturers try to add more cores for each newly released processor. For example, the Intel E7 Xeon family has 24 cores.
Back to the prediction of Herb Sutter where he says:
Concurrency is the next major revolution in how we write software.
And
Applications will increasingly need to be concurrent if they want to fully exploit continuing exponential CPU throughput gains Efficiency and performance optimization will get more, not less, important.
After 13 years of his prediction, is the concurrency really a major revolution in how we write the software? Or we must wait for few years to see this revolution?
We know that working with the multithread and multi-core is not an easy task, many developers encounter many problems. just a look at the forums we can discover some feedback like this one
I am a fairly good programmer, my boss is also a fairly good programmer. Though he seems to underestimate some tasks such as multi-threading and how difficult it can be (I find it very difficult for anything more than running a few threads, waiting for all to finish, then return results). The moment you start having to worry about deadlocks and race conditions, I find it very difficult, but the boss doesn't seem to appreciate this - I don't think he has ever come across this. Just slap a lock on it is pretty much the attitude. So how can I introduce him, or explain why he might be underestimating the complexities of concurrency, parallelism, and multi-threading? Or maybe I am wrong?
And this is exactly what herb Sutter pointed in his article
The vast majority of programmers today don’t grok concurrency, just as the vast majority of programmers 15 years ago didn’t yet grok objects. But the concurrent programming model is learnable, particularly if we stick to message- and lock-based programming, and once grokked it isn’t that much harder than OO and hopefully can become just as natural. Just be ready and allow for the investment in training and time, for you and for your team.
Currently are the developers aware of the concurrency benefits? Are the projects designed to make the most of the concurrency or we need to recruit experts and gurus to design an efficient code using concurrency? is the revolution is there?
Yes, the revolution is there but it was not initiated by the developers. Many years ago, it was initiated by the new programming languages, and also the new libraries and standards of the classical languages. Indeed a developer needs a language which simplifies its task to make the most of the concurrency. Thinking that it can do it by using a low-level API is a bad idea. It will just introduce many bugs and issues.
Rust, Go and Clojure are some new concurrent oriented languages.
Here ‘s the slogan of rust:
Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety.
And the definition of Clojure:
Clojure is a dynamic, general-purpose programming language, combining the approachability and interactive development of a scripting language with an efficient and robust infrastructure for multithreaded programming.
These new languages gain some popularity but it’s difficult to compete with the older languages like C, C++, Java, and C#. However, for these classic languages and since many years ago, some features and libraries are added to them to make the most of the concurrency and help developers to have an efficient concurrent code. this is what Herb Sutter pointed in his article:
Finally, programming languages and systems will increasingly be forced to deal well with concurrency.
For example Microsoft® .NET Framework 4 introduces Parallel Programming model, which utilizes all the CPU cores and runs your Application code in parallel on all the cores, so that you get the fastest computation of your program written in C#. And for each new .Net Framework, new possibilities, and features are added to make the multicore programming easiest than before.
For C++, Herb Stutter at this time pointed that no standardized support for concurrency at all
The C++ language has long been used to write heavy-duty multithreaded systems well, but it has no standardized support for concurrency at all (the ISO C++ standard doesn’t even mention threads, and does so intentionally), and so typically the concurrency is of necessity accomplished by using nonportable platform-specific concurrency features and libraries. (It’s also often incomplete; for example, static variables must be initialized only once, which typically requires that the compiler wrap them with a lock, but many C++ implementations do not generate the lock.)
Fortunately, the C++ renaissance since 2011 provides to the developer many interesting features to make the multithread and multi-core programming easiest than before.
To resume the revolution is already there when designing the new programming languages or when adding new features to the older popular languages. Now it’s the turn to the developers to discover these new possibilities and try to use them efficiently. Don’t worry the concurrent programming is not scary as before.
Finally, Herb Sutter was right, and it’s not a surprise given his long-standing expertise. And he contributed a lot to provides many useful concurrency features since 2011 with the C++11 standard.
