Anthony Williams schrieb:
With your changes to use InterlockedDecrement, it looks good. Off hand, I can't think of a reason why it would break --- I don't believe it suffers from deadlocks, lost wakeups, spurious wakeups, or unfairness.
Thanks for looking into it. About spurious wakeups: They are possible, but AFAIK they are considered to be quite normal in condition/mutex paradigm. As you will anyway use condition variables in a loop to reevaluate the state variables, this is no harm. About unfairness: Since I do not try to control the order of the wakeups this is left to the scheduler, and thread priorities respectively. Of course I do hold off any waiters, that entered after a broadcast or signal. But this is by design. But then: In my small example I am seeing that the done1,done2,done3 are considerably unbalanced. I am not sure yet if this is an indication of unfairness, or just an artifact of how I am trying to measure it. Any ideas?
You just need to extend it to work with other mutex types, now.
This is what currently puzzles me somewhat. The condition documentation is not explicit on whether a try_mutex is different upon return of the wait. It simply says "and then reaquires the lock". On the other hand it would not be meaningful to return without holding the lock again. Also I feel a little surprised, that try and timed are attributed to the mutex, I would have expected them properties of locks? Regards, Roland