[cpp-threads] SC on PPC (was Re: Increment/decrement operators on atomics package)

[Alexander Terekhov]

On 5/1/07, Paul E. McKenney <paulmck at linux.vnet.ibm.com> wrote:
> On Tue, May 01, 2007 at 11:20:20AM +0200, Alexander Terekhov wrote:
> > On 5/1/07, Paul E. McKenney <paulmck at linux.vnet.ibm.com> wrote:
> > [...]
> > >> >> But isync is not really a bidirectional barrier. It's just a way to
> > >> >> achieve .acq using fake or real dependencies.
> > >> >
> > >> >It can indeed be used to achieve ,acq in some cases, but as near as I
> > >> >can tell its original intent was to handle the case where the subsequent
> > >> >instruction stream depended on prior operations, for example, after
> > >> >mapping in a module but before executing it.
> > >>
> > >> I meant its effect on memory ordering.
> > >
> > >Fair enough.  But you -did- say "It's just a way to achieve .acq".
> > >
> > >> http://www.ussg.iu.edu/hypermail/linux/kernel/0603.1/0379.html
> > >
> > >Yep.  But this URL says that isync -can- be used to create a type
> > >of memory barrier.  It doesn't imply that isync's use is restricted
> > >to this use case.
> >
> > It can be used for context synchronization stuff as well but hardware
> > can be smart enough to maintain a flag telling whether context sync is
> > actually needed and optimize isync in this respect to make it less
> > expensive for common usage as one-way "import barrier" in conjunction
> > with dependencies... i.e. that regarding memory ordering, it's just a
> > way to achieve .acq using fake or real dependencies.
>
> Sort of.  With respect to subsequent stores, but not with respect to
> subsequent loads.

Book II:

if a Store instruction depends on the value
returned by a preceding Load instruction (because the
value returned by the Load is used to compute either
the effective address specified by the Store or the value
to be stored), the corresponding storage accesses are
performed in program order. The same applies if
whether the Store instruction is executed depends on a
conditional Branch instruction that in turn depends on
the value returned by a preceding Load instruction.

Because an isync instruction prevents the execution of
instructions following the isync until instructions preceding
the isync have completed, if an isync follows a
conditional Branch instruction that depends on the
value returned by a preceding Load instruction, the
load on which the Branch depends is performed before
any loads caused by instructions following the isync.
This applies even if the effects of the "dependency" are
independent of the value loaded (e.g., the value is
compared to itself and the Branch tests the EQ bit in
the selected CR field), and even if the branch target is
the sequentially next instruction.

It means that for load_acquire we can simply do

load;"branch never taken";isync // see B.2.3 Safe Fetch (Book II).

Do you still disagree?

regards,
alexander.