[M3commit] recursive locking in WinTrestle

[Tony Hosking]

Umm, no, we do not need this for pthreads, since the windowing on non- 
Windows system does not have the problem you describe.   I think that  
a deeper understanding of the WinTrestle code is needed here.  From  
reading the WinTrestle comments, it says that calls out to Windows are  
performed by a special thread that has no locks held.  So, how can a  
call-back from Windows (presumably within the same thread) manage to  
be in a state where the thread has locks.  It sounds like there may be  
something broken in the design of WinTrestle, but this is NOT a  
motivation to complicate the Thread interface.  I suggest that effort  
be focused in WinTrestle rather than making a global hack that is not  
justified.

On Aug 15, 2008, at 12:29 PM, Jay wrote:

> There is a case, trivial to hit, in WinTrestle that calls out to  
> Windows with some locks held, Windows calls back into Trestle,  
> Trestle attempts to acquire the locks again, and it dies.
>
> It should be easy to implement...
>
> All it takes to hit this in WinTrestle is to copy (as in copy/paste)  
> twice in the same app.
> My example was from the same control but that isn't necessary.
> Just copy from one Trestle control and then copy from another and it  
> hits.
>
> A careful review might reveal that is safe to release the locks,  
> call out, reacquire.
> The comments indicate a general non-calling out with locks held, but  
> the implementation does not quite agree.
>
> pthread has this: PTHREAD_MUTEX_RECURSIVE
> It's just bogus?
>
> One lock type -- nonrecursive mutex -- is really all you need?
>
> I assume a multi-reader/single-writer is also useful. In fact, a  
> mutex can just be a reader/writer where everyone is a writer, though  
> that might waste space (given that Windows now has a reader/writer  
> lock that is just the size of a pointer, maybe not).
>
> - Jay
>
> > From: hosking at cs.purdue.edu
> > To: jay.krell at cornell.edu
> > Date: Fri, 15 Aug 2008 11:41:23 +0100
> > CC: m3commit at elegosoft.com
> > Subject: Re: [M3commit] CVS Update: cm3
> >
> > 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
> >
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20080815/16d104f5/attachment-0002.html>