Messages in this thread |  | | Date | Sun, 23 Feb 2014 21:25:55 -0800 | Subject | Re: [RFC][PATCH 0/5] arch: atomic rework | From | Linus Torvalds <> |
| |
On Sun, Feb 23, 2014 at 8:59 PM, Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > On Sun, Feb 23, 2014 at 05:35:28PM -0800, Linus Torvalds wrote: >> >> 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...
So 'p' is what comes from that consuming load that returns a 'restrict' pointer. That doesn't affect 'q' in any way.
But the act of initializing 'q' by dereferencing p (in "p->next") is - by virtue of the restrict - something that the compiler can see cannot alias with anything else, so the compiler could re-order other memory accesses freely around it, if you see what I mean.
Modulo all the *other* ordering guarantees, of course. So other atomics and volatiles etc may have their own rules, quite apart from any aliasing issues.
> 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.
Yes, and to me, it's really just a legalistic trick to make it clear that any *other* pointer that happens to point to the same object cannot be dereferenced within scope of the result of the atomic_read(mo_consume), at least not if you expect to get the memory ordering semantics. You can do it, but then you violate the guarantee of the restrict, and you get what you get - a potential non-ordering.
So if somebody just immediately assigns the value to a normal (non-restrict) pointer nothing *really* changes. It's just there to describe the guarantees.
Linus
|  |