There are ripples spreading across the concurrency pond, some provoked by this series, and there’s this one issue that keeps coming up: “Concurrency” vs. “Parallelism”. It is asserted that they’re not the same thing, and that this is important.
[This is part of the Concur.next series.]
From the wilds of Haskell-land comes Parallelism /= Concurrency by (I believe) Simon Marlow. Ted Leung’s piece is similarly titled: Concurrency => Parallelism; it in turn references Peter Van Roy’s Programming Paradigms for Dummies: What Every Programmer Should Know (PDF).
I found Van Roy’s paper worth reading, once you get past all the verbiage about how wonderful what he’s about to tell you is; his discussion of P vs. C was the clearest I’ve encountered.
I’m with Ted when he says “From where I sit, this is all about exploiting multicore hardware.” I’d modify that by adding “... in a way that has a low barrier to entry for typical application programmers.” And on that basis, I’m really having a hard time following the C-vs.-P narrative where it seems to lead.
Marlow’s argument is that if you are so fortunate as to be living in Haskell’s benevolent side-effect-free glow, “you are free to run different parts of the program at the same time without observing any difference in the result.” I.e. it’s deterministic, which is a Good Thing. Models based on processes and actors, on the other hand, accept that they execute in an unpredictable order, maybe parallel or maybe not, and are thus non-deterministic, which Must Be Bad.
Which, if true, means that Erlang and Clojure, for example, couldn’t possibly work. Well, except for they do. Oh, well, Marlow allows, “STM is better than locks, and message passing has its advantages”.
(And tuple spaces must be even more pathetic-and-hopeless, because they’re even less deterministic; you don’t even know where the messages you’re sending are going to end up.)
I think that the point that Marlow and the FP tribe are trying to make is important; an important virtue of their approach is that the speedup due to concurrency/parallelism can to some degree be achieved automatically by the system; the process/actor approach on the other hand requires the developer to think about what happens in parallel with what and who has to tell whom what to do. (Having said that, Marlow goes on to discuss “par/pseq” and Nested Data Parallelism, both of which seem to put some of the parallelism under developer control.)
So the jury is out; I’d be unsurprised if FP turns out to be an important building block for the Java of Concurrency. But I’d be quite surprised if there turned out to be no role for the process/actor approach. At least some in the Haskell community seem to agree.
This sort of wholesale dissing of a family of approaches that seems empirically to work in some important application scenarios really isn’t helpful.