Howard Hinnant <hinnant <at> twcny.rr.com> writes:
First, here's the code:
Thanks for the test code. Here's my results, running on Windows XP Pro on an Intel Core2Duo 1.83GHz T5600. Boost 1.35 mutex, no yield: 22.2656,25.0156,21.7969,23.0312,21.9375 Boost 1.35 mutex, with yield: 20,0625,20.4062,19.9844,19.9531,20.4531 CRITICAL_SECTION based mutex, no yield: 27.4219,19.3281,26.4062,20,28.3594 CRITICAL_SECTION based mutex, with yield: 24.2344,19.0625,16.6084,25.25,21.5469 new BitTestAndSet-based mutex, no yield: 20.3906,20.2188,20.4844,19.7969,20.5938 new BitTestAndSet-based mutex, with yield: 20.3125,20.6406,20.0625,20.5625, 20.125 I also tried using an in-order based lock(): new BitTestAndSet-based mutex, in order: 23.75,24.8906,23.8438,24.0938,24 CRITICAL_SECTION based mutex, in order: 42.9219, 38.9844 These were taking too long, and I ran out of patience to run more tests. Additional observations: With the boost-1.35 mutex, the time spent in the kernel was higher without the yield than with the yield. With ALL the Critical-section based tests, the first thread finished very quickly (around 5s), and for the last few seconds (the last 20s in the case of the in order tests), there were only 2 threads running, with VERY low CPU usage. Lock in order was always the slowest, with double the time for the critical-section tests. The Critical-section based mutex had both the fastest and slowest run time, with a huge spread, whereas the others had a very narrow spread. The average time for CS-based mutexes was larger than the others. The yield improved performance on all but my new BitTestAndSet-based mutex, which already had comparable performance to the boost-1.35-with-yield case. For this mutex, the with-yield version was slightly slower than the no-yield version, but not enough to be conclusive (0.2%). Conclusion: Lock in order is always worse than try-and-back-off, sometimes considerably so. Adding yield() to try-and-back-off helps with some mutex implementations, and is effectively a no-op in others, so is worth adding. Anthony