[M3devel] condition variables/win32

[Tony Hosking]

In general, it is OK in M3 to associate multiple conditions with the  
same mutex.  But not vice versa.

On 8 Oct 2009, at 09:32, Jay K wrote:

> condition variables/win32
>
>
> So..one way I think about condition variables
> is that you want to be woken when someone else
> leaves the mutex that guards the data that you are dealing with.
> You want to know when another thread modifies the data.
> (If you have a reader/writer lock, you only want to be
> woken when someone exits a write.)
>
>
> Now, if you consider a producer/consumer queue.
> There are two interesting occurences.
> Transitions from empty to non-empty
> and transitions from full to non-full (optionally,
> if it is fixed size).
>
>
> Consumers wait for empty to non-empty.
> Consumers signal full to non-full.
> Producers wait for full to non-full.
> Producers signal non-empty to empty.
>
>
> So, in this case, one mutex is likely used with with two condition  
> variables.
>
>
> But, what if we take a simplifying deoptimization and assume that a  
> condition
> variable is only ever associated with one mutex?
> Anyone existing that mutex wakes up anyone waiting on any condition  
> associated with it?
> Like, a condition variable I think becomes stateless and everything is
> about the mutex?
>
>
> What is the downside?
>
>
> Condition variables are allowed to have spurious wakeups.
> This would "just" increase them. Too much?
>
>
> So, therefore, what would be wrong with the following design?
>  a mutex contains an event
>  and a number of waiters, zero or non-zero
>  if a mutex is exiting with a non-zero number of waiters, signal the  
> event
>
>
> To handle Signal vs. Broadcast
> method 1:
>  the number of waiters might be interlocked
>  the woken would decrement it
>  if it isn't zero, signal the event again
>
>
> method 2:
>  the number of waiters is both an integer and a semaphore
>  and the lock exiter raises the semaphore by the the integer
>
>
> method 3:
>  it is not an auto-reset event and there is a count
>   and when the count goes to 0, reset the event
>  I think in this case you have to maintain a "wait generation"
>  so that new waiters don't prevent the count from ever hitting 0.
>  I think this #3 is what Java might be doing, and is described here:
> http://www.cs.wustl.edu/~schmidt/win32-cv-1.html
>  "3.3. The Generation Count Solution"
>
>
> also:
> http://www.cs.wustl.edu/~schmidt/win32-cv-1.html
> 3.2. The SetEvent Solution
> Evaluating the SetEvent Solution
> Incorrectness --
>
>
> Is that incorrect case really necessarily incorrect?
> It seems unfair, since first waiter should be first woken, but..?
>
>
> Am I missing something? A lot?
>
>
>  - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091008/b18d0fde/attachment-0002.html>