[M3commit] CVS Update: cm3

[Dragiša Durić]

Just because we can do something is not a reason to do it. Minimalistic
philosophy of Modula-3 API is, as opposed to Java for example, one of
it's greatest strenghts.

I still can remember a moment when I opened Java book on Thread class. I
see it in my nightmares from time to time :).

On Fri, 2008-08-15 at 11:41 +0100, Tony Hosking wrote:
> I am unclear as to why this abstraction is needed for Windows threads  
> when it is not needed for pthreads.  Please explain.
> 
> On Aug 15, 2008, at 2:08 AM, Jay wrote:
> 
> >
> > We should probably add a new type Thread.RecursiveExclusiveLock? And  
> > then just use that here?
> > The basic Win32 critical section is such a thing precisely. Not that  
> > it is all that great. But it is widely used.
> > Vista adds the "SRWLock" which is a small read/write lock and maybe  
> > reduced recursive functionality.
> > It is indeed small, just the size of a pointer, whereas a critical  
> > section is fairly large.
> >
> > - Jay
> >
> >
> >
> > Date: Thu, 14 Aug 2008 20:11:19 -0400From: rcoleburn at scires.comTo: jay.krell at cornell.edu 
> > ; jkrell at elego.de; m3commit at elegosoft.comSubject: Re: [M3commit] CVS  
> > Update: cm3
> >
> > Jay:
> >
> > There is the abstraction of multiple concurrent "readers" but only  
> > one "writer".  I actually have such a module that I use sometimes in  
> > my programs.  The idea is one of acquiring/releasing read locks and  
> > write locks.  The difficulty here is in preventing starvation and  
> > usually requires adherence to some rules (again rigor).  By  
> > starvation I mean that writers must wait for all readers to finish  
> > before they get access, so if there is always at least one reader,  
> > the writer will "starve" and never gain access.
> >
> > As for recursive locks, again that is usually indicative of a design  
> > flaw.  I did once implement a system that permitted the same thread  
> > to acquire a lock multiple times, provided that it eventually  
> > released the lock the same number of times that it acquired it.  In  
> > other words, after the first lock, subsequent locks by the same  
> > thread just increment a counter.  Then, unlocks decrement the  
> > counter until it is zero with the final unlock actually releasing  
> > the mutex.
> >
> > In the code you modified, you could implement such a scheme to  
> > handle the recursive locks, provided that at some point the thread  
> > releases for each lock.  The Thread interface has the ability to  
> > note the current thread (i.e., Thread.Self()).  So you could make a  
> > stack of locks by same thread.  Other threads would have to block  
> > until the first thread's lock stack was empty.
> >
> > For example:
> >
> > ACQUIRE:  If resource available, lock resource mutex and put current  
> > thread on granted stack.  Otherwise, if current thread already on  
> > granted stack, push it on stack again and let it proceed.  Otherwise  
> > (this is a new thread wanting access), so push this thread onto a  
> > waiting stack and wait
> 
-- 
Dragiša Durić <dragisha at m3w.org>