Concurrent GC

Concurrent GC

[Jonathan Bryant]

Apologies if this was sent out a few times: my email client and I are  
not getting along at the moment... :-\

My two cents,

> It's very nice to have a concurrent run-time system, and we know how
> to do it (at significant cost), but it's not really worth the trouble
> until we have an answer to this question: what programming language
> features do we put on top of it?
>
> Shared memory with threads, locks, and conditions just doesn't cut
> it, in terms of writing programs that work.
>

For writing shared memory concurrent programs in OCaml, the Event  
module is a far better fit than locks, mutexes and conditions (oh,  
my!).  It fits the functional paradigm much better and makes program  
design far easier to reason about.  Even simple programs can benefit  
(design wise) from its use.  One of the major advantages is that it's  
defined the same way as most of the other major types in the language  
(lists, sets, etc.): recursively, so it flows natrually from the  
language.  For example, in C/C++/Java (shared memory concurrency), an  
algorithm such as merge sort is tricky, and parallelizing it is  
downright nasty, but in OCaml with the Event module (message passing  
concurrency), merge sort borders on trivial, and parallelizing it is  
almost as simple because the recursion of the algorithm and the  
recursion of the parallelism go hand in hand.  Try it and you'll see.

Mutexes, conditions, and locks really only need to be there for  
transliterating sequential, array based parallel code, but if you are  
doing that, the question really is why?  OCaml outperforms C pretty  
much everywhere but that, and the true benefits of OCaml in this  
situation (cleanliness, safety, readability, etc.) are much better  
exploited by rethinking the algorithm using message passing.  I feel  
that the (possible) slight hit in speed is completely justified by  
the numerous other benefits of the Event module.


> I understand where you're coming from, but this point of view  
> implies, I think, an inappropriate division of labor between  
> language designers and language users.  I agree, ordinary shared- 
> state concurrency with threads is a disaster.  But the burden of  
> figuring out how to write concurrent programs in a reasonable way  
> is not just the responsibility of the language designer --- library  
> writers can come up with good abstractions to take advantage of  
> threads as well.
>

Again, great abstractions to take advantage of these multi-cored  
processors is already in the OCaml standard library: the Event  
module.  All that we need is the ability to actually take advantage  
of it.


> ...threads with real concurrency.  Right now, ocaml doesn't provide  
> that, and it's a real weakness of the language.  The lack of a  
> concurrent GC, in my opinion, stifles innovation in this area...
>

Agreed.

--Jonathan Bryant