<HTML><HEAD>
<STYLE><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></STYLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-15">
<META content="MSHTML 6.00.6002.18071" name=GENERATOR></HEAD>
<BODY class=hmmessage>
<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>