lkml.org 
[lkml]   [2014]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][PATCH 0/5] arch: atomic rework
    On Sun, Feb 23, 2014 at 05:35:28PM -0800, Linus Torvalds wrote:
    > On Sun, Feb 23, 2014 at 5:16 PM, Paul E. McKenney
    > <paulmck@linux.vnet.ibm.com> wrote:
    > >>
    > >> (a) we've said 'q' is restricted, so there is no aliasing between q
    > >> and the pointers b/c. So the compiler is free to move those accesses
    > >> around the "q = p->next" access.
    > >
    > > Ah, if I understand you, very good!
    > >
    > > My example intentionally left "q" -not- restricted.
    >
    > No, I 100% agree with that. "q" is *not* restricted. But "p" is, since
    > it came from that consuming load.
    >
    > But "q = p->next" is ordered by how something can alias "p->next", not by 'q'!
    >
    > There is no need to restrict anything but 'p' for all of this to work.

    I cannot say I understand this last sentence right new from the viewpoint
    of the standard, but suspending disbelief for the moment...

    (And yes, given current compilers and CPUs, I agree that this should
    all work in practice. My concern is the legality, not the reality.)

    > Btw, it's also worth pointing out that I do *not* in any way expect
    > people to actually write the "restrict" keyword anywhere. So no need
    > to change source code.

    Understood -- in this variant, you are taking the marking from the
    fact that there was an assignment from a memory_order_consume load
    rather than from a keyword on the assigned-to variable's declaration.

    > What you have is a situation where the pointer coming out of the
    > memory_order_consume is restricted. But if you assign it to a
    > non-restricted pointer, that's *fine*. That's perfectly normal C
    > behavior. The "restrict" concept is not something that the programmer
    > needs to worry about or ever even notice, it's basically just a
    > promise to the compiler that "if somebody has another pointer lying
    > around, accesses though that other pointer do not require ordering".
    >
    > So it sounds like you believe that the programmer would mark things
    > "restrict", and I did not mean that at all.

    Indeed I did believe that.

    I must confess that I was looking for an easy way to express in
    standardese -exactly- where the ordering guarantee did and did
    not propagate.

    The thing is that the vast majority of the Linux-kernel RCU code is more
    than happy with the guarantee only applying to fetches via the pointer
    returned from the memory_order_consume load. There are relatively few
    places where groups of structures are made visible to RCU readers via
    a single rcu_assign_pointer(). I guess I need to actually count them.

    Thanx, Paul



    \
     
     \ /
      Last update: 2014-02-24 06:42    [W:5.357 / U:0.764 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site