[M3devel] concurrency

[Tony Hosking]

On Jul 4, 2011, at 9:39 AM, Hendrik Boom wrote:

> There was a lot of discussion on problems with concurrency when we wen 
> to pthreads implementation so that we could make use of multiple CPUs.
> After a while disuccion sttopped.
> 
> Have these problems all been resolved yet?

There are issues that have been reported but which I've not had time to explore.
Too busy trying to finish my book on GC.  I hope to have time to work on things soon.

> If I recall correctly, there was a problem with one program, cvsup, 
> using fork as well as threads.  This worked with green threads, but not 
> with pthreads.  Has cvsup been rehabilitated in some way?

cvsup is badly behaved with respect to POSIX semantics for fork and threads.  It still needs to be fixed rather than making M3 threads support its bad behavior.

> How do pthreads interact with the garbage collector?  Or are there 
> several garbage collectors with different interaction modalities?

The current garbage collector expects to be able to stop all the threads in order to *initiate* a garbage collection by scanning their stacks.  Unfortunately, getting pthreads to stop reliably is difficult on some operating systems (BSD derivatives appear to be bad at this, but Windows, Linux and OSX seem to function well enough).  [This shortcoming is a problem also for the Boehm collector for C/C++.]  In CM3 the same garbage collector is used whether for pthreads or user threads.

The best way to get M3 threads to play nicely on all OS would be to avoid thread stopping mechanisms that expect cooperation from the OS and simply to use explicit polling inserted by the compiler at calls and backward branches to decide if the thread should suspend itself.  To handle calls to external code not generated by the M3 compiler we would also need to have a thread atomically post the fact that it is in external code on entry and un-post that fact on return (i.e., at calls to <*EXTERNAL*>).  To make that synchronization efficient we need to use CAS or LL/SC atomicity primitives (rather than relying on pthread_mutex calls).  I still need to fix all the atomics support in CM3 to be able to do that properly.

So, my list of TODOs includes:

1) Explore (and perhaps fix) reported issues with the current pthreads implementation [short-term]
2) Commit fixes to CM3 support for atomics [medium-term]
3) Switch CM3 threads over to cooperative explicit suspension rather than signal-based suspension [long-term]