Computer chip manufacturers cannot keep on increasing the clock speed indefinitely to make their processors faster. They seem to have already reached the limit (on clock speed) and have started putting multiple independent processing cores on a single chip to increase the computational capacity. As most systems start running on processors with tens of cores (if not hundreds right away) application programmers will need to start relying on concurrent programming to make their applications faster and responsive. This will lead to significant changes in the way we design, develop, debug and test programs. We will have new tools, APIs, compilers, languages and frameworks for supporting highly concurrent programs written by application programmers.

The first and most obvious change will be that programmers will start using many more threads and use current lock based approaches to synchronize access to shared data. Now detecting bugs in multithreaded programs is extremely difficult and as we write more concurrent programs, it will become increasingly important to have tools which can check our programs for correctness. Two such tools are CHESS from Microsoft research and jPredictor from UIUC. Both are still research projects but are definitely worth taking a look at and playing around with.

The transactional memory research community advocates getting rid of lock based approach for managing access to shared data. The idea comes from the database world where transactions have been around for a long time. Hardware transactional memory, hybrid transactional memory and software transactional memory, the three broad categories in which implementations are often split, are all under active research but there already are quite a few implementations out there for you to play around with. One of the core ideas behind using transactional memory for accessing shared data is to allow users to specify “what” needs to be synchronized and then let the machine take care of the “how” part (compare this to how you use locks today). This is supposed to greatly simplify the concurrent programming model but it is too early to say if it really does make the programming model simpler.

While  I cannot cover or summarize the work being done on transactional memory without making it into a small project, I can provide a few starting points that you may find interesting. Microsoft is doing very interesting work in this area and while a lot of it uses Haskel, there is a C-sharp API for software transactional memory that you should look at. If you are a Java programmer, you should take a look at DSTM2. And irrespective of what technology you use for building systems, I will recommend reading publications on transactional memory by Maurice Herlihy, Simon Peyton-Jones, Victor Luchangco and Mark Moir (there are others, I just picked up the four I see often in the literature).

Finally, we should not ignore the world of message passing. OpenMP and Erlang have been around for a long time and are designed for concurrent programming. OpenMP is an API you can use from C/C++ and FORTRAN to write parallel programs to take advantage of shared-memory architectures.  Erlang is a programming language in which you write processes that communicate exclusively using messages and if you write your Erlang programs correctly, you get the ability to scale to hundreds of processors for free.

Category: .Net, Java, Programming, Tools and Utilities | 1 Comment »