Back in March 2005, Herb Sutter published his famous article “The Free Lunch Is Over” and predicted a concurrent programming revolution as big as the object-oriented revolution. Here’s a brief excerpt from the article explaining the motivation behind this prediction:
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.
Today, 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
At the same time, processor manufacturers continue to add more cores to each new generation of processors. For example, the Intel E7 Xeon family has 24 cores.
Returning to Herb Sutter’s prediction, 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.
Thirteen years after his prediction, has concurrency truly revolutionized the way we write software? Or do we need to wait a few more years to see this revolution unfold?
We know that working with multithreading and multicore systems is not easy, and many developers encounter significant challenges. A quick look at developer forums reveals feedback like this:
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?This is exactly what Herb Sutter pointed out 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.
Are developers currently aware of the benefits of concurrency? Are projects designed to make the most of concurrency, or do we still need experts to design efficient concurrent code? Is the revolution here?
Yes, the revolution is here, but it was not driven by developers alone. It began years ago with new programming languages, as well as new libraries and standards for established languages. Developers need languages that make it easier to take full advantage of concurrency. Relying solely on low-level APIs is usually a bad idea, as it can introduce numerous bugs and other issues.
Rust, Go, and Clojure are examples of modern languages designed with concurrency in mind.
Here’s the Rust slogan:
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 newer languages are gaining popularity, but competing with established languages such as C, C++, Java, and C# remains difficult. However, these established languages have gained features and libraries over the years that help developers take advantage of concurrency and write efficient concurrent code. This is what Herb Sutter pointed out in his article:
Finally, programming languages and systems will increasingly be forced to deal well with concurrency.
For example, Microsoft® .NET Framework 4 introduced a parallel programming model that can utilize all available CPU cores and run application code in parallel, improving the performance of C# programs. Each new version of the .NET Framework added capabilities that made multicore programming easier.
For C++, Herb Sutter pointed out at the time that there was 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 that began in 2011 has provided developers with many useful features that make multithreaded and multicore programming easier.
To sum up, the revolution is already here, both in the design of new programming languages and in the addition of new features to established ones. Now it is up to developers to explore these capabilities and use them effectively. Don’t worry — concurrent programming is not as scary as before.
Ultimately, Herb Sutter was right, which is hardly surprising given his long-standing expertise. He has also contributed significantly to the development of useful concurrency features since 2011, beginning with the C++11 standard.