Re-creating threading and concurrency knowledge in increasingly popular languages

Question

I am primarily a Java developer, and I've been reading a lot of in-depth work on threads and concurrency. Many very smart people (Doug Lea, Brian Goetz, etc) have authored books on these topics and made contributions to new concurrency libraries for Java.

As I start to learn more about Python, Ruby, and other languages, I'm wondering: does all of that work have to be re-created for these languages?

Will there be, or does there need to be, a "Doug Lea of Python," or a "Brian Goetz of Ruby," who make similarly powerful contributions to the concurrency features of those languages?

Does all of this concurrency work done in Java have to be re-created for future languages? Or will the work done in Java establish lessons and guidance for future languages?

Answer 1

The basic principles of concurrent programming existed before java and were summarized in those java books you're talking about. The java.util.concurrent library was similarly derived from previous code and research papers on concurrent programming.

However, some implementation issues are specific to Java. It has a specified memory model, and the concurrent utilities in Java are tailored to the specifics of that. With some modification those can be ported to other languages/environments with different memory model characteristics.

So, you might need a book to teach you the canonical usage of the concurrency tools in other languages but it wouldn't be reinventing the wheel.

Answer 2

Keep in mind that threads are just one of several possible models for dealing with "concurrency". Python, for example, has one of the most advanced asynchronous (event based) non-threaded models in Twisted. Non-blocking models are quite powerful and are used as alternatives to threads in most of the highest scaling apps out there (eg. nginx, lighttpd).

Your assumption that other popular languages need threads may simply be a symptom of a java centric (and hence thread-centric) world view. Take a look at the C10K page for a slightly dated but highly informative look at several models for how to handle large volumes of concurrent requests.

Answer 3

This is not flame bait, but IMHO Java has one of the simpler and more restricted models for threading and concurrency available. That's not necessarily a bad thing, but at the level of granularity it offers it means that the perspective it gives you of what concurrency is and how to deal with it is inherently limited if you have a "java centric" view (as someone else put it).

If you're serious about concurrency, then it's worth exploring other languages precisely because different models and idioms exist.

Some of the hottest areas are lock-free programming (you'll see a lot of it, but often done badly, in C++) and functional programming (which has been around for a while but arguably, is becoming increasingly relevant. A prime example in the case of concurrency is probably Erlang).

Answer 4

I think the answer is both yes and no. Java arguably has the most well-defined memory model and execution semantics of the most commonly used imperative languages (Java, C++, Python, Ruby, etc). In some sense, other languages either lack this completely or are playing catch-up (if that's even possible given the immaturity of the threading models).

C++ is probably the notable exception - it has been treading the same ground for C++0x and has possibly gone beyond the current state of the Java model from my impression.

I say no because the communities are not isolated. Many of the guys working on this stuff are involved (at least from a guidance point of view, if not from a direct hand in the specs) in more than one language. So, there is a lot of crosstalk between guys working on JMM and guys working on C++0x specs as they are essentially solving the same problems with many of the same underlying drivers (from the hardware guys at the bottom and the users at the top). And I'm pretty sure there is cross-talk at some level between the JVM / CLR camps as well.

As others have mentioned, there are also other models for concurrency: actors in Erlang and Scala, agents/STM in Clojure, FP's rise in F#, Scala, Haskell, the CCR and PLINQ stuff in CLR land, etc. It's an exciting time right now! We can use as many concurrency experts as we can find I think.... :)

Answer 5

Kamaelia is a project (which I started, and continue to work on) that has specifically the goal of making concurrency a tool you want to use, rather than a pain to use. In practical terms this means that it is primarily a shared-nothing model with message passing model (based on a world view from Occam & Unix pipes).

Underlying that goal is a desire to make concurrency easy to use for the average developer, shielding them from the nastier problems caused by a number of approaches to concurrency. (There's a bunch of presentations on slideshare explaining the why & how there)

Additionally it provides a simple software transactional memory model for the situations where you must share data, and uses a deliberately simple API.

Kamaelia's primary implementation is in python, with a toy implementation in Ruby & C++. Someone else has ported the underlying approach to E and also to Java. (though the Java person has disappeared) (The toy implementations are sanity checks the ideas can work in other languages, if needing to be recast as local idioms)

Perhaps your question shouldn't be "what can these languages learn", but "what can the Java community learn by looking elsewhere?". Many people who learn python are liguistically immigrants from elsewhere and bring their knowledge of other languages with them, and so from where I sit it looks like python already looks out to other languages for inspiration.

Picking something concrete, for example, this speak and write application - which is a tool for teaching a small child to read and write, based around pen input, handwriting recognition, and speech synth - uses several dozen concurrent subsystems, runs at an acceptable speed on a single core machine, would be easily amenable to running on a many-core machine. However, the reason for the number of concurrent subsystems however has nothing to do with "wanting to make the application parallel", but more to do with "How can I make the application easier to write, extend and maintain?". The fact it ends up embarassingly parallel is a secondary bonus.

There's a full tutorial - Pragmatic Concurrency - linked from the front page. (Notes, slides, video & code bundle)

The model can be improved, and suggestions are welcome - life would be very boring if we all just "stopped" trying to make better tools - but ignoring what already exists seems a little ... parochial. If that seems a little harsh, please look at today's dilbert.

:-)