Re: C++ Threads, what's the status quo?
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.
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.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]