The Problem With Threads
I just read a Technical Report from UC Berkeley's EE/CS department entitled The Problem With Threads, which succinctly and clearly captures the problems with the concurrency mechanisms in our currently popular programming languages. It should be very readable to a lay programmer, since only a small section contains formalisms and most unfamiliar terms are defined in the text or footnotes.
To sum it up, threads (shared-memory concurrency) are an inappropriate method of bringing concurrency to a program because they destroy the inherent determinism of sequential programming languages. The tools we have to help deal with the nondeterminism only chip away at the combinatorial explosion of program interleavings, leaving so much opportunity for error that designing reliable and robust multithreaded software is futile.
The report notes that solutions to the problem that retain as much determinism as possible have existed for years, but have not caught on. The author suggests that instead of creating new programming languages, new coordination languages should be used to coordinate components written in familiar languages.
It's a very thought-provoking paper, and I think the conclusions are right on, as much as I'd like a new language to catch on. Massive concurrency is coming, and our current languages are not equipped to tackle it alone.
Comments: (0) Categories: Language-design Concurrency