[concurrency-interest] AtomicReference get vs. getAcquire; get/set Opaque

Alex Otenko oleksandr.otenko at gmail.com
Sun Sep 25 11:07:56 EDT 2016


Well, knowing there are architectures where data dependencies have to be enforced, it’s hard to tell how far we relax the ordering. There is a reference to C++, and that does clarify what ordering is meant.


Alex


> On 25 Sep 2016, at 00:24, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> 
> 
> 
> On Saturday, September 24, 2016, Alex Otenko <oleksandr.otenko at gmail.com <mailto:oleksandr.otenko at gmail.com>> wrote:
> In the documentation for getAcquire / setRelease there is not a word about ordering of getAcquire and setRelease between themselves.
> 
> So it’d be important to know if a subsequent getAcquire can be reordered with a preceding setRelease - eg will polling this queue twice in a loop return the same v.
> That would violate normal data dependence, wouldn't it? However, a good question is can compiler perform store-load forwarding, yielding null on the second read.  I suspect no because I'd expect acquire/release to encompass opaque as well, and so compiler must perform the read on 2nd iteration. 
> 
> Alex
> 
>> On 24 Sep 2016, at 18:10, Martin Buchholz <martinrb at google.com <>> wrote:
>> 
>> 
>> 
>> On Sat, Sep 24, 2016 at 6:19 AM, Dávid Karnok <akarnokd at gmail.com <>> wrote:
>> I have a one element single-producer single-consumer "queue" implemented as this:
>> 
>> boolean offer(AtomicReference<T> ref, T value) {
>>     Objects.requireNonNull(value);
>>     if (ref.get() == null) {
>>         ref.lazySet(value);
>>         return true;
>>     }
>>     return false;
>> }
>> 
>> T poll(AtomicReference<T> ref) {
>>     T v = ref.get();
>>     if (v != null) {
>>        ref.lazySet(null);
>>     }
>>     return v;
>> }
>> 
>> Is it okay to turn get() into getAcquire() and lazySet into setRelease() (I can see lazySet delegates to setRelease)? 
>> 
>> Yes, but ... the poll and offer operations will no longer be part of the global sequentially consistent order of synchronization actions.
>> 
>> More generally, are there consequences turning CAS loops of get()+compareAndSet into getAcquire() + weakCompareAndSetRelease?
>> 
>>  
>> In addition, are there examples (or explanations) of when it is okay to use getOpaque/setOpaque  and would they work with the concurrent "queue" above at all?
>> 
>> (I guess there is not much difference for x86 but my code may end up on weaker platforms eventually.)
>> 
>> I think there is a difference on x86.  Conceptually, set/volatile write "drains the write buffer", while setRelease does not.
>> 
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu <>
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
> 
> 
> 
> -- 
> Sent from my phone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20160925/ec3cc6cb/attachment-0001.html>


More information about the Concurrency-interest mailing list