[cpp-threads] Yet another visibility question

Alexander Terekhov alexander.terekhov at gmail.com
Thu Oct 12 10:03:29 BST 2006


On 10/10/06, Peter Dimov <pdimov at mmltd.net> wrote:
> Alexander Terekhov wrote:
> > On 10/9/06, Peter Dimov <pdimov at mmltd.net> wrote:
> >> Alexander Terekhov wrote:
> >>> On 10/8/06, Peter Dimov <pdimov at mmltd.net> wrote:
> >>>> Consider:
> >>>>
> >>>> // initial values 0
> >>>>
> >>>> // thread 1
> >>>>
> >>>> x = 1; // ordinary store
> >>>> store_release( y, 1 );
> >>>>
> >>>> // thread 2
> >>>>
> >>>> r1 = load_raw( y ); // assume this reads 1
> >>>> store_release( y, r1+1 ); // ... and this stores 2
> >>>>
> >>>> // thread 3
> >>>>
> >>>> r2 = load_acquire( y ); // assume this reads 2
> >>>>
> >>>> if( r2 == 2 )
> >>>> {
> >>>>     assert( x == 1 ); // ordinary load
> >>>> }
> >>>>
> >>>> Will the assert pass?
> >>>
> >>> Uhmm, it will pass under classic RC model. The store to y in thread
> >>> 1 is allowed to be made visible with respect to any other thread
> >>> only after the preceding store to x is made globally visible.
> >>
> >> Yeah. But if the store to x is guaranteed to be made visible only to
> >> threads that observe the subsequent store_release to y, T3 is not
> >> guaranteed to see it, because it didn't observe T1's store to y, but
> >> rather T2's.
> >
> > Wouldn't that mean that T3 can observe y changing from 2 to 1 (instead
> > of 1 to 2) or somehow it would be guaranteed that T3 can never see y
> > == 1. I just can't imagine such a model.
>
> It probably can't happen in practice; I'm not sure. It just seemed to me
> that this is the case under the proposed C++MM, and Hans has confirmed it.
> Whether this is good or bad, I don't know, but a refcounting under these
> rules seems to need acq+rel ("ordered") decrement.

If it needs acq+rel then it is bad and the definition of
synchronizes-with ought to be changed to allow less ordered decrements
for refcounting, I think.

regards,
alexander.



More information about the cpp-threads mailing list