Nonblocking Algorithms and Scalable Multicore Programming
Exploring some alternatives to lock-based synchronization
by Samy Al Bahra | June 11, 2013
This article appears in print in Communications of the ACM, Volume 56 Issue 7—
Proving the Correctness of Nonblocking Data Structures
So you've decided to use a nonblocking data structure, and now you need to be certain of its correctness. How can this be achieved? When a multithreaded program is too slow because of a frequently acquired mutex, the programmer's typical reaction is to question whether this mutual exclusion is indeed required. This doubt becomes even more pronounced if the mutex protects accesses to only a single variable performed using a single instruction at every site. Removing synchronization improves performance, but can it be done without impairing program correctness?
by Mathieu Desnoyers | June 2, 2013
This article appears in print in Communications of the ACM, Volume 56 Issue 7—
Structured Deferral: Synchronization via Procrastination
We simply do not have a synchronization mechanism that can enforce mutual exclusion.
Software Transactional Memory: Why Is It Only a Research Toy?
STM is sometimes touted as the way forward for developing concurrent software, but is it ready for use in real-world applications? The authors built an STM runtime system and compiler framework, the IBM STM, and compared its performance to other similar products by Intel and Sun. They conclude that from both performance and productivity standpoints, STM still has a long way to go before it can be viable in the real world.
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.
by Ulrich Drepper | October 24, 2008
This article appears in print in Communications of the ACM, Volume 52 Issue 2—
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.
by Jim Larson | October 24, 2008
This article appears in print in Communications of the ACM, Volume 52 Issue 3—
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.
by Bryan Cantrill, Jeff Bonwick | October 24, 2008
This article appears in print in Communications of the ACM, Volume 51 Issue 11—
Unlocking Concurrency
Multicore architectures are an inflection point in mainstream software development because they force developers to write parallel programs. In a previous article in Queue, Herb Sutter and James Larus pointed out, “The concurrency revolution is primarily a software revolution.
Threads without the Pain
Much of today’s software deals with multiple concurrent tasks. Web browsers support multiple concurrent HTTP connections, graphical user interfaces deal with multiple windows and input devices, and Web and DNS servers handle concurrent connections or transactions from large numbers of clients.
Software and the Concurrency Revolution
Leveraging the full power of multicore processors demands new tools and new thinking from the software industry. Concurrency has long been touted as the "next big thing" and "the way of the future," but for the past 30 years, mainstream software development has been able to ignore it. Our parallel future has finally arrived: new machines will be parallel machines, and this will require major changes in the way we develop software. The introductory article in this issue ("The Future of Microprocessors" by Kunle Olukotun and Lance Hammond) describes the hardware imperatives behind this shift in computer architecture from uniprocessors to multicore processors, also known as CMPs (chip multiprocessors).
Trials and Tribulations of Debugging Concurrency
We now sit firmly in the 21st century where the grand challenge to the modern-day programmer is neither memory leaks nor type issues (both of those problems are now effectively solved), but rather issues of concurrency. How does one write increasingly complex programs where concurrency is a first-class concern. Or even more treacherous, how does one debug such a beast? These questions bring fear into the hearts of even the best programmers.
