<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
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> </body>
</html>