Re: C++ Threads, what's the status quo?
Le Chaud Lapin wrote:
James Kanze wrote:
Le Chaud Lapin wrote:
Also, as hinted by John Q, there will be many cases (probably most)
where there is no choice but to make one thread wait while another
thread operates on a shared global variable, so a compiler-supplied
atomic operation will only get you up to the spin-lock, and after that,
it is back to kernel-mode synchronization primitives.
Which is obviously false. Zeljko showed how to solve the
problem for a single processor system: a thread switch cannot
occur between the two operations. Add a lock prefix for
multiprocessors, and the processor should hold the memory bus
for the total length of the instruction, so no other processor
can access the variable. (I'm not sure that this holds with
more modern versions of the x86 architecture, but it was the
case when I wrote my OS.)
It is not false. If the variable is a large aggregate that requires
lengthy processing, then a second thread will need to wait.
And if it isn't? Lock free algorithms can't be used for
everything, but there are significant algorithms where they are
applicable.
This is actually the motivation of most of my posts: to remind us that
all trickery will ultimately lead to kernel-mode synchronization
primitives.
In which case, you're arguing something which is provably false.
Lock-free non-blocking algorithms are known for some operations,
provided the hardware provides the right instructions. You
don't typically need kernel-mode synchronization for things like
adding or subtracting of atomic integral types. You certainly
don't for Intel, nor for Sparc post version 9. (Earlier
versions of the Sparc architecture did require some sort of
system level synchronization.)
The world of multi-threaded applications would be very uninteresting if
the only thing that was allowed was synchronization against integral
types.
Certainly. But synchronization is typically for a few well
defined structures. Given the right machine instructions, it's
possible, for example, to implement a message queue without
using locks. Boost::shared_ptr or various COW algorithms are
other cases for which there are lock-free solutions, which
guarantee no waiting.
They're not relevant in my code; the profiler has yet to
indicate that locking is causing bottlenecks. But that doesn't
mean that others might not need them, or that they're
impossible.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]