<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
<DIV> > What are the Misc/misc calls?</DIV>
<DIV> </DIV>
<DIV>Trestle stuff.</DIV>
<DIV>Search in m3-ui.</DIV>
<DIV>It is in "Misc" that Juno calls .Signal(untilDone).</DIV>
<DIV>Sometimes the entire "misc" call is skipped, or maybe occurs fewer times. That is when it hangs.</DIV>
<DIV>I'm pretty sure.</DIV>
<DIV> </DIV>
<DIV> > The corruption comes outside of GC. It's just that the GC dicovers it.</DIV>
<DIV> </DIV>
<DIV>Agreed.</DIV>
<DIV> </DIV>
<DIV> > The only reason to have it in the CV is to achieve the optimization,</DIV>
<DIV> > so you know to which mutex queue we should transfer the signalled/broadcast thread.</DIV>
<BR>
<BR>
Of course. I should have realized that.<BR>Um..the data is available anyway though, isn't it?<BR>
The thread had to call wait(mutex, condition) in order for signal(condition) to unlink him from the condition's waiters, the waiting thread can store the mutex in itself (he can only be waiting on one condition variable at a time) and the signaling thread can grab that.<BR>
I think.<BR>
<BR>
<BR>
In either case, I'm not too inclined to touch it for this release until we are sure there is a bug, and that looks unlikely at this point. We could try putting back your BroadcastHeap change?<BR>
<BR>
<BR>
It also seems a little gross that the heap lock is a special case recursive mutex.<BR>
It seems like we should have Mutex and RecursiveMutex, have either work with Condition, and have LockHeap/UnlockHeap/BroadcastHeap just be wrappers around that.<BR>
<BR>
<BR>
More generally we should probably try to embelish Thread.i3 with more primitives I think. At least "interlocked" and "once", if not "event" and "semaphore".<BR>
"once" could definitely see a fair amount of use.<BR>
The rest maybe not, maybe they are too primitive and hard to get good use out of, hard to define portably/efficiently.<BR>
<BR>
<BR>
Or maybe LockHeap/UnlockHeap recursive support could/should be removed and just stick with Mutex and Condition and nothing else?<BR>
<BR>
<BR>
Well, reader/writer locks are nice.<BR>
<BR>
<BR>
The "Little Book of Semaphores" seems to suggest ideas like "turnstile", "rendevous" and maybe others, though I'm not sure they are actually easy to think about (I don't seem able to keep up with the author :( ), and possibly a generalization of reader/writer, like an n/m/o lock where you have x classes of code and different numbers of them are allowed to have the lock. Reader/writer is 2 classes with unlimited/1 access. <BR>
There is a case of read/insert/delete that can scale a bit better than reader/writer.<BR>
<BR>
And maybe a "thread local" mechanism?<BR>
<BR>
<BR>
- Jay<BR> <BR>
<HR id=stopSpelling>
CC: m3devel@elegosoft.com<BR>From: hosking@cs.purdue.edu<BR>To: jay.krell@cornell.edu<BR>Subject: Re: [M3devel] Juno/Thread/Win32 notes<BR>Date: Wed, 21 Oct 2009 21:56:21 -0400<BR><BR>
<DIV><SPAN class=ecxApple-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=ecxApple-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=ecxApple-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=ecxApple-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=ecxApple-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=ecxApple-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=ecxApple-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=ecxApple-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=ecxApple-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=ecxApple-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><SPAN class=ecxApple-style-span style="FONT-SIZE: medium">On 21 Oct 2009, at 17:02, Jay K wrote:</SPAN></DIV></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></DIV></SPAN></DIV></SPAN></DIV>
<DIV><BR class=ecxApple-interchange-newline>
<BLOCKQUOTE><SPAN class=ecxApple-style-span style="WORD-SPACING: 0px; FONT: medium Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=ecxhmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">ThreadWin32.m3 almost exactly matches Birrel's design.<BR>The order of two unlocks is reversed. It probably doesn't matter.<BR>He says LockMutex/UnlockMutex are just P/V. Ours is a bit different.<BR>We have queueing on our locks which appears unncessary, but is maybe<BR>with in mind an optimization mentioned but now shown by Birrel --<BR>that of Signal with a lock held transfering a thread right<BR>to the mutex's wait list.<BR></DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>The queueing on mutexes does appear unnecessary, unless the optimization can be achieved.</DIV><BR>
<BLOCKQUOTE><SPAN class=ecxApple-style-span style="WORD-SPACING: 0px; FONT: medium Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=ecxhmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana"> Birrel also has one mutex per condition variable but that<BR>seems to maybe be incidental and not architectural.<BR></DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>The only reason to have it in the CV is to achieve the optimization, so you know to which mutex queue we should transfer the signalled/broadcast thread.</DIV><BR>
<BLOCKQUOTE><SPAN class=ecxApple-style-span style="WORD-SPACING: 0px; FONT: medium Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=ecxhmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana"> I believe there is much room for performance improvement<BR>here, but if it is correct, it is ok for this release.<BR>As well, I believe lock/conditionvariables can be made to work<BR>in threads not created by the Modula-3 runtime, at least with<BR>a dependency on NT4 or Win2000 (QueueUserAPC to trigger alert).<BR>(owner = GetCurrentThreadId instead of T).<BR></DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>Sure.</DIV><BR>
<BLOCKQUOTE><SPAN class=ecxApple-style-span style="WORD-SPACING: 0px; FONT: medium Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=ecxhmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">I put in a bunch of RTIO in Juno.<BR>Whenever it hangs, the Signal call doesn't actually occur.<BR>We have to try to figure out why.<BR>It is something in the Misc/misc calls.<BR></DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>What are the Misc/misc calls?</DIV>
<DIV><BR></DIV>
<BLOCKQUOTE><SPAN class=ecxApple-style-span style="WORD-SPACING: 0px; FONT: medium Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=ecxhmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana"> So ThreadWin32.m3 is fairly well vindicated (except<BR>maybe via some roundabout fashion).<BR> <BR><BR>The heap corruption is now fairly rare in Juno.<BR>I don't know if it is consistent or not.<BR>The contents are, not sure of the address.<BR>I'll debug more.<BR> <BR><BR>My next idea..since I think the corruption involves<BR>copying a pixmap over other data, is to alter all<BR>pixmaps to be composed of specific data, see if that<BR>occurs in the corruption, to try to confirm this<BR>part of my theory.<BR> <BR><BR>If that holds, then the memcpys done by gc could<BR>check for the pattern (actually they could check<BR>anyway, I thought I tried that already, will try again).<BR></DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>The corruption comes outside of GC. It's just that the GC dicovers it. This should really be straightforward to catch, if you can make it occur deterministically.</DIV><BR>
<BLOCKQUOTE><SPAN class=ecxApple-style-span style="WORD-SPACING: 0px; FONT: medium Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=ecxhmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana"> As well, with ThreadWin32.m3 having gotten some fixes,<BR>getting various timestamps of the source tree might be<BR>a good idea.<BR> <BR><BR>With ThreadWin32.m3 fairly well vindicated, we might<BR>declare the quality is high enough asis. ?<BR>But I'd like to keep investigating.<BR>(Anyone else can?)<BR> <BR><BR>The doubt imho is now more cast upon the Win32 Trestle code.<BR>We might even try Cygwin configured to use Win32 threads<BR>and X Windows and see if that has the same bug.<BR> <BR> <BR>Later..<BR> - Jay<BR></DIV></SPAN></BLOCKQUOTE></DIV><BR> </body>
</html>