Book Reviews
The Art of Multiprocessor Programming by Maurice Herlihy and Nir Shavit
ISBN:
978-0123705914
Publisher:
Morgan Kaufmann
Pages:
528
The free lunch is indeed over. As the processor manufacturers reached the practical limits of single core designs the new multicore architectures entered the mainstream. The challenge for us software developers is to make programs that scale on all these multiple cores. It's a challenge that calls for radically different technologies and a different kind of programming. The Art of Multiprocessor Programming turned out to be a really good introduction to the building blocks used for parallelization. But make no mistake - it's a hard read.
Confessions up front; I didn't read The Art of Multiprocessor Programming cover to cover. Rather, I read the parts I found of immediate interest (different lock-algorithms, spin locks, futures, software transactional memory) and has kept the book as a reference. The book dives deep into the different aspects and solutions for multiprocessor programming. It's the kind of book you need for writing robust synchronization mechanisms, parallel run-time systems or developing a modern compiler. I generally found the examples and text pedagogical and well-though out. That said, The Art of Multiprocessor Programming is probably too theoretical and detailed for many application programmers. I would still recommend it though; just like I don't write binary search trees or linked-lists on a regular basis, I don't expect to write many Filter locks myself either. Yet a decent understanding of the algorithms and concepts are a must for writing solid code in traditional imperative languages on multiprocessor architectures.
My main concern with the techniques and algorithms discussed in the book is how hard they are to get right. Worse, all techniques require us to write our programs differently for multicores than what we would have done on a traditional old-school single core chip; the programmer has to make an active choice to introduce parallelism. Traditional concurrency libraries (e.g. java.util.concurrent ) simply won't scale on hundreds or thousands of processors. Instead I believe that the real solution is to use technologies that allow the natural parallelism of the problem to be expressed. Such a solution wouldn't differentiate between single and multiple cores with respect to the coding constructs and design. Rather, the technology would be able to scale the program automatically depending on available hardware resources. Such technologies already exists, and yes, I'm talking about Erlang . Of course Erlang isn't turtles all the way down ; somebody (i.e. the virtual machine) do has to care about scheduling and synchronization. And to implement such a system, we've come full-circle and it's where this book comes in as a valuable and highly recommended aid.
Reviewed October 2010
