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.
