[M3devel] win32 AlertPause polls instead of one big wait?

[Randy Coleburn]

Jay, I notice you say something about Win9x below.
 
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.
 
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.
 
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.  
 
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.  
 
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.
 
Regards,
Randy

>>> Jay K <jay.krell at cornell.edu> 12/11/2009 9:17 AM >>>
[was truncated..]
Oh -- it is so you can wait for more than 4 billion
milliseconds, I guess.
The chunk size of the loop is roughly the maximum
time WaitForSingleObject is allowed.
Ok.

 
btw, we could also use Win32's native "alert"
mechanism. That would save creating all the alert events.
The downside is that I don't see how to alert a wait
on Win9x. Maybe via some extra arbitrary async pipe i/o?
On NT it's just QueueUserAPC.
 
 - Jay
 


From: jay.krell at cornell.edu 
To: m3devel at elegosoft.com 
Date: Fri, 11 Dec 2009 14:05:56 +0000
Subject: [M3devel] win32 AlertPause polls instead of one big wait?

Anyone know why Win32 AlertPause uses a polling loop instead of just one wait?
 
 
I'm not sure this is going to work out, but:
  I'm "rewriting" stuff to use a separate event for alerting.
  alertable goes away
  There will be two events: 
    waitEvent, for condition variables
    alertEvent, for alerting 
 
 
roughly speaking:
 
 
AlertPause: WaitForSingleObject(alertEvent)
AlertWait:
   alerted := WaitForMultipleObjects({alertEvent, waitEvent}) == WAIT_OBJECT_0)
Alert(t): SetEvent(t.alertEvent);
TestAlert: alerted := WaitForSingleObject(alertEvent, 0);
 
 
It seems simple enough.
That shows all the ingredients.
That'll eliminate a lot of the global locking.
And then one "last" iteration to use the Java code for condition variables and the global lock will be gone.
You can't just use the Java code because it doesn't include alertability.
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.
The waiter/tickets/counter stuff is pretty clever -- I don't understand it yet..
 
 
 - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091211/94daf10e/attachment-0002.html>