[M3devel] concurrency

[Daniel Alejandro Benavides D.]

Hi all:
I would go for the lower over head in Modula-3 lite implementations as legacy systems:
http://readlist.com/lists/gentoo.org/gentoo-user/12/62906.html

Currently the only thing replacement of CVSup is not ahead of it, in the server side which is precisely the point of rewriting it (Modula-3 big footprint and complexity), as for that I know, there could be some improvement over it but the needed changes to the server could diminish the advantage.

The only thing they don't like of CVSup is the disk usage overhead, but  this is something inherent to the application if I may say so, even more, if development were continued perhaps dcvs could a way to address somehow that (given the client replacement doesn't affect the project too much).
But current support for them is wacky AFAIK pm3 is broken, so this is a plus over it, and a plus in cm3 against java but not C.

http://forums.pcbsd.org/archive/index.php/t-3416.html

Anyways, there should be some application to rescue from their repositories so they keep it alive (shouldn't we?):
http://libresoft.dat.escet.urjc.es/cvsanal/freebsd-cvs/index.php?menu=Statistics

Thanks in advance

--- El mié, 6/7/11, Tony Hosking <hosking at cs.purdue.edu> escribió:

> De: Tony Hosking <hosking at cs.purdue.edu>
> Asunto: Re: [M3devel] concurrency
> Para: "Hendrik Boom" <hendrik at topoi.pooq.com>
> CC: m3devel at elegosoft.com
> Fecha: miércoles, 6 de julio, 2011 08:47
> 
> 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]
> 
> 
>