<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Randy, Juno hanging pretty consistently seems pretty concrete to me. Doesn't it?<BR>
Granted it might be related to "alert" which maybe isn't an often used feature?<BR>
Any testing/testcases you can contribute, please do.<BR>
<BR>
We should probably have more primitives instead of building on top of what we have, as the lower levels are already fairly inefficient and building on them is probably even more so.<BR>
<BR>
-Jay<BR><BR> <BR>
<HR id=stopSpelling>
Date: Thu, 8 Oct 2009 12:15:57 -0400<BR>From: rcoleburn@scires.com<BR>To: m3devel@elegosoft.com<BR>Subject: Re: [M3devel] condition variables/win32<BR><BR>
<STYLE>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Verdana;}
</STYLE>
<DIV>Jay:</DIV>
<DIV> </DIV>
<DIV>I have written and extensively tested a number of modules using threading. </DIV>
<DIV> </DIV>
<DIV>For example, I have a nice multi-reader, single-writer lock implementation, a gatekeeper implementation, an object-database implementation, etc. All of these are built on top of the thread primitives in Modula-3.</DIV>
<DIV> </DIV>
<DIV>So there is no need to reinvent the wheel here. If you need to see some of the code for these, let me know. Perhaps I can contribute some of these to the community.</DIV>
<DIV> </DIV>
<DIV><FONT size=3>At this point, do we have any <STRONG>concrete example of a failure</STRONG> in the Win32 threading implementation, other than something mysterious with Juno?</FONT></DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Randy<BR><BR>>>> Jay K <jay.krell@cornell.edu> 10/8/2009 9:32 AM >>><BR>condition variables/win32<BR> <BR><BR>So..one way I think about condition variables<BR>is that you want to be woken when someone else<BR>leaves the mutex that guards the data that you are dealing with.<BR>You want to know when another thread modifies the data.<BR>(If you have a reader/writer lock, you only want to be<BR>woken when someone exits a write.)<BR> <BR><BR>Now, if you consider a producer/consumer queue.<BR>There are two interesting occurences.<BR>Transitions from empty to non-empty<BR>and transitions from full to non-full (optionally,<BR>if it is fixed size).<BR> <BR><BR>Consumers wait for empty to non-empty.<BR>Consumers signal full to non-full.<BR>Producers wait for full to non-full.<BR>Producers signal non-empty to empty.<BR> <BR><BR>So, in this case, one mutex is likely used with with two condition variables.<BR> <BR><BR>But, what if we take a simplifying deoptimization and assume that a condition<BR>variable is only ever associated with one mutex?<BR>Anyone existing that mutex wakes up anyone waiting on any condition associated with it?<BR>Like, a condition variable I think becomes stateless and everything is<BR>about the mutex?<BR> <BR> <BR>What is the downside?<BR> <BR><BR>Condition variables are allowed to have spurious wakeups.<BR>This would "just" increase them. Too much?<BR> <BR><BR>So, therefore, what would be wrong with the following design?<BR> a mutex contains an event <BR> and a number of waiters, zero or non-zero <BR> if a mutex is exiting with a non-zero number of waiters, signal the event<BR> <BR><BR>To handle Signal vs. Broadcast<BR>method 1:<BR> the number of waiters might be interlocked<BR> the woken would decrement it<BR> if it isn't zero, signal the event again<BR> <BR><BR>method 2:<BR> the number of waiters is both an integer and a semaphore<BR> and the lock exiter raises the semaphore by the the integer<BR><BR> <BR>method 3:<BR> it is not an auto-reset event and there is a count<BR> and when the count goes to 0, reset the event<BR> I think in this case you have to maintain a "wait generation" <BR> so that new waiters don't prevent the count from ever hitting 0.<BR> I think this #3 is what Java might be doing, and is described here:<BR><A href="http://www.cs.wustl.edu/~schmidt/win32-cv-1.html">http://www.cs.wustl.edu/~schmidt/win32-cv-1.html</A><BR> "3.3. The Generation Count Solution"<BR><BR> <BR>also:<BR><A href="http://www.cs.wustl.edu/~schmidt/win32-cv-1.html">http://www.cs.wustl.edu/~schmidt/win32-cv-1.html</A><BR>3.2. The SetEvent Solution<BR>Evaluating the SetEvent Solution<BR>Incorrectness -- <BR> <BR><BR>Is that incorrect case really necessarily incorrect?<BR>It seems unfair, since first waiter should be first woken, but..?<BR><BR> <BR>Am I missing something? A lot?<BR> <BR><BR> - Jay<BR></DIV> </body>
</html>