<HTML><HEAD>
<STYLE><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></STYLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-15">
<META content="MSHTML 6.00.6002.18124" name=GENERATOR></HEAD>
<BODY class=hmmessage>
<DIV>Jay, I notice you say something about Win9x below.</DIV>
<DIV> </DIV>
<DIV>I never had much success with Win9x back in the cm3 v4.1 days. Farshad and company stated that they would only support WindowsNT4.0 back then.</DIV>
<DIV> </DIV>
<DIV>I think it would be fine at this point to just support the newer stuff (Windows NT4.0 / 2000 / XP / Vista / Windows 7) and not worry about the old 9x versions or even NT3.5.</DIV>
<DIV> </DIV>
<DIV>I've been watching all the activity on threading and mutexes. I keep updating from the HEAD branch and rebuilding on XP and Vista to make sure stuff still compiles. I must admit all these low-level changes concern me for the same reasons Olaf outlined a few days ago. </DIV>
<DIV> </DIV>
<DIV>I've not had much time to devote to cm3 lately, but I will try to test using some of my multi-threaded programs as soon as I can. However, I fear it will be hard to tell if something is only "slightly broken" or "slightly misbehaves" because unless you see a crash or obvious behavior flaw, you won't know it is "slightly" broken. </DIV>
<DIV> </DIV>
<DIV>I did contribute a "Mutex Checker" test program a few weeks back. I'll keep running it, but it doesn't test all the alert and condition variable stuff. I think we need some test programs that can prove correctness, but these are going to be hard to develop I fear.</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Randy<BR><BR>>>> Jay K <jay.krell@cornell.edu> 12/11/2009 9:17 AM >>><BR>[was truncated..]<BR>Oh -- it is so you can wait for more than 4 billion<BR>milliseconds, I guess.<BR>The chunk size of the loop is roughly the maximum<BR>time WaitForSingleObject is allowed.<BR>Ok.<BR><BR> <BR>btw, we could also use Win32's native "alert"<BR>mechanism. That would save creating all the alert events.<BR>The downside is that I don't see how to alert a wait<BR>on Win9x. Maybe via some extra arbitrary async pipe i/o?<BR>On NT it's just QueueUserAPC.<BR> <BR> - Jay<BR> <BR><BR></DIV>
<DIV>
<HR id=ecxstopSpelling>
</DIV>
<DIV><BR>From: jay.krell@cornell.edu<BR>To: m3devel@elegosoft.com<BR>Date: Fri, 11 Dec 2009 14:05:56 +0000<BR>Subject: [M3devel] win32 AlertPause polls instead of one big wait?<BR><BR>
<STYLE>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Verdana;}
</STYLE>
Anyone know why Win32 AlertPause uses a polling loop instead of just one wait?<BR> <BR> <BR>I'm not sure this is going to work out, but:<BR> I'm "rewriting" stuff to use a separate event for alerting.<BR> alertable goes away<BR> There will be two events: <BR> waitEvent, for condition variables<BR> alertEvent, for alerting <BR> <BR> <BR>roughly speaking:<BR> <BR> <BR>AlertPause: WaitForSingleObject(alertEvent)<BR>AlertWait:<BR> alerted := WaitForMultipleObjects({alertEvent, waitEvent}) == WAIT_OBJECT_0)<BR>Alert(t): SetEvent(t.alertEvent);<BR>TestAlert: alerted := WaitForSingleObject(alertEvent, 0);<BR> <BR> <BR>It seems simple enough.<BR>That shows all the ingredients.<BR>That'll eliminate a lot of the global locking.<BR>And then one "last" iteration to use the Java code for condition variables and the global lock will be gone.<BR>You can't just use the Java code because it doesn't include alertability.<BR>You can't, I believe, draw a parallel to the pthreads code, because the Java code doesn't maintain a wait list with a mutex.<BR>The waiter/tickets/counter stuff is pretty clever -- I don't understand it yet..<BR> <BR> <BR> - Jay<BR><BR></DIV></BODY></HTML>