lkml.org 
[lkml]   [2015]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier
    On Thu, Oct 15, 2015 at 09:30:40AM -0700, Paul E. McKenney wrote:
    > On Thu, Oct 15, 2015 at 12:48:03PM +0800, Boqun Feng wrote:
    > > On Wed, Oct 14, 2015 at 08:07:05PM -0700, Paul E. McKenney wrote:
    [snip]
    > >
    > > > Why not try creating a longer litmus test that requires P0's write to
    > > > "a" to propagate to P1 before both processes complete?
    > > >
    > >
    > > I will try to write one, but to be clear, you mean we still observe
    > >
    > > 0:r3 == 0 && a == 2 && 1:r3 == 0
    > >
    > > at the end, right? Because I understand that if P1's write to 'a'
    > > doesn't override P0's, P0's write to 'a' will propagate.
    >
    > Your choice. My question is whether you can come up with a similar
    > litmus test where lwsync is allowing the behavior here, but clearly
    > is affecting some other aspect of ordering.
    >

    Got it, though my question about the propagation of P0's write to 'a'
    was originally aimed at understanding the hardware behavior(or model) in
    your sequence of events ;-)

    To be clear, by "some other aspect of ordering", you mean something like
    a paired RELEASE+ACQUIRE senario(i.e. P1 observes P0's write to 'a' via
    a load, which means P0's write to 'a' propagates at some point), right?

    If so I haven't yet came up with one, and I think there's probably none,
    so my worry about "lwsync" in other places is likely unnecessary.

    Regards,
    Boqun
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2015-10-19 02:41    [W:3.470 / U:1.652 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site