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

Dávid Karnok akarnokd at gmail.com
Sat Sep 24 09:19:16 EDT 2016


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)? 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.)



-- 
Best regards,
David Karnok
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20160924/17b53961/attachment-0001.html>


More information about the Concurrency-interest mailing list