The Concurrency Problem

Vol. 6 No. 5 – September 2008

The Concurrency Problem

Interviews

A Conversation with Steve Bourne, Eric Allman, and Bryan Cantrill

In part two of their discussion, our editorial board members consider XP and Agile.

A Conversation with Steve Bourne, Eric Allman, and Bryan Cantrill

In part two of their discussion, our editorial board members consider XP and Agile.

In the July/August 2008 issue of ACM Queue we published part one of a two-part discussion about the practice of software engineering. The goal was to gain some perspective on the tools, techniques, and methodologies that software engineers use in their daily lives. Three members of Queues editorial advisory board participated: Steve Bourne, Eric Allman, and Bryan Cantrill, each of whom has made significant and lasting real-world contributions to the field (for more information on each of the participants, see part one). In part two we rejoin their conversation as they discuss XP (Extreme Programming) and Agile.

ERIC ALLMAN Weve talked a fair amount about tools, design methodologies, and a lot about debuggers, but we havent really talked much about programming practices and styles. These days you probably have to be dead not to have heard about XP and Agile. Im interested in XP, and have been for a while. One of the things that interests me, though, is that it doesnt really look like theres much new in it. A lot of the principles have been around awhilefor example, unit testing? Gosh, when did I first hear about unit testing? I might have been out of diapers, but not by much.

Curmudgeon

Affine Romance

Buyer (and seller) beware

Affine Romance

Buyer (and seller) beware

Stan Kelly-Bootle, Author

Theres a British idiom, Suck it and see, the epitome of skepticism, which despite its coarse brevity could well replace whole libraries of posh philosophic bigtalk about the fabric of reality. A less aggressive version is Show me, Im from Missouri, which requires the proper Southern Mizoorah drawl for maximum impact. Wherever youre from, the message is one of eternal vigilance in the face of fancy claims. Advertising, the creation and pushing forth of fancy claims, predates human literacy, and its success is evident in many rampant domains ranging from religion and astrology to sugared water, pet rocks, and Java (only joking there, James).

From the serpents cunning loss-leader fruit promotion in Eden (hurry, this offer ends soon) has grown a major industry, the dynamo of consumerism, winning both West and East. Ironically, there are warnings of evil in the very etymology (Latin adversus) and even stronger revelations in Vance Packards The Hidden Persuaders (1957). Its still referred to generically as Madison Avenue, although the special talent needed to bamboozle, or in euphemistic ad-speak, motivate, buyers is quite evenly distributed around the globe.

by Stan Kelly-Bootle

Articles

Erlang for Concurrent Programming

What role can programming languages play in dealing with concurrency? One answer can be found in Erlang, a language designed for concurrency from the ground up.

Erlang for Concurrent Programming

Designed for concurrency from the ground up, the Erlang language can be a valuable tool to help solve concurrent problems.

Jim Larson, Google

Erlang is a language developed to let mere mortals write, test, deploy, and debug fault-tolerant concurrent software.1 Developed at the Swedish telecom company Ericsson in the late 1980s, it started as a platform for developing soft realtime software for managing phone switches.2 It has since been open-sourced and ported to several common platforms, finding a natural fit not only in distributed Internet server applications, but also in graphical user interfaces and ordinary batch applications.

Erlangs minimal set of concurrency primitives, together with its rich and well-used libraries, give guidance to anyone trying to design a concurrent program. Erlang provides an effective platform for concurrent programming for the following reasons:

by Jim Larson

Real-World Concurrency

In this look at how concurrency affects practitioners in the real world, Cantrill and Bonwick argue that much of the anxiety over concurrency is unwarranted.

Real-world Concurrency

Chances are you wont actually have to write multithreaded code. But if you do, some key principles will help you master this black art.

Bryan Cantrill and Jeff Bonwick, Sun Microsystems

Software practitioners today could be forgiven if recent microprocessor developments have given them some trepidation about the future of software. While Moores 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 universalyour softwares relationship to concurrency depends on where it physically executes, where it is in the stack of abstraction, and the business model that surrounds it.

by Bryan Cantrill, Jeff Bonwick

Kode Vicious

Beautiful Code Exists, if You Know Where to Look

Dear KV, I've been reading your rants in Queue for a while now and I can't help asking, is there any code you do like? You always seem so negative; I really wonder if you actually believe the world of programming is such an ugly place or if there is, somewhere, some happy place that you go to but never tell your readers about.

Dear KV,

Ive been reading your rants in Queue for a while now and I cant help asking, is there any code you do like? You always seem so negative; I really wonder if you actually believe the world of programming is such an ugly place or if there is, somewhere, some happy place that you go to but never tell your readers about.
A Happy Programmer

by George Neville-Neil

Articles

Software Transactional Memory: Why Is It Only a Research Toy?

The promise of STM may likely be undermined by its overheads and workload applicabilities.

TM (transactional memory) is a concurrency control paradigm that provides atomic and isolated execution for regions of code. TM is considered by many researchers to be one of the most promising solutions to address the problem of programming multicore processors. Its most appealing feature is that most programmers only need to reason locally about shared data accesses, mark the code region to be executed transactionally, and let the underlying system ensure the correct concurrent execution. This model promises to provide the scalability of fine-grain locking, while avoiding common pitfalls of lock composition such as deadlock. In this article we explore the performance of a highly optimized STM and observe that the overall performance of TM is significantly worse at low levels of parallelism, which is likely to limit the adoption of this programming paradigm.

by Calin Cascaval, Colin Blundell, Maged Michael, Harold W. Cain, Peng Wu, Stefanie Chiras, Siddhartha Chatterjee

Parallel Programming with Transactional Memory

While sometimes even writing regular, single-threaded programs can be quite challenging, trying to split a program into multiple pieces that can be executed in parallel adds a whole dimension of additional problems. Drawing upon the transaction concept familiar to most programmers, transactional memory was designed to solve some of these problems and make parallel programming easier. Ulrich Drepper from Red Hat shows us how it's done.

With the speed of individual cores no longer increasing at the rate we came to love over the past decades, programmers have to look for other ways to increase the speed of our ever-more-complicated applications. The functionality provided by the CPU manufacturers is an increased number of execution units, or CPU cores.

by Ulrich Drepper