[jmm-dev] bitwise RMW operators, specifically testAndSetBit/BTS

Andrew Haley aph at redhat.com
Mon Jul 25 08:54:20 UTC 2016


On 19/07/16 21:51, Andrew Haley wrote:
> On 19/07/16 09:39, Paul Sandoz wrote:
>>
>> Both plain and opaque have “no assurance of memory ordering effects
>> with respect to other threads” but opaque is stronger in the sense
>> that the compiler is restricted in what optimisations it may
>> perform, in a sense the access is “opaque” to the compiler e.g. it
>> cannot elide the access or fold it into a more recent access etc.
> 
> OK, but if the processor can reorder accesses (and satisfy them from
> local caches) in the absence of fences, why is this a distinction that
> is worth bothering about?  And how on Earth would you make such a
> distinction in the context of a high-level language specification?

I'm still wondering about this one.  I think Doug has said that
Opaque accesses are coherent but Plain accesses aren't.  I guess
there's also non-atomic treatment of long and double.

Andrew.



More information about the jmm-dev mailing list