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.
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
REFERENCES
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 Architecture: 282-293.
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, MA: O’Reilly.
10. See reference 8.
11. Cantrill, B. 2007. A spoonful of sewage. In Beautiful Code, ed. A. Oram and G. Wilson. Cambridge, MA: O’Reilly.
12. See reference 6.
LOVE IT, HATE IT? LET US KNOW feedback@acmqueue.com 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 thread-blocking mechanism. © 2008 ACM 1542-773/08/0900 $5.00
References:
Archives