Re: [boost] [thread] best practice to lock multiple mutexes

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2008-02-10 06:52:50

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