<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
The comment is false. It does call out to Windows with lock held.<BR>
<BR>
- Jay<BR><BR><BR>
<HR>
<BR>
From: hosking@cs.purdue.edu<BR>To: jay.krell@cornell.edu<BR>Date: Fri, 15 Aug 2008 12:51:54 +0100<BR>CC: m3commit@elegosoft.com<BR>Subject: Re: [M3commit] recursive locking in WinTrestle<BR><BR><BR>
<DIV><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV style="WORD-WRAP: break-word"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV>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.</DIV></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></DIV></SPAN></DIV><BR>
<DIV>
<DIV>On Aug 15, 2008, at 12:29 PM, Jay wrote:</DIV><BR class=EC_Apple-interchange-newline>
<BLOCKQUOTE><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">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:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</A><BR>> To:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</A><BR>> Date: Fri, 15 Aug 2008 11:41:23 +0100<BR>> CC:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:m3commit@elegosoft.com">m3commit@elegosoft.com</A><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:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:rcoleburn@scires.comTo">rcoleburn@scires.comTo</A>:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</A><BR>> > ;<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:jkrell@elego.de">jkrell@elego.de</A>;<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:m3commit@elegosoft.comSubject">m3commit@elegosoft.comSubject</A>: 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></DIV></SPAN></BLOCKQUOTE></DIV><BR></body>
</html>