[cpp-threads] Web site updated

[Raul Silvera]

Peter Dimov wrote on 02/15/2007 01:04:54 PM:

> Raul Silvera wrote:
> > Peter Dimov wrote on 02/13/2007 03:22:52 PM:
> >
> >> Similarly,
> >>
> >> atomic_fetchadd_relaxed( &cnt, r );
> >> atomic_fetchadd_relaxed( &cnt, -r );
> >>
> >> should be a noop, even for _ordered.
> >>
> >
> > I certainly agree with this for _relaxed, but not for ordered.
> > Ordered says that the second fetchadd cannot be done until after the
> > first one has been made visible, so the implicit barrier will prevent
> > the updates from being merged and removed.
>
> I agree for an "ordered" that implies a #StoreLoad, and don't agree for
an
> "ordered" that does not.

Fair enough. The "ordered" I had in mind implies all kinds of ordering,
including a #StoreLoad.
>
> > Furthermore, I think such
> > a mechanism is what should be used (instead of volatile) when users
> > insist on relying on the intermediate values becoming visible to
> > other threads. In this case, simply making the first fetchadd
> > _release should be sufficient to prevent the two operations from
> > being combined.
>
> I don't believe that _release implies a #StoreLoad, so I disagree about
> _release being non-combineable. A store_release could conceivably be
> coalesced by the hardware write queue in the absence of #StoreLoad, so
why
> not by the compiler?
>

It doesn't imply a #StoreLoad, but it does imply a #StoreStore. My
reasoning is that in order to fully honor the #StoreStore, you need the
store implied by the first fetch-and-add to be performed before the store
implied by the second fetch-and-add.

In any case, I can agree that "before" could be replaced by
"no-later-than", in which case the memory operations could be removed.
However, it cannot be completely transformed into a noop: the fence must
remain. Here is an example:

a==cnt==0

[1] atomic_store_relaxed(a, 1);

[2] atomic_fetchadd_release( &cnt, r );
[3] atomic_fetchadd_release( &cnt, -r );

[4] atomic_store_relaxed(cnt, 1);

If you were to replace [23] by a noop, you would lose any ordering between
[1] and [4], so other threads could see cnt==1, a==0.

>
--
Raúl E. Silvera         IBM Toronto Lab   Team Lead, Toronto Portable
Optimizer (TPO)
Tel: 905-413-4188 T/L: 969-4188           Fax: 905-413-4854
D2/KC9/8200/MKM