[M3commit] CVS Update: cm3

[Tony Hosking]

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