Real-world
CONCURRENCY
Software practitioners today 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), as a result of
both intractable physical limitations and practical engineering considerations, that increasing density
is no longer being spent on boosting clock rate. Instead, it
is being used to put multiple CPU cores on a single CPU
die. From the software perspective, this is 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. Judging 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.” 1
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 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.
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: you may be able to leave some of your
code forever executing in sequential bliss, and some 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.
