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