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

[Alexander Terekhov]

On 5/2/07, Alexander Terekhov <alexander.terekhov at gmail.com> wrote:
> 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).

See also

http://www.patentstorm.us/patents/6473850-description.html

But note that full bidirectional LoadLoad barrier is not really needed
for isync.

It just needs to ensure that "the load on which the Branch depends is
performed before any loads caused by instructions following the
isync."

>
> Do you still disagree?

regards,
alexander.