lkml.org 
[lkml]   [2014]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [RFC][PATCH 0/5] arch: atomic rework
From
On Mon, Feb 24, 2014 at 4:57 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Sun, Feb 23, 2014 at 11:31 AM, Linus Torvalds
> <torvalds@linux-foundation.org> 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.


\
 
 \ /
  Last update: 2014-02-28 18:41    [W:0.347 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site