<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Randy, I was just going to ask about this..:<BR>
<BR>
<BR>
building with Visual C++ 2.0 (banner says copyright 1994):<BR>
Time.mo : error LNK2001: unresolved external symbol "<A href="mailto:_GetSystemTimeAsFileTime@4">_GetSystemTimeAsFileTime@4</A>"<BR>WinImageList.mo : error LNK2001: unresolved external symbol "<A href="mailto:_ImageList_GetIcon@12">_ImageList_GetIcon@12</A>"<BR>WinImageList.mo : error LNK2001: unresolved external symbol "<A href="mailto:_ImageList_LoadImageA@28">_ImageList_LoadImageA@28</A>"<BR>WinImageList.mo : error LNK2001: unresolved external symbol "<A href="mailto:_ImageList_Remove@8">_ImageList_Remove@8</A>"<BR>WinImageList.mo : error LNK2001: unresolved external symbol "<A href="mailto:_ImageList_ReplaceIcon@12">_ImageList_ReplaceIcon@12</A>"<BR>ThreadWin32C.obj : error LNK2001: unresolved external symbol "_InterlockedCompareExchange"<BR>ThreadWin32.mo : error LNK2001: unresolved external symbol "<A href="mailto:_InterlockedCompareExchange@12">_InterlockedCompareExchange@12</A>"<BR>RTOS.mo : error LNK2001: unresolved external symbol "<A href="mailto:_IsDebuggerPresent@0">_IsDebuggerPresent@0</A>"<BR>m3core.dll : error LNK1120: 8 unresolved externals<BR>
<BR>
building with Visual C++ 4.0 (circa 1996?):<BR>ThreadWin32.mo : error LNK2001: unresolved external symbol <A href="mailto:_InterlockedCompareExchange@12">_InterlockedCompareExchange@12</A><BR>ThreadWin32C.obj : error LNK2001: unresolved external symbol _InterlockedCompareExchange<BR>m3core.dll : fatal error LNK1120: 2 unresolved externals<BR>
<BR>
building with Visual C++ 4.2 (circa 1996?):<BR>works<BR><BR>
<BR>Which is also some significant measure of what operating systems work.<BR>
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.<BR>
<BR>
<BR>
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. <U><FONT color=#0000ff>GetSystemTimeAsFileTime</FONT></U> 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.<BR>
The way I discover the stack boundaries might not work on Win9x/Win32s, but it might.<BR>
<BR>
<BR>
For testing I make sure Juno can startup several times, the system can rebuild itself, and sometimes run test p007.<BR>
If all that works, things are better than they were for a long time.<BR>
For many months Juno would sometimes hang due to a bug that affected all programs.<BR>
Granted, we didn't necessarily ever release that bug.<BR>
In comparison the pthreads code has also had long standing problems..I think..at least on FreeBSD.<BR>
For better and for worse, these parts of the system do need work imho.<BR>
<BR>
<BR>
My changes are also mostly for the simpler. Of course nobody can decide what is "simple".<BR>
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.<BR>
Let me know of any slight or suspected problem and esp. let me run the code.<BR>
We should be ok, or better. :)<BR>
<BR>
<BR>
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.<BR>
I could test older systems in VMs. I mostly just use XP.<BR>
<BR>
<BR>
- Jay<BR><BR>
<BR>
<HR id=stopSpelling>
<BR>
Date: Fri, 11 Dec 2009 23:50:57 -0500<BR>From: rcoleburn@scires.com<BR>To: m3devel@elegosoft.com<BR>Subject: Re: [M3devel] win32 AlertPause polls instead of one big wait?<BR><BR><BR>
<STYLE>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Verdana;}
</STYLE>
<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=ecxecxstopSpelling>
</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>