[cpp-threads] Web site updated

[Raul Silvera]

Peter Dimov wrote on 02/13/2007 03:22:52 PM:

> Boehm, Hans wrote:
> >> MMIO accesses, anyone?  Hardware timing analysis (especially
> >> if there is a short loop between the two)?
> >>
> >> Let's please just outlaw that sort of optimization for
> >> store_raw(), so that it can retain its full meaning.
> >>
> > My understanding is that we are constrained here as to what we can
> > require in normative standards text.
>
> Even if we aren't so constrained, do we really want to forbid these
> optimizations?
>
> atomic_fetchadd_relaxed( &cnt, +1 );
>
> // ordinary ops 1
>
> atomic_fetchadd_relaxed( &cnt, +1 );
>
> // ordinary ops 2
>
> atomic_fetchadd_relaxed( &cnt, +1 );
>
> I'd really like the MM to be enlightened/permissive enough as to allow
>
> // ordinary ops 1+2
>
> atomic_fetchadd_relaxed( &cnt, +3 );
>
> here. (This should work even for _release because moving in one direction
is
> still allowed; not for the various flavors of _ordered, though.)
>
> 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. 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.

--
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