[M3devel] concurrency

[Daniel Alejandro Benavides D.]

Hi all:
In fact Archlinux use it too:

https://bbs.archlinux.org/viewtopic.php?id=655

This a good example of their use, in fact there NPTL server and client, I can run it in my system (ubuntu804 hardy x86):

http://www2.cddc.vt.edu/linux/distributions/archlinux/other/cvsup/

Interesting I can't do it ldd, but can run its CLI.

Thanks in advance

--- El mié, 6/7/11, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribió:

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