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

[Paul E. McKenney]

On Wed, May 02, 2007 at 11:13:10AM +0200, Alexander Terekhov wrote:
> 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).

Good point -- I was indeed missing the conditional branch in your
example.  Please accept my apologies for my confusion!

Note, however, that the time-honored notion of enforcing ordering based
on data dependencies is proving somewhat controversial in the C/C++
standards committee.  Given that control dependencies are supported
by fewer CPUs than are data dependencies, I would guess that support
of control dependencies will be even more controversial.  My current
proposal (draft attached) therefore addresses control dependencies but
not data dependencies.

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

You are quite correct -- the control dependency represented by the
conditional branch does enforce ordering on PowerPC.

							Thaxn, Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.decadentplace.org.uk/pipermail/cpp-threads/attachments/20070502/876300a4/dependencyproposal.2007.05.02a-0001.html