<HTML><HEAD>
<STYLE>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</STYLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-15">
<META content="MSHTML 6.00.6000.16705" name=GENERATOR></HEAD>
<BODY class=hmmessage>
<DIV>Jay, this comment is indeed disturbing. Since, I didn't have anything to do with the Trestle implementation for Windows, I can't really offer an authoritative opinion here. The phrase "the only reason this *might* work" is especially disturbing as it sounds as if the idea was still being tested and not known to be sound. </DIV>
<DIV> </DIV>
<DIV>I've done quite a bit of multi-threaded programming and the complexity gets out of hand quickly without some rigor and the help of a good thread-aware language like Modula-3. When I say rigor, I mean the programmers have to set some ground rules that are enforced throughout the code that will ensure correct multi-threaded operation.</DIV>
<DIV> </DIV>
<DIV>Arbitrarily releasing locks to prevent potential recursive locks seems like a recipe for disaster and hints that the necessary rigor was not established.</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Randy<BR><BR>>>> Jay <jay.krell@cornell.edu> 8/14/2008 6:05 PM >>><BR>How about this comment in the code:<BR> <BR>(*-------------------------------------------------- raw seething windows ---*)<BR>(* NOTE: The helper procedures called by WindowProc lock VBT.mu when calling<BR> various Trestle procedures. They do not hold locks while calling Win32<BR> because it knows nothing about Modula-3 locks and it can, on a whim, call<BR> WindowProc to do something. The only reason this scheme might work is<BR> because we have a single Modula-3 thread that's pulling on the Win32<BR> message queue and calling WindowProc.<BR> <BR> Similarly, we don't bother locking around updates to Child records.<BR> They are updated by the single Modula-3/WindowProc thread.<BR>*)<BR><BR>?<BR>I also need to check if any state has been modified, or cached in locals, with<BR>the locks held that are being released.<BR> <BR> -Jay<BR><BR><BR></DIV>
<DIV>
<HR>
</DIV>
<DIV><BR>Date: Thu, 14 Aug 2008 11:13:25 -0400<BR>From: rcoleburn@scires.com<BR>To: jkrell@elego.de; m3commit@elegosoft.com<BR>Subject: Re: [M3commit] CVS Update: cm3<BR><BR><BR></DIV>
<META content="Microsoft SafeHTML" name=Generator>
<DIV>Jay:</DIV>
<DIV> </DIV>
<DIV>I haven't studied this code in depth, but on the surface I doubt your change is "correct". </DIV>
<DIV> </DIV>
<DIV>I think the more telling problem is that if you look at the body of WinTrestle.Release, it is empty, save for a comment that it is not yet implemented. So, it would seem that if WinTrestle.Acquire is called more than once, you will crash because the locks have not been released.</DIV>
<DIV> </DIV>
<DIV>Further, I don't think it would make sense to release the locks before calling out to Windows, and then reacquire them upon return. The locks are known to Modula-3 and not Windows. Releasing them will allow other competing threads to acquire them while you are in the Windows subsystem and would seem to violate whatever protections were in place per holding the locks. Upon return from Windows, the thread will be back in competition with others to reacquire the locks it gave up and upon success, there is no guarantee that the other threads didn't disturb the state the original thread depended upon.</DIV>
<DIV> </DIV>
<DIV>I would suggest reverting these changes and looking to implement the Release procedure.</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Randy</DIV>
<DIV><BR>>>> Jay Krell <jkrell@elego.de> 8/14/2008 4:26 PM >>><BR>CVSROOT:/usr/cvs<BR>Changes by:jkrell@birch.08/08/14 16:26:59<BR><BR>Modified files:<BR>cm3/m3-ui/ui/src/winvbt/: WinTrestle.m3 <BR><BR>Log message:<BR>release locks when calling out to Win32 to prevent recursive lock acquisition. correct?<BR><BR><BR></DIV></BODY></HTML>