[M3commit] recursive locking in WinTrestle

[Jay]

The comment is false. It does call out to Windows with lock held.
 
 - Jay



From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Fri, 15 Aug 2008 12:51:54 +0100CC: m3commit at elegosoft.comSubject: Re: [M3commit] recursive locking in WinTrestle


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_RECURSIVEIt'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/ae1cbdc5/attachment-0002.html>