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

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2008-02-11 07:47:16

Peter Dimov <pdimov <at> pdimov.com> writes:

> 
> Anthony Williams:
> 
> > Adding yield() to try-and-back-off helps with some mutex implementations, 
> > and is
> > effectively a no-op in others, so is worth adding.
> 
> I think that I would like to see how the algorithms scale to a number of 
> cores equaling the number of philosophers before agreeing with that. As Phil 
> notes, extra yields are not a problem if another thread can use the time to 
> do something useful. 

OK. I dropped down to two philosophers on my dual-core machine (same machine as
before). This isn't the only thing running, but there's not much else going on.

Boost 1.35 mutex, no yield: 27s
Boost 1.35 mutex, with yield: 19s

New BTS mutex, no yield: 12s
New BTS mutex, with yield: 10s

CS-based mutex, no yield: 39s
CS-based mutex, with yield: 30s

In the boost 1.35 cases, I was seeing about 70% CPU usage, but around 25% in
kernel space. In the BTS cases, I was seeing around 70% CPU usage, but very low
kernel time. In the CS cases, I was seeing about 25% CPU usage, almost all in
kernel space.

Note that the high contention caused the times for half the cases to be higher
than for the 5-thread version, despite having less work to do!

In all cases the yield improved performance vs the non-yield version.

This also makes me think I need to check in my BTS-based mutex ASAP, as it
appears to perform much better under such high contention.

Anthony
--
Anthony Williams
Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL