Next in Concurrency

Question

For past year I have been working a lot on concurrency in Java and have build and worked on many concurrent packages. So in terms of development in the concurrent world, I am quite confident. Further I am very much interested to learn and understand more about concurrent programming.

But I am unable to answer myself what next? What extra should I learn or work on to inherit more skills related to Multi-core processing. If there is any nice book (read and enjoyed 'concurrency in practice' and 'concurrent programming in java') or resource's related to Multi-core processing so that I can go to the next level?

Answer 1

Disclaimer - I'm not a concurrency expert, but my co-author is, I'm parroting him :-)

Since you've read Doug Lea's and Brian Goetz's books then you've definitely covered the best material out there to date.

Going forwards, there's the new concurrency enhancements in Java 7. Most noticeably the Fork/Join framework and the new asynchronous NIO APIs.

Java 8 will introduce further concurrency improvements with lambdas/parallel collections.

Another thing to seriously look at is alternative ways of dealing with concurrency. To be blunt, Java's 'lock mutable objects' approach is always going to be error prone, no matter how much the APIs are improved. So I recommend looking at Scala's actor model and Clojure's STM as alternative ways to deal with concurrency issues whilst maintaining interoperability with Java.

[warning --> self advertisement]So I'll naturally recommend our upcoming book, The Well-Grounded Java Developer, which covers all of the things I mentioned above :-).[/warning]

Lest I forget, Groovy also has a highly recommended Gpars lib, I haven't used it personally though.

Answer 2

The D programming language provides two paradigms for concurrent programming, both of which have their uses and are rather interesting.

std.concurrency provides message passing with no default memory sharing. All global and static variables in D are thread-local by default and spawn and send do not allow sending messages that contain mutable pointer indirection. Limited sharing can be obtained via the shared keyword, which entails additional checking by the type system. Outside the safe dialect of the language you can force classic C/Java-style global/shared variables using the __gshared keyword, but all bets are off then as far as race safety. This model is detailed in a free chapter of Andrei Alexandresu's book "The D Programming Language".

std.parallelism is less safe but in some ways more flexible than std.concurrency and is geared specifically towards multicore data and task parallelism for increasing data processing throughput rather than general-case concurrency. It features a parallel foreach loop, asynchronous function calls, parallel reductions, etc. It provides mechanisms to make it easier to write race-safe code but doing so still requires some degree of discipline.

A more thorough discussion about the two major multithreading paradigms in D can be found in my recent article on the subject.

Answer 3

I'd strongly suggest you go and take a look at Clojure

The approach to concurrency is very novel, and in my view a significant advance on what you see in Java and most other languages. Some key points:

• Identity and state are separated - OOP complects object identity with it's current state in the form of mutable member variables. Clojure strictly separates identity (managed references) and state (immutable data structures) in a way that significant simplifies development of reliable concurrent programs.
• Persistent immutable data structures - because everything is immutable, you can take a snapshot of data / state at any time and be assured that it won't get mutated underneath you. But better than that - they are persistent data structures that share data with previous versions. As a result, operations are much closer to O(1) rather than the O(n) you would pay for a copy-on-write strategy for immutable data.
• Software transactional memory - rather than using locks, you just enclose code in a (dosync ...) block and they are automatically run as a transaction. No risk of deadlocks, and no need to develop complex locking strategies. This is a massive win, especially when combined with the immutable data structures above. Effectively, Clojure implements multi-version concurrency control in its STM.
• Functional programming paradigm is used to make it much easier to write reliable concurrent code. Basically if you take an immutable data structure, run it through a pure function and output a different immutable data structure, then your code is guaranteed to be safe for concurrency.

I'd suggest watching this video as an introduction

Answer 4

Take a look at the Scala language, which extends Java and runs on the JVM. It borrows the notion of "Actors" from Erlang, and gives good capability for handling concurrency failures.

Answer 5

If you want to take it to a whole new level, you might want to look into programming with CUDA.

This allows you to distribute your algorithms over hundreds of processing cores on your graphics card rather than the few main CPU cores. There are even Language bindings which apparently make it relatively easy to accelerate high level languages like python using GPGPU techniques.

Answer 6

Programming Concurrency on the JVM: Mastering Synchronization, STM, and Actors discusses concurrent programming in Scala, Clojure, JRuby and Groovy.
You will get a pretty solid understanding of different approaches for concurrency.

Where is your smile?