Re: How to guarantee memory access orthogonality without atomics?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


While your citations are technically from a draft proposal, I'm
substantially convinced that you're correct in your assertion that
"You can't have a data race if the threads don't access the same
objects", byte-granularity assumed. In any event, thank you very much
for the guidance.

For the benefit of the archive, I found this related thread:
http://lwn.net/Articles/479626/

which quotes, as you did, that:

"Two expression evaluations conflict if one of them modifies a memory
location and the other one reads or modifies the same memory
location."

It seems to me that the danger herein lies in the environment in which
"same" is evaluated. What you've suggested is that the evaluation is
to occur at the memory controller level, not at the compiler level. (I
think that makes sense, but I'm not sure it's explicit in the spec.)
So there's a small danger here that one could consider nonconflicting
an expression which modified only orthogonal memory locations at the
superficial C level, but which resolved to read-modify-write conflicts
at the cache line level. Hence, I suppose, your comment about the
problem of implementing C on a machine which could not support
different threads nonatomically writing to the same line.

On Fri, Apr 27, 2012 at 4:57 PM, Andrew Haley <aph@xxxxxxxxxx> wrote:
> On 04/27/2012 10:23 AM, Leonard Plentz wrote:
>
>> X is 4 bytes wide. It's based at address 27. Y is also 4 bytes wide.
>> It's based at address 31. Cache lines happen to be 32 bytes long.
>> Processor 0 can write to X any time, and processor 1 can write to Y
>> anytime. Writing to Y causes an implicit read-modify-write to the line
>> containing X. But this doesn't matter because it's assumed under
>> C99/C11 that the processor will enforce the orthogonality of X and Y,
>> provided that their sizes are at least a multiple of whole bytes based
>> at whole-byte boundaries.
>>
>> Is that correct?
>
> Yes.  If you have a look at the definition of a conflict in N3242=11-0012
> you'll see
>
> 4 Two expression evaluations conflict if one of them modifies a memory
>  location[1.7] and the other one accesses or modifies the same
>  memory location.
>
> ... and in Section 1.7 ...
>
> 3 A memory location is either an object of scalar type or a maximal
>  sequence of adjacent bit-fields all having non-zero width. ... Two
>  threads of execution (1.10) can update and access separate memory
>  locations without interfering with each other.
>
> Andrew.



[Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

Add to Google