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

Sat Dec 12 06:37:44 CET 2009

Randy, I was just going to ask about this..:

building with Visual C++ 2.0 (banner says copyright 1994):

Time.mo : error LNK2001: unresolved external symbol "_GetSystemTimeAsFileTime at 4"
WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_GetIcon at 12"
WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_LoadImageA at 28"
WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_Remove at 8"
WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_ReplaceIcon at 12"
ThreadWin32C.obj : error LNK2001: unresolved external symbol "_InterlockedCompareExchange"
ThreadWin32.mo : error LNK2001: unresolved external symbol "_InterlockedCompareExchange at 12"
RTOS.mo : error LNK2001: unresolved external symbol "_IsDebuggerPresent at 0"
m3core.dll : error LNK1120: 8 unresolved externals

building with Visual C++ 4.0 (circa 1996?):
ThreadWin32.mo : error LNK2001: unresolved external symbol _InterlockedCompareExchange at 12
ThreadWin32C.obj : error LNK2001: unresolved external symbol _InterlockedCompareExchange
m3core.dll : fatal error LNK1120: 2 unresolved externals

building with Visual C++ 4.2 (circa 1996?):
works

Which is also some significant measure of what operating systems work.

I had deleted \cm3\lib. If you build in m3-win\import-libs, then the problems drop to just InterlockedCompareExchange, and that is easily fixed. Though again it is a measure of what operating system versions will work.

I'm really undecided here. Our dependency on anything beyond Windows 95/NT 3.1, maybe even Win32s, is really slight or nonexistant. If you look at the above list for example, InterlockedCompareExchange I /just/ introduced to replace a lock, a lock that I had only introduced recently as part of removing the giant lock (the lock is much smaller). IsDebuggerPresent is really optional. GetSystemTimeAsFileTime is trivial to do without. ImageList stuff probably isn't needed -- we certainly get stuff at the wrong layer because of a certain part of our architecture. You know, normally in C / C++, there's no comctl32.dll support at any lower level, whoever needs it just #includes commctl.h. It is our "wrappers" that introduce this dependency.

The way I discover the stack boundaries might not work on Win9x/Win32s, but it might.

For testing I make sure Juno can startup several times, the system can rebuild itself, and sometimes run test p007.

If all that works, things are better than they were for a long time.

For many months Juno would sometimes hang due to a bug that affected all programs.

  Granted, we didn't necessarily ever release that bug.

In comparison the pthreads code has also had long standing problems..I think..at least on FreeBSD.

For better and for worse, these parts of the system do need work imho.

My changes are also mostly for the simpler. Of course nobody can decide what is "simple".

The change to remove the giant lock from LockMutex/UnlockMutex agrees with Birrel's paper, which only implies the lock might be there for an optimization elsewhere, an optimization that we didn't have.

Let me know of any slight or suspected problem and esp. let me run the code.

We should be ok, or better. :)

For the alert thing we could do a version check and/or GetProcAddress on QueueUserAPC, or actually I suspect it is easy to be Win9x compatible. You'd have each thread open/create its own anonymous pipe and to alert the thread you'd just write a byte the pipe.

I could test older systems in VMs. I mostly just use XP.

 - Jay

Date: Fri, 11 Dec 2009 23:50:57 -0500
From: rcoleburn at scires.com
To: m3devel at elegosoft.com
Subject: Re: [M3devel] win32 AlertPause polls instead of one big wait?

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/20091212/757d855a/attachment-0002.html>