From: Christopher Currie (codemonkey_at_[hidden])
Date: 2004-07-15 10:45:07
Michael Glassford wrote:
>> The idea is that our C++ mutex should always be competitive with
>> the "best" native mutex available on the platform.
> It's hard to disagree with this.
>> (Incidentally, on Windows, the best native mutex is neither
>> CRITICAL_SECTION nor HMUTEX, it's Alexander's event-based thing. Or so he
>> says. But he's usually right about these things.)
> Yes, and I hope to look into it when I get time.
I'm not a Windows programmer, so feel free to disregard anything that
follows, but weren't events considered and rejected already? From
"Experienced programmers using the Windows platform today report that
event variables are a continuing source of errors, even after previous
bad experiences caused them to be very careful in their use of event
variables. Overt problems can be avoided, for example, by teaming the
event variable with a mutex, but that may just convert a race condition
into another problem, such as excessive resource use. One of the most
distressing aspects of the experience reports is the claim that many
defects are latent. That is, the programs appear to work correctly, but
contain hidden timing dependencies which will cause them to fail when
environmental factors or usage patterns change, altering relative thread
The decision to exclude event variables from Boost.Threads has been
surprising to some Windows programmers. They have written programs which
work using event variables, and wonder what the problem is. It seems
similar to the "goto considered harmful" controversy of 30 years ago. It
isn't that events, like gotos, can't be made to work, but rather that
virtually all programs using alternatives will be easier to write,
debug, read, maintain, and be less likely to contain latent defects."
This is not to say that "Alexander's event-based thing" can't be done
correctly, but I feel like this is covered ground.
-- Christopher Currie <codemonkey_at_[hidden]>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk