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

Martin Buchholz martinrb at google.com
Sat Sep 24 13:10:21 EDT 2016


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20160924/84c624b0/attachment-0001.html>


More information about the Concurrency-interest mailing list