(S) RFR: 8157904: Atomic::cmpxchg for jbyte is missing a fence on initial failure
Andrew Haley
aph at redhat.com
Wed Aug 24 17:05:13 UTC 2016
On 24/08/16 09:01, David Holmes wrote:
> On 24/08/2016 5:36 PM, Andrew Haley wrote:
>> On 22/08/16 08:54, David Holmes wrote:
>>> An earlier code review noticed that the default shared implementation of
>>> Atomic::cmpxchg(jbyte*) was missing the required post-memory-barrier in
>>> case of an initial failure:
>>
>> Just to satisfy my curiosity, why is the post-memory-barrier in
>> case of an initial failure required? Is there some specification
>> somewhere that I can refer to?
>
> In atomic.hpp:
>
> // All of the atomic operations that imply a read-modify-write action
> // guarantee a two-way memory barrier across that operation.
>
> and then each op has additional descriptions e.g.:
>
> // Performs atomic compare of *dest and compare_value, and exchanges
> // *dest with exchange_value if the comparison succeeded. Returns prior
> // value of *dest. cmpxchg*() provide:
> // <fence> compare-and-exchange <membar StoreLoad|StoreStore>
OK; I guess it doesn't much matter from a performance point of view.
It's stronger than anything we get from Java and or C++11 intrinsics,
which struck me as odd.
Andrew.
More information about the hotspot-runtime-dev
mailing list