RFR(XS): make shared variables volatile
Andrew Haley
aph at redhat.com
Fri Sep 23 14:46:32 UTC 2016
On 22/09/16 16:50, Roman Kennke wrote:
> Am Donnerstag, den 22.09.2016, 16:29 +0100 schrieb Andrew Haley:
>> On 22/09/16 16:07, Roman Kennke wrote:
>>>
>>> The question that came up while discussing this is how to access
>>> such
>>> fields. Atomic and OrderAccess both have no public load() and
>>> store()
>>> methods (or similar). There is load_acquire() and release_store()
>>> both
>>> those are recommended only to be used in pairs. I believe it would
>>> have
>>> the desired effects, but doesn't exactly look clean. Any hints?
>>
>> acquire and release are exactly what you want. Whether you do this
>> with fences or load_acquire() and release_store() does not affect
>> correctness. If you see an acquire without a matching release or
>> vice
>> versa that's probably a bug.
>
> Yes. But what if modification is done by, e.g., Atomic::inc() and in
> some other place you want to read the value? I can use load_acquire()
> and it would (probably?) be the right thing, but has no matching
> release_store().
I understand your point, but Atomic::inc has both acquire and release
semantics. It's not very well documented, but I believe it does.
> That's what we were wondering if the API should provide
> OrderAccess::load() or something similar.
Probably not. In practice, such naked fences are very error-prone.
For avoidance of doubt,
load_acquire == load ; loadload|loadstore
release_store == storestore|loadstore ; store
Andrew.
More information about the shenandoah-dev
mailing list