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

Alexander Terekhov alexander.terekhov at gmail.com
Tue May 1 00:04:04 BST 2007


On 4/30/07, Paul E. McKenney <paulmck at linux.vnet.ibm.com> wrote:
[...]
> > >> This is rather intriguing because unless I'm just missing something,
> > >> cumulativity is defined the same for all barriers including
> > >> lwsync/eieio and it comes into play when *P3* makes a post-barrier
> > >> store which is observed by another processor.
> > >
> > >Not for isync or for ordering based on dependencies, however.
> >
> > 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.

http://www.ussg.iu.edu/hypermail/linux/kernel/0603.1/0379.html

[...]
> > IOW with an empty "B-cumulativity", whatever you add to the A set
> > (calling it "A-cumulativity") is not constrained at all with respect
> > to other processors.
>
> By "empty B-cumulativity", do you mean that there is no store following
> the barrier providing the cumulativity,

Yes.

> or do you mean that there is no load referencing that store,

Same effect. Let's optimize it out, then.

regards,
alexander.



More information about the cpp-threads mailing list