exception, not the rule; in normal contexts, wait- and
lock-free data structures are to be avoided as their failure
modes are brutal (livelock is much nastier to debug than
deadlock), their effect on complexity and the maintenance burden is significant, and their benefit in terms of
performance is usually nil.
Prepare for the thrill of victory—and the agony of
defeat. Making a system scale can be a frustrating pursuit:
the system will not scale until all impediments to scalability have been removed, but it is often impossible to
know if the current impediment to scalability is the last
one. Removing that last impediment is incredibly gratifying: with that change, throughput finally gushes through
the system as if through an open sluice. Conversely, it can
be disheartening to work on a complicated lock breakup
only to discover that while it was the impediment to
scalability, it was merely hiding another impediment,
and removing it improves performance very little—or
perhaps not at all. As discouraging as it may be, you must
return to the system to gather data: does the system not
scale because the impediment was misunderstood, or
does it not scale because a new impediment has been
encountered? If the latter is the case, you can take solace
in knowing that your work is necessary—though not sufficient—to achieve scalability, and that the glory of one
day flooding the system with throughput still awaits you.
THE CONCURRENC Y BUFFE T
There is universal agreement that writing multithreaded
code is difficult: although we have attempted to elucidate
some of the lessons learned over the years, it nonetheless
remains, in a word, hard. Some have become fixated on
this difficulty, viewing the coming of multicore computing as cataclysmic for software. This fear is unfounded, for
it ignores the fact that relatively few software engineers
actually need to write multithreaded code: for most, concurrency can be achieved by standing on the shoulders of
those subsystems that already are highly parallel in implementation. Those practitioners who are implementing a
database or an operating system or a virtual machine will
continue to need to sweat the details of writing multithreaded code, but for everyone else, the challenge is not
how to implement those components but rather how
best to use them to deliver a scalable system. While lunch
might not be exactly free, it is practically all-you-can-eat—and the buffet is open! Q
1. Sutter, H., Larus, J. 2005. Software and the concurrency revolution. ACM Queue 3( 7): 54-62.
2. De Witt, D., Gray, J. 1992. Parallel database systems:
the future of high-performance database systems.
Communications of the ACM 35( 6): 85-98.
3. Oskin, M. 2008. The revolution inside the box.
Communications of the ACM 51( 7): 70-78.
4. Barroso, L. A., Gharachorloo, K., McNamara, R.,
Nowatzyk, A., Qadeer, S., Sano, B., Smith, S., Stets,
R., Verghese, B. 2000. Piranha: a scalable architecture
based on single-chip multiprocessing. In Proceedings of
the 27th Annual International Symposium on Computer
5. Shavit, N. 2008. Transactions are tomorrow’s loads
and stores. Communications of the ACM 51( 8): 90.
6. Cantrill, B. 2006. Hidden in plain sight. ACM Queue
4( 1): 26-36.
7. McKusick, K. A. 2006. A conversation with Jarod Jen-son. ACM Queue 4( 1): 16-24.
8. Cantrill, B. 2003. Postmortem object type identification. In Proceedings of the Fifth International Workshop
on Automated Debugging.
9. Peyton Jones, S. 2007. Beautiful concurrency. In
Beautiful Code, ed. A. Oram and G. Wilson. Cambridge,
10. See reference 8.
11. Cantrill, B. 2007. A spoonful of sewage. In Beautiful
Code, ed. A. Oram and G. Wilson. Cambridge, MA:
12. See reference 6.
LOVE IT, HATE IT? LET US KNOW
firstname.lastname@example.org or www.acmqueue.com/forums
BRYAN CANTRILL is a Distinguished Engineer at Sun
Microsystems, where he has worked on concurrent systems
since coming to Sun to work with Jeff Bonwick on Solaris
performance in 1996. Along with colleagues Mike Shapiro
and Adam Leventhal, Cantrill developed DTrace, a facility
for dynamic instrumentation of production systems that
was directly inspired by his frustration in understanding the
behavior of concurrent systems.
JEFF BONWICK is a Fellow at Sun Microsystems, where he
has worked on concurrent systems since 1990. He is best
known for inventing and leading the development of Sun’s
ZFS (Zettabyte File System), but prior to this he was known
for having written (or rather, rewritten) many of the most
parallel subsystems in the Solaris kernel, including the synchronization primitives, the kernel memory allocator, and the
© 2008 ACM 1542-773/08/0900 $5.00