[cpp-threads] Yet another visibility question

[Hans Boehm]

On Wed, 10 Jan 2007, Peter Dimov wrote:

> Hans Boehm wrote:
> > Let me see if I can summarize where I think we might stand.  (I'm a
> > little confused ...)
> >
> > A number of us think that high-level atomics, ideally with
> > sequentially consistent semantics and similar to Java volatiles, are
> > highly desirable, since they are the closest to actually being usable
> > by mere mortals,
> > and give tolerable performance for things like double-checked locking.
> > (I think there was, and still is, a fairly clear concensus supporting
> > this on the C++ committee.)
> >
> > I would really prefer a model in which programs that use high-level
> > atomics to synchronize, and have no races on ordinary variables,
> > behave sequentially consistently.
>
> Let me see if I understand.
>
> atomic<int> x, y; // 0 0
>
> // thread 1
>
> x = 1;
>
> // thread 2
>
> y = 1;
>
> // thread 3
>
> r1 = x; r2 = y;
>
> // thread 4
>
> r3 = x; r4 = y;
>
> Are you saying that (r1 r2 r3 r4) == (0 1 1 0) is invalid? Doesn't this
> imply on x86 using InterlockedExchange for all stores (and possibly
> InterlockedCompareExchange for all loads, I'm not sure), and on PPC using
> lwarx/stwcx. loops for all operations?
>
>
Once you fix the bug in the example by inverting the two loads in threads
4, the answer is yes, I would like that.  (As written, this is possible in
an SC execution.)  There are also those people who feel we're not going
to get it.  But I think the verdict is still out.

There are still parallel discussions about hardware implications, and
how difficult this really is on existing hardware, as opposed to with
existing hardware specs, to what extent it inherently slows down
the hardware, and whether or not we can actually describe the semantics
of atomics intelligibly without this property.

Hans