The Concurrency Problem

Vol. 6 No. 5 – September 2008

The Concurrency Problem

Affine Romance: Buyer (and seller) beware

There’s 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, I’m from Missouri,” which requires the proper Southern Mizoorah drawl for maximum impact. Wherever you’re 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).

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

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 is a language developed to let mere mortals write, test, deploy, and debug fault-tolerant concurrent software. 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. 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.

Erlang is a language developed to let mere mortals write, test, deploy, and debug fault-tolerant concurrent software. 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. 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.

by Jim Larson

Beautiful Code Exists, if You Know Where to Look: A koder with attitude, KV answers your questions. Miss Manners he ain’t.

I’ve been reading your rants 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.

I've been reading your rants 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.

by George Neville-Neil

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 Queue’s 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.

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 Queue's 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.

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.

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.

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.

by Bryan Cantrill, Jeff Bonwick

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.

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.

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