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 http://www.boost.org/libs/thread/doc/rationale.html#events: "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 timings. 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@gmail.com>