The only ones I can think of off-hand are these two. The second one isn't really about parallel/concurrent/distributed programming per se, but rather about using Intels Threading Building Blocks - good book if that's what you want to do, but not very useful if not. The first book is interesting and covers a lot of ground (covering general techniques and algorithms as well as specific implementations with OpenMP, MPI and Java's facilities), but I liked Art of multiprocessor programming more, probably because it has a more beginner friendly teach everything from the very beginning approach.

http://www.amazon.com/Patterns-Parallel-Programming-Timothy-...

http://www.amazon.com/Intel-Threading-Building-Blocks-Parall...

Integrating parallelism into a language is an easy sell for me. And, I like his points, but what what is the biggest news to me is that they are integrating Cilk Plus into g++: http://software.intel.com/en-us/articles/intel-cilk-plus/ At first I thought they were open-sourcing the current Cilk implementation that is a part of Intel's C/C++ compiler, but I think that is still proprietary.

Intel, as company, still has a mixed message when it comes to shared-memory parallel programming, as evidence by their Parallel Building Blocks: http://software.intel.com/en-us/articles/intel-parallel-buil...

Thread Building Blocks was an internal thing - which it appears that the author was a part of. He literally wrote a book on it: http://www.amazon.com/Intel-Threading-Building-Blocks-Parall... The solution he's championing is from Cilk Arts, who Intel purchased back in 2008. But this article makes no mention of Array Building Blocks, which is the rebranding of Rapid Mind, which Intel also purchased in either 2008 or 2009.

If you want to read papers on multithreaded programming that were almost before their time, read about the Cilk project back when it was pure research, before it was spun off into a company which Intel bought. Google Scholar can help: http://scholar.google.com/scholar?q=cilk "The implementation of the Cilk-5 multithreaded language" is a particularly good paper.

Maybe I'm naive, but I don't think the problem is what everyone always says - that parallel programming is super hard and most programmers cant effectively program for multicore systems. Instead I think the problem is one of education and training. How many programmers actually get decent training and education in multicore programming? I don't think its very many. Of all the programmers complaining how hard it is to write effective multicore programs, how many have actually read books and research papers on the subject? Again, I'd wager not many.

For example, In my four year computer science degree, a lot of time was spent on high level languages like Java, C, C++, Haskell, even prolog. A good bit of time was spent on low level details (two computer architecture modules, an "advanced" computer architecture module, an assembly programming module). Some time was spent on computability, complexity and parsing. Of course, we had a number of math modules too, including probability, statistics and linear algebra. A lot of time was spent on object oriented programming, data structures and algorithms. A little bit of time was spent on other topics like network programming, databases, operating systems (we did cover deadlock and some concurrent programming stuff in great detail here) and AI. The rest was split between single (optional!) modules on niche areas: digital signal processing, cryptography, compression, 3d graphics and so on.. including concurrent programming.

We spent so much time learning how to program sequentially, why would anyone even suggest that we should be able to program for multicore systems? Were we given years of training in parallel programming languages, algorithms, data structures and libraries? Nope. Instead the time was spent on sequential programming. Of course its going to be hard to program for multicore!

Heres a car analogy:

Its like spending years learning to drive tractors, expecting that you can then drive formula one cars.

Some problems simply don't make much sense to try and solve with parallel programming. Some problems do, but we're not properly educated to spot these effectively, to know what data structures are appropriate and what algorithms we should use, nevermind things like testing and debugging parallel software.

As an aside, if performance is what we're trying to achieve with multicore programming, then we need to be taught about efficient cache usage too! Misuse of the processor cache kills multicore performance and popular software development principles, like object-oriented programming actually works against the processor cache! Ugh.

There is plenty to help us effectively program for multicore. A short (and very incomplete) list:

    - monitor based concurrency (mutexes, semaphores, condition variables + threads); usually not the best option
    - Software Transactional Memory; replace manual synchronisation with transactional access to shared memory
    - Message passing; multiuple threads/tasks communicating through immutable messages (being immutable means that synchronization concerns are minimized)
    - Dataflow languages/libraries where data "flows" through computational nodes and many streams of data can flow through in parallel (each node can be processing at the same time)
    - Tools and libraries such as OpenMP, OpenCL and Intel Threading Building Blocks
    - Languages with a focus on parallel programming like Erlang and Clojure (I especially like Clojures view on *time*)
    - Languages with built-in immutable data structures help make synchronisation less painful. Same goes for atomic data structures.
    - Entity Systems[1] are actually surprisingly suited for multicore programming, IMHO

I would suggest everybody to pick up the book The Art of Multiprocessor Programming[2] and get an introduction to the basic concepts. After that it depends on what you want to do, but if you're a C++ programmer, I would suggest the intel threading building blocks book[3].

[1] http://t-machine.org/index.php/2007/09/03/entity-systems-are...

[2] http://www.amazon.com/Art-Multiprocessor-Programming-Maurice...

[3] http://www.amazon.com/Intel-Threading-Building-Blocks-Parall...