Herb Sutter
James Larus
Abstract
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 describes the hardware imperatives behind this shift in computer architecture from uniprocessors to multicore processors, also known as CMPs.
- Sutter, H. 2005. The free lunch is over: a fundamental turn toward concurrency in software. Dr. Dobb's Journal 30 (3); http://www.gotw.ca/publications/concurrency-ddj.htm.Google Scholar
- Ramalingam, G. 2000. Context-sensitive synchronization-sensitive analysis is undecidable. ACM Transactions on Programming Languages and Systems 22 (2): 416-430. Google ScholarDigital Library
- Dean, J., and Ghemawat, S. 2004. MapReduce: simplified data processing on large clusters. Proceedings of the Sixth Symposium on Operating Systems Design and Implementation, San Francisco, CA: 137-150. Google ScholarDigital Library
- Qadeer, S., and Wu, D. 2004. KISS: Keep it Simple and Sequential. Proceedings of the ACM SIGPLAN 2004 Conference on Programming Language Design and Implementation, Washington, DC: 1-13. Google ScholarDigital Library
- King, S. T., Dunlap, G. W., and Chen, P. M. 2005. Debugging operating systems with time-traveling virtual machines. Proceedings of the 2005 Annual Usenix Technical Conference, Anaheim, CA: 1-15. Google ScholarDigital Library
- Chandra, S., Godefroid, P., and Palm, C. 2002. Software model checking in practice: an industrial case study. Proceedings of the 24th International Conference on Software Engineering, Orlando, FL: 431-441. Google ScholarDigital Library
Index Terms
- Software and the Concurrency Revolution: Leveraging the full power of multicore processors demands new tools and new thinking from the software industry.
Recommendations
Relaxed Concurrency Control in Software Transactional Memory
Some of today's TM systems implement the two-phase-locking (2PL) algorithm which aborts transactions every time a conflict occurs. 2PL is a simple algorithm that provides fast transactional operations. However, it limits concurrency in benchmarks with ...
Experiences in initiating concurrency software research efforts
ICSE '10: Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering - Volume 2Multi-core CPUs are now common in modern computers. To get access to effectively an unlimited supply of compute resources, software programs that have been highly optimized to use a single CPU need to be converted where possible to use concurrency. We ...
A Smooth Concurrency Revolution with Free Objects
Most of the many concurrent programming models that have been invented were devised by concurrency "aristocrats" for concurrency aristocrats. To get concurrency to the masses, we need a simple way to exploit parallelism with languages that common ...
Reviews
Matthew Mark Huntbach
The most interesting thing about this article is that it differs little from similar articles written up to 30 years ago. The argument is that the increasing computational requirements of programs being written will force us to use massively concurrent hardware, and this will require a revolution in programming languages. This was, for example, the driving force behind the Japanese Fifth Generation project of the 1980s. But the promised boom in new programming paradigm languages was sidestepped. Efficiency developments in sequential hardware remained in line with the growth in computational requirements; the object-oriented paradigm, an organic development from structural programming, and still sequential at heart, has come to dominate the development of new programming languages. This article follows from another that argues that the physical limits to sequential hardware efficiency have now been reached. It follows a familiar line, noting that, though for certain problems with a regular structure, the explicitly programmed mapping of subproblems to parallel processors is a possibility, for computation in general there is no predictable pattern. Unpredictable parallel access to mutable memory is difficult to comprehend and reason about. Java may be the state-of-the-art programming language, but its concurrency mechanism of threads with synchronization through locks represents no change from techniques of decades ago, and feels horribly low level. The paper discusses this, says we need to change, but only hints at how. I was sorry the paper did not have more references to past experimental work that, if this paper is right, may return to fashion soon. Online Computing Reviews Service
Access critical reviews of Computing literature here
Become a reviewer for Computing Reviews.
Comments