[cpp-threads] Web site updated

[Hans Boehm]

I'm not sure I've completely followed this discussion, but this seems
to be diverging quite a bit from N2052, in ways that I would not like
to see.  Certainly acquire and release were NOT defined
in terms of implicit fences.  One reason for that is to make it possible
to optimize out for example, thread-local synchronization.  An
assignment to a dead atomic variable with store_release has
no ordering implications on anything else.  If the
definition was based on fences, it would be very hard to eliminate the
implied fence.

Our current definition of "ordered" needs work, since we don't yet
have agreement on what it should mean.  (We have been playing with some
variants that do enforce ordering with respect to threads that do
not access the same atomic variable.  But I think that was probably
a mistake.)

Java volatiles continue to guarantee this property, as do Java locks.
Thread local uses can be replaced by ordinary variables (or removed
for locks).  Thus this property
can be preserved for sequentially consistent atomics.  The
StoreLoad "fence" following a volatile store
is there only to order later VOLATILE loads, later ordinary references
may still be performed before the store.

Even though thread-local synchronization is less likely to arise in
C++, I think these considerations still matter if you care about
the compiler merging threads.

Hans

On Sat, 17 Feb 2007, Raul Silvera wrote:

>
>
> 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=3D=3Dcnt=3D=3D0
>
> [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 betwee=
n
> [1] and [4], so other threads could see cnt=3D=3D1, a=3D=3D0.
>
> >
> --
> Ra=FAl 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
>
>
>
>
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>