[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