
<html>

<head>

<style>

.hmmessage P

{

margin:0px;

padding:0px

}

body.hmmessage

{

FONT-SIZE: 10pt;

FONT-FAMILY:Tahoma

}

</style>

</head>

<body class='hmmessage'>

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.<BR><BR>It should be easy to implement...<BR><BR>All it takes to hit this in WinTrestle is to copy (as in copy/paste) twice in the same app.<BR>My example was from the same control but that isn't necessary.<BR>Just copy from one Trestle control and then copy from another and it hits.<BR><BR>A careful review might reveal that is safe to release the locks, call out, reacquire.<BR>The comments indicate a general non-calling out with locks held, but the implementation does not quite agree.<BR>

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

</html>