Messages in this thread | | | Date | Tue, 3 Nov 2015 20:43:22 -0800 | Subject | Re: [PATCH 4/4] locking: Introduce smp_cond_acquire() | From | Linus Torvalds <> |
| |
On Tue, Nov 3, 2015 at 7:57 PM, Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > > Thank you, and yes, it clearly states that read-to-write dependencies > are ordered.
Well, I wouldn't say that it's exactly "clear".
The fact that they explicitly say "Note that the DP relation does not directly impose a BEFORE (⇐) ordering between accesses u and v" makes it all clear as mud.
They *then* go on to talk about how the DP relationship *together* with the odd "is source of" ordering (which in turn is defined in terms of BEFORE ordering) cannot have cycles.
I have no idea why they do it that way, but the reason seems to be that they wanted to make "BEFORE" be purely about barriers and accesses, and make the other orderings be described separately. So the "BEFORE" ordering is used to define how memory must act, which is then used as a basis for that storage definition and the "is source of" thing.
But none of that seems to make much sense to a *user*.
The fact that they seem to equate "BEFORE" with "Processor Issue Constraints" also makes me think that the whole logic was written by a CPU designer, and part of why they document it that way is that the CPU designer literally thought of "can I issue this access" as being very different from "is there some inherent ordering that just results from issues outside of my design".
I really don't know. That whole series of memory ordering rules makes my head hurt.
But I do think the only thing that matters in the end is that they do have that DP relationship between reads and subsequently dependent writes, but basically not for *any* other relationship.
So on alpha read-vs-read, write-vs-later-read, and write-vs-write all have to have memory barriers, unless the accesses physically overlap.
Linus
| |