Taming Concurrency

Two items this week. AMD again talked about their next generation of 4 core processors. That is, each chip will have 4 processors. On further research, both AMD and Intel have been talking about 4 core processors for sometime. This week I also received the May edition of IEEE Computer, which had as its cover feature "The Problem with Threads".

On the one hand we are moving into a world where applications have to be concurrent to exploit the available hardware. On the other hand there is a growing realization that the current tools are not adequate. All this in the face of hardware that is being designed to make life more difficult for the casual threads user.

The fundamental problem is quite simple. Programming languages offer a set of features to help the programmer and prevent them from making simple programming mistakes. For example, typechecking and sophisticated type extension mechanisms like objects to allow the programmer to easily express their ideas in a safe way. Automatic garbage collection in Java and other languages eliminate a huge collection of bugs, disastrous crashes and storage management code. On top of this are a set of design patterns that help and guide the programmer.

None of these things exist in the threads environment. A threading library is an add-on to a programming language. It provides no protection to the user, in fact it encourages unsafe programming practices. Also, threading libraries provide very little guidance as to how they should be used. On top of this, there is no rich set of design patterns for parallel and concurrent programming. I had difficulty recognizing the set of design patterns that are available and could not find patterns that I regularly use.

All this has the making of a perfect storm. "The Problem with Threads" paper takes the position that we have to integrate threads into existing programming languages because people are not willing to move to a new programming paradigm. I take the opposite view. We will not be able to write safe concurrent programs until we develop and determine to use programming languages that prevent us from making elementary mistakes, just as we have programming languages that prevents us from making elementary mistakes with types and memory allocation.