Re: C++ Threads, what's the status quo?
Le Chaud Lapin wrote:
Simon Farnsworth wrote:
Further, the standard is silent on whether you can assume strict
consistency, weak consistency, sequential consistency, causual
consistency, or another consistency model.
I am happy to admit, I have no idea what these terms mean, but I will
look them up in about 10 minutes.
However, I see something missing in your post: atomic operations. This
is the essence of my thesis. I keep saying there will not be any
guarantees in any language if you do not have:
Even with atomic operations, in consistency models weaker than strict
consistency, you cannot guarantee that threading will work properly when
you access a data structure from two different threads, unless you've got
some way of imposing cache synchronisation between two CPUs. For example,
in a weak model, the following pseudocode can produce "1, 1, 1" even if
thread_1 gets the lock first, although it's guaranteed to return 2:
int x = 1;
lock x_lock; // Atomic operations used to implement the lock.
int main()
{
x_lock.acquire();
start thread_2() on other CPU;
cout << x << ", ";
x = 2;
x_lock.release();
return x;
}
void thread_2()
{
x_lock.acquire();
cout << x << ", ";
x = 1;
cout << x << ", ";
x_lock.release();
}
The reason for this is that unless the caches are fully synchronised between
CPUs when the lock is released, the first CPU (running main) is entitled to
not write the change to x to memory until an arbitrarily later point. The
CPU running thread_2 will thus pick up the original value of x.
Fixing this requires the C++ standard to think about what operations should
act as consistency barriers; for example, one fix would be to add a special
operation that guarantees inter-CPU consistency for the variable it's
called on. Then, after writing x (but before releasing the lock), main
could make x's value consistent between CPUs.
An alternative fix might make the compiler guarantee that some operations
are cache synchronisation points; then (at the expense of less efficient
code for weakly consistent systems), the code would work as you'd expect.
At the moment, the standard is completely silent on what guarantees do and
do not exist; most small computer systems (less than 256 CPUs) guarantee at
least causal consistency, but there are serious hardware design advantages
to weaker models (like release consistency). If C++ wants to be the
language of choice on systems of all sizes, it needs to cope with this.
--
Simon Farnsworth
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]