Re: MT Design Question
"Joshua Maurice" <joshuamaurice@gmail.com>
The important quality of condition variables is not "the mutex is
automatically acquired after returning from wait". Don't get me wrong,
it's nice, and probably the only sane way to present it to users.
However, the important part of condition variables is releasing the
lock and going on the wait queue, and doing that atomically.
I don't see any difference compared to W32's Event if you drop the attached
mutex handling.
However, there are
situations where you want a thread A to go to sleep until another
thread B has completed some work. In such a case, you need to work
with the OS scheduler to put thread A to sleep. Ideally, you also do
not want to poll in order to "wake up" thread A.
If the other thread finishes you can WaitForSingeObject directly on the
thread handle. If it continues, you do the same on an Event, that is set
(reset? never can remember which ;-) on the thread.
I assume that this is a rather common situation, telling the OS
scheduler to put a thread to sleep until some other thread has
finished its work. What APIs do you generally use to interact with the
OS scheduler to do this?
The mentioned Event. The scenario you described is indeed quite fundamental,
did you think it is not covered on word's most widespread platform?
Also, for the record, a large source of my hate is the following
snippet from MSDN
http://msdn.microsoft.com/en-us/library/ms684914%28VS.85%29.aspx
Somewhat strange, it marks PulseEvent as Win2000 thing. It was definitely
present on NT4.0, and possibly earlier. The conditionals it suggest to use
made in only at XP.
Not sure whether PulseEvent had this chance to lose wakeups back then. In my
scenarios only Set and Reset was used -- in a straightforward way at
different ends.
OTOH, comes to mind that Pulse never played well with WaitForMultipleEvents
(for obvious reasons), that makes it kinda dead beef outside very special
scenarios, that may not even exist ;-)
Basically, the entire function is beyond broken. I like the
conclusion: "Instead, use condition variables".
Okay, that makes it 'ballast' that you can find an any API. What is
important in practice if there is a set of non-broken functions that helps
you cover your actual problems (including fair performance, safety,
complexity management, etc).