From Concurrent to Parallel

Recorded at:

Yet I'm still confused of how the work stealing would work when multiple workers compele to steal the task from the tail of a single workers dequeue?

God, that was awful. I'll paraphrase it here: Java sucks as a language for massive concurrency, but we don't want to face that, so, instead, we'll talk about some ad-hoc approaches to various problems that are already solved and working, and build a library for them as if it were original. Only those problems are not the everyday problems most of us face, and, as said, are solved for those who need them.

I particularly liked when he mentioned that threads are expensive, as if this was basic truth, instead of a consequence of various characteristics of Java.

Now, the library is nice -- actually, very good, and if I hadn't read about it before and the presentation was a bit more honest about the very limited scope of what they were doing, it would be a great presentation.

For those still left looking for effective massive concurrency, it seems Erlang and the like are still it.

Daniel, while I also have some qualms as to the utility and applicability of this particular library, I have to take issue with your criticism of this presentation.

First, if Java "sucks as a language for massive concurrency", it's because all mainstream languages, which are largely imperative and OO, "suck for massive concurrency".

I'm not sure what you mean when you say the approach described is "ad hoc", or that anybody claimed that it was original. In fact the speaker alluded to previous approaches implemented in other languages at the beginning of the talk. My reservation is that this is not applicable to "everyday problems" but I believe the point the speaker is trying to make is that this WILL be the everyday problem as we face the challenge of massively parallel hardware.

The fact that threads are expensive is a basic truth (they are more expensive than not using threads). This truth stems from operating system implementation, and is possibly worsened by language implementation. If you could say anything about Java, it is not that it does not have a superb VM. Java's VM is best in class, has had massive engineering years poured into it by some really brilliant engineers, and beats the pants of other languages/VMs that could be considered alternatives to Java/JVM: Ruby, Python (both of which have been plagued by infamous "global interpreter locks"), and probably anything else out there.

Perhaps you have some antiquated ideas about Java from 1997? Let's say the Java runtime was perfect, there is still thread overhead at the OS level. This is not specific to Java. All languages that use threads (including natively compiled languages) have to deal with this. There are of course many alternatives available: fibers, events, async IO, etc. But your claim seems to be that threads are expensive specifically due to characteristics of Java, not that other approaches should be used.

Of course if you are looking for "massive concurrency" look at Erlang. Look at a lot of things. Erlang is conspicuously NON-mainstream, so Erlang developers are obviously NOT the target of this talk. If you have been writing massively concurrent Erlang for the last 10 years, well, I guess you get a pat on the back, but you are certainly the exception and I don't get what your beef is with the Java community building new libraries for themselves.

By the way there are languages that suck less for concurrency on the JVM, including Clojure and (gasp) Erjang.