[M3commit] recursive locking in WinTrestle

[Jay]

My understanding, could be all wrong:
The thread is not intended to hold no locks, just not while calling out.
The thread obeys the usual Trestle locking rules.
   I *believe* it is not a special thread, it just happens to be the thread that all gui stuff happens on. I believe other threads can still do some Trestle stuff, just not that result to calls to Windows.
It's obvious why this is happening, from the callstack.
Less obvious what to do about it.
 
Is reentrance and working on some data while already working on that data on the same thread really always such a terrible thing? If you know where the points you might reenter from are?
That is, while data is locked, it can and will likely go through some states in which it is "incoherent", in which it is "in the middle" of being updated. But isn't the incoherence likely to be over short runs of code? Not likely to be at a point where a function is called? Otherwise, it becomes difficult for even the holder of the lock to keep things straight. I mean, you know, data is usually coherent, but must often pass through incoherence between coherent states. I would expect very little code to deal with the incoherence, for the updating code to be as short as possible.
 
 - Jay



CC: m3commit at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3commit] recursive locking in WinTrestleDate: Fri, 15 Aug 2008 21:03:41 +0100


Then the question is why that thread, which is intended *not* to hold any locks so it *can* call out to Windows, actually does hold a lock.  Sounds like a bug to me.  The fix is to figure out where it is acquiring the lock and deduce what should actually be happening.

On Aug 15, 2008, at 8:37 PM, Jay wrote:

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/b10e044e/attachment-0002.html>