practice doi 10 1145 1400214 1400227 What does the proliferation of concurrency mean for the software you develop by Bryan Cantrill and Jeff Bonwick Real World Concurrency could be forgiven if recent microprocessor developments have given them some trepidation about the future of software While Moore s Law continues to hold that is transistor density continues to double roughly every 18 months due to both intractable physical limitations and practical engineering considerations that increasing density is no longer being spent on boosting clock rate but rather on putting multiple CPU cores on a single CPU die From the software perspective this not a revolutionary shift but rather an evolutionary one multicore CPUs are not the birthing of a new paradigm but rather the progression of an old one multiprocessing into more widespread deployment From many recent articles and papers on the subject however one might think that this blossoming of concurrency is the coming of the apocalypse that the free lunch is over 10 As practitioners who have long been at the coal face of concurrent systems we hope to inject some calm reality if not some hard won wisdom into a discussion that has too often descended into hysterics Specifically we hope to answer the essential question what does the proliferation of concurrency mean for Software pr ac t i t i o ne rs to d ay 34 communicatio ns o f th e acm n ov e m ber 2008 vo l 5 1 n o 1 1 the software that you develop Perhaps regrettably the answer to that question is neither simple nor universal your software s relationship to concurrency depends on where it physically executes where it is in the stack of abstraction and the business model that surrounds it And given that many software projects now have components in different layers of the abstraction stack spanning different tiers of the architecture you may well find that even for the software that you write you do not have one answer but several some of your code may be able to be left forever executing in sequential bliss and some of your code may need to be highly parallel and explicitly multithreaded Further complicating the answer we will argue that much of your code will not fall neatly into either category it will be essentially sequential in nature but will need to be aware of concurrency at some level While we will assert that less much less code needs to be parallel than some might fear it is nonetheless true that writing parallel code remains something of a black art We will also therefore give specific implementation techniques for developing a highly parallel system As such this article will be somewhat dichotomous we will try to both argue that most code can and should achieve concurrency without explicit parallelism and at the same time elucidate techniques for those who must write explicitly parallel code Indeed this article is half stern lecture on the merits of abstinence and half Kama Sutra Some Historical Context Before discussing concurrency with respect to today s applications it is helpful to explore the history of concurrent execution even by the 1960s when the world was still wet with the morning dew of the computer age it was becoming clear that a single central processing unit executing a single instruction stream would result in unnecessarily limited system performance While computer designers experimented with different ideas to circumvent this limi illustration by a ndy gilmo re tation it was the introduction of the Burroughs B5000 in 1961 that captured the idea that ultimately proved to be the way forward disjoint CPUs concurrently executing different instruction streams but sharing a common memory In this regard as in many the B5000 was at least a decade ahead of its time But it was not until the 1980s that the need for multiprocessing became clear to a wider body of researchers who over the course of the decade explored cache coherence protocols for example the Xerox Dragon and DEC Firefly prototyped parallel operating systems for example multiprocessor Unix running on the AT T 3B20A and developed par allel databases for example Gamma at the University of Wisconsin In the 1990s the seeds planted by researchers in the 1980s bore the fruit of practical shipping systems with many computer companies for example Sun SGI Sequent Pyramid placing big bets on symmetric multiprocessing These bets on concurrent hardware necessitated corresponding bets on concurrent software if an operating system cannot execute in parallel not much else in the system can either These companies came to the realization independently that their operating systems must be rewritten around the notion of concurrent execution These rewrites took place in the early 1990s and the resulting systems were polished over the decade In fact much of the resulting technology can today be seen in open source operating systems like OpenSolaris FreeBSD and Linux Just as several computer companies made big bets around multiprocessing several database vendors made bets around highly parallel relational databases upstarts like Oracle Teradata Tandem Sybase and Informix needed to use concurrency to achieve a performance advantage over the mainframes that had dominated transaction processing until that time 5 As in operating systems this work was conceived in the n ov e mb er 2 0 0 8 vo l 51 n o 1 1 c om m u n ic at ion s of t he acm 35 practice late 1980s and early 1990s and incrementally improved over the course of the decade The upshot of these trends was that by the end of the 1990s concurrent systems had displaced their uniprocessor forebears as high performance computers When the Top500 list of supercomputers was first drawn up in 1993 the highest performing uniprocessor in the world was just 34 with over 80 of the Top 500 being multiprocessors of one flavor or another By 1997 uniprocessors were off the list entirely Beyond the supercomputing world many transaction oriented applications scaled with CPU allowing users to realize the dream of expanding a system without revisiting architecture The rise of concurrent systems in the 1990s coincided with another trend while CPU clock rate continued to increase the speed of main memory was not keeping up To cope with this relatively slower memory microprocessor architects incorporated deeper and more complicated pipelines caches and prediction units Even then the clock rates themselves were quickly becoming something of a fib while the CPU might be able to execute at