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@xxxxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
