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

Martin Buchholz martinrb at google.com
Sat Sep 24 19:04:19 EDT 2016


We know the docs could be better, but we do have
"""Ignoring the many semantic differences from C and C++, this method has
memory ordering effects compatible with memory_order_acquire ordering."""
http://download.java.net/java/jdk9/docs/api/java/lang/invoke/VarHandle.html#getAcquire-java.lang.Object...-

On Sat, Sep 24, 2016 at 2:34 PM, Alex Otenko <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.
>
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20160924/7ec088df/attachment.html>


More information about the Concurrency-interest mailing list