<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
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>
<BR>
<BR>Birrel also has one mutex per condition variable but that<BR>seems to maybe be incidental and not architectural.<BR>
<BR>
<BR>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>
<BR>
<BR>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>
<BR>
<BR>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>
<BR>
<BR>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> </body>
</html>