This month’s Effective Concurrency column, Prefer Futures to Baked-In “Async APIs”, is now live on DDJ’s website.
From the article:
When designing concurrent APIs, separate "what" from "how"
Let’s say you have an existing synchronous API function [called DoSomething]… Because DoSomething could take a long time to execute (whether it keeps a CPU core busy or not), and might be independent of other work the caller is doing, naturally the caller might want to execute DoSomething asynchronously. …
The question is, how should we enable that? There is a simple and correct answer, but because many interfaces have opted for a more complex answer let’s consider that one first.
I hope you enjoy it. Finally, here are links to previous Effective Concurrency columns:
The Pillars of Concurrency (Aug 2007)
How Much Scalability Do You Have or Need? (Sep 2007)
Use Critical Sections (Preferably Locks) to Eliminate Races (Oct 2007)
Apply Critical Sections Consistently (Nov 2007)
Avoid Calling Unknown Code While Inside a Critical Section (Dec 2007)
Use Lock Hierarchies to Avoid Deadlock (Jan 2008)
Break Amdahl’s Law! (Feb 2008)
Going Superlinear (Mar 2008)
Super Linearity and the Bigger Machine (Apr 2008)
Interrupt Politely (May 2008)
Maximize Locality, Minimize Contention (Jun 2008)
Choose Concurrency-Friendly Data Structures (Jul 2008)
The Many Faces of Deadlock (Aug 2008)
Lock-Free Code: A False Sense of Security (Sep 2008)
Writing Lock-Free Code: A Corrected Queue (Oct 2008)
Writing a Generalized Concurrent Queue (Nov 2008)
Understanding Parallel Performance (Dec 2008)
Measuring Parallel Performance: Optimizing a Concurrent Queue (Jan 2009)
volatile vs. volatile (Feb 2009)
Sharing Is the Root of All Contention (Mar 2009)
Use Threads Correctly = Isolation + Asynchronous Messages (Apr 2009)
Use Thread Pools Correctly: Keep Tasks Short and Nonblocking (Apr 2009)
Eliminate False Sharing (May 2009)
Break Up and Interleave Work to Keep Threads Responsive (Jun 2009)
The Power of “In Progress” (Jul 2009)
Design for Manycore Systems (Aug 2009)
Avoid Exposing Concurrency – Hide It Inside Synchronous Methods (Oct 2009)
Prefer structured lifetimes – local, nested, bounded, deterministic (Nov 2009)
Prefer Futures to Baked-In “Async APIs” (Jan 2010)
I always enjoy teaching together with Scott Meyers and Andrei Alexandrescu, not only because it means I get to work with good friends, but also because I get to listen to them speak. Scott and Andrei always have interesting and useful things to say and say them well. We occasionally speak at the same big conferences, but at those we’re often scheduled at the same time and so we don’t get to hear each other’s sessions (and attendees likewise have to choose one competing session or the other for that time slot), and presenting in large rooms to hundreds of people makes it hard to get much quality face time with the individual audience members.
So I’m really looking forward to spending three days together with Scott and Andrei and a limited number of attendees at a new event called C++ and Beyond:
What do C++ programmers think about these days? Perhaps the new features from C++0x that are becoming commonly available and that introduce fundamental changes in how C++ software is designed. Perhaps the increasing importance of developing effective concurrent systems. Perhaps the continuing pressure to create high-performance software. Possibly the impact of new systems programming languages such as D. Most likely, all of the above, and more.
C++ legends Scott Meyers, Herb Sutter, and Andrei Alexandrescu think about these things, too — all the time. Scott and Herb are neck-deep in C++0x, while Andrei is literally writing the book on D (The D Programming Language). Herb and Andrei put the pedal to the metal on applied concurrency and parallelism; Herb is writing the book on that topic (Effective Concurrency). All three focus on the development of high-performance systems, a topic Scott’s writing a book about (Fastware!).
This summer, Scott, Herb, and Andrei will host an intensive three-day technical event focusing on “C++ and Beyond” — an examination of issues related to C++ and its application in high-performance (typically highly concurrent) systems, as well as related technologies of likely interest to C++ programmers.
We know it’ll be in the Seattle area. We know it’ll be this summer. What we don’t know is which of the two candidate dates (in June or August) works best for you, so we thought we’d let you decide: If you’re potentially interested in attending, please vote for your preferred date. At that page you can also let us know what kinds of topics you’d like to see covered.
Once we finalize the details we’ll post them and open registration. You can subscribe to follow announcements via this feed.
We hope to see you in the beautiful Pacific Northwest this summer.
Recommended reading (it’s short), from the January 2010 issue of CACM:
What Should We Teach New Software Developers? Why?
by Bjarne Stroustrup
It’s a wonderfully accurate and concise summary of the disconnect between the ivory tower and the trenches – i.e., (some) computer science academics and (some) software development industry managers, with commentary on other topics like why or why not to regulate the software development industry.
My favorite part is this from the conclusion (emphasis added):
We must do better. Until we do, our infrastructure will continue to creak, bloat, and soak up resources. Eventually, some part will break in some unpredictable and disastrous way (think of Internet routing, online banking, electronic voting, and control of the electric power grid). …
Bjarne isn’t prone to disaster warnings (indeed, this is the first time I recall seeing a comment like this from him, even over a beer or three), but he’s right. This hits directly on an issue I’ve also been giving thought to in recent years: As an industry and a society, we routinely underestimate the degree to which we’ve gradually allowed our automated civilization to become reliant on computers and software, and vulnerable as a result. We’ve been satisfied with making any given system “reliable enough” for the intended application (e.g., having a much higher bar for life-critical software than for a word processor), and so far we’ve been able to get away with that without the level of broad regulation for software development that is routinely required for other disciplines like engineering that are involved in providing essential products and services. Of course, as Bjarne points out, one reason for the lack of regulation of the software development industry is that we don’t know (and/or can’t agree on) exactly what to require and how to measure it; we’re just not as mature a field yet as civil or mechanical engineering.
Recognizing the potential scope of a catastrophic and systemic software failure in the field – one that disables a vital piece of infrastructure (say, electric power or food distribution, country-wide for a month) and that can’t be patched with a remote update – adds impetus to understanding and solving the kinds of issues Bjarne writes about.