On Mon, Feb 24, 2014 at 4:57 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Sun, Feb 23, 2014 at 11:31 AM, Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: >> >> Let me think about it some more, but my gut feel is that just tweaking >> the definition of what "ordered" means is sufficient. >> >> So to go back to the suggested ordering rules (ignoring the "restrict" >> part, which is just to clarify that ordering through other means to >> get to the object doesn't matter), I suggested: >> >> "the consume ordering guarantees the ordering between that >> atomic read and the accesses to the object that the pointer >> points to" >> >> and I think the solution is to just say that this ordering acts as a >> fence. It doesn't say exactly *where* the fence is, but it says that >> there is *some* fence between the load of the pointer and any/all >> accesses to the object through that pointer. > > I'm wrong. That doesn't work. At all. There is no ordering except > through the pointer chain. > > So I think saying just that, and nothing else (no magic fences, no > nothing) is the right thing: > > "the consume ordering guarantees the ordering between that > atomic read and the accesses to the object that the pointer > points to directly or indirectly through a chain of pointers" To me that reads like int i; int *q = &i; int **p = &q; atomic_XXX (p, CONSUME); orders against accesses '*p', '**p', '*q' and 'i'. Thus it seems they want to say that it orders against aliased storage - but then go further and include "indirectly through a chain of pointers"?! Thus an atomic read of a int * orders against any 'int' memory operation but not against 'float' memory operations? Eh ... Just jumping in to throw in my weird-2-cents. Richard. -- 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
