[cpp-threads] A question about N2153

[Raul Silvera]

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


cpp-threads-bounces at decadentplace.org.uk wrote on 01/17/2007 04:40:04 PM:

> On 1/17/07, Paul E. McKenney <paulmck at linux.vnet.ibm.com> wrote:
> [...]
> > > Well, an acquire_"fence" is like this:
> > >
> > > // do your atomic operation here
> > > #StoreLoad | #StoreStore
> > >
> > > And a release_"fence" is like this:
> > >
> > > #LoadStore | #StoreStore
> > > // do your atomic operation here
> >
> > OK.  But I already understood what you guys meant by these two
primitives.
> > My question is why choose these particular definitions?  From my
> > viewpoint, the definitions are quite strange, and they don't do what I
> > want in many cases.  I often need a StoreStore without the StoreLoad,
and
>
> Acquire "fence" and sink-store barrier part of .rel aside for a
> moment, N2153 gives an example for "release" fence:
>
>   do_work(A,B);
>   release_fence();
>   lock_A.store_raw(LOCK_UNLOCKED);
>   lock_B.store_raw(LOCK_UNLOCKED);
>
> I mentally translate it to
>
>   do_work(A,B);
>   atomic_stores_raw_group_release(lock_A, lock_B, LOCK_UNLOCKED);
>

Yes, exactly. The whole point is that it isn't possible for a standard to
provide all possible ordering constructs that may be useful (e.g three lock
releases, or cases where different types of locks are released), so we're
providing some building blocks so that the user can construct them without
overspecifying the ordering requirements.


> (with an extra feature being that the later won't inhibit hoisting of
> subsequent stuff above it any more than classic .rel).
>
> regards,
> alexander.
>
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads