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