Subj : Re: C++ desired features
To   : comp.lang.c++.moderated,comp.programming.threads
From : Hans Boehm
Date : Thu Feb 24 2005 08:10 pm

Joe Seigh wrote:
> Multithreading usage patterns tend to fall into producer/consumer or
reader/writer
> patterns.   Message passing works well with the former but doesn't
work well
> with the latter.  Mutexes don't scale well with the latter by
definition.
> rwlocks don't scale so well either.  Lock-free stuff seems to do
quite well.
> You can crank up the contention level to 11 which will kill mutex and
rwlock
> based solutions and the lock-free stuff doesn't even seem to breath
heavy.
>
In my experience, lock-free solutions are great, especially when
someone else has already dealt with the tricky correctness issues.  In
particular, they can safely be used from signal/interrupt handlers,
etc.

But if you look simply at performance, in my experience at least, they
can win or lose, depending on implementation details, hardware
characteristics, etc.  For example, I reported a small experiment in
http://portal.acm.org/citation.cfm?doid=1011767.1011774 (or
http://www.hpl.hp.com/techreports/2004/HPL-2004-105.html).  Beside the
actual content of the paper, the last section compares a simple
lock-free stack vs. a solution based on simple spin-sleep locks.  The
winners are different for a 2xPII/266 and a 4xPPro machine.  And that's
pretty similar hardware.  (There were also OS differences, but I'm not
sure they matter for this particular comparison.  If so, I don't
understand the effect.)

As many people have pointed out, the real problem with contention is
typically that a critical cache line (either holding the lock, or the
lock-free data structure) is transferred back and forth between
processor caches for every access.  That's inherently not cheap.
(Inappropriate lock implementations may of course make it much worse,
as you can also see in the above test.)

Hans


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

.