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

[Jay K]

ps: not to mention the exponent!

 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] win32 AlertPause polls instead of one big wait?
Date: Fri, 11 Dec 2009 15:09:20 +0000



No.
I answered my question --  it is in case of really long pauses -- over 4billion milliseconds.
The waits are broken up into chunks of that size.
We use a 53bit? mantissa longreal to represent seconds whereas Win32 wait is 32bit number of milliseconds.
The one doesn't fit in the other.
 
 - Jay
 


Subject: Re: [M3devel] win32 AlertPause polls instead of one big wait?
From: hosking at cs.purdue.edu
Date: Fri, 11 Dec 2009 10:06:03 -0500
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu




Can you get spurious wakeups with those Windows calls?


On 11 Dec 2009, at 09:05, Jay K wrote:

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/0621608a/attachment-0002.html>