[concurrency-interest] jdk9 VarHandle and Fence methods

Vitaly Davidovich vitalyd at gmail.com
Fri Aug 21 18:04:55 EDT 2015


That wouldn't be a CAS if that outcome were possible.  My understanding is
the ordering in those CAS variants dictates ordering of memory accesses
before and after the CAS with respect to the CAS itself.

sent from my phone
On Aug 21, 2015 5:09 PM, "Peter Levart" <peter.levart at gmail.com> wrote:

> Hi Doug,
>
> On 08/21/2015 03:44 PM, Doug Lea wrote:
>
>     /**
>      * Atomically sets the value to the given updated value with the
>      * memory semantics of setRelease if the current value {@code ==}
>      * the expected value, as accessed with the memory samantics of
>      * getRelease.
>
>             ^^^^
> Should that be getRelaxed or more probably getAcquire ?
>
>      *
>      * @param expected the expected value
>      * @param val the new value
>      * @return the current value, which will be the same as {@code val} if
>      * successful.
>      */
>     T compareAndExchangeRelease(Object owner, T expected, T val);
>
>
> Suppose the value is currently 1 and two threads do the following
> concurrently:
>
> Thread1:
>
> v1 = compareAndExchangeRelease(owner, 1, 2);
>
> Thread2:
>
> v2 = compareAndExchangeRelease(owner, 1, 3);
>
>
>
> Can the outcome be: v1 == 2, v2 == 3 ?
>
> If it is getAcquire then probably not, but if it is getRelaxed then It
> might be or not?
>
>
> Regards, Peter
>
>
> _______________________________________________
> 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/20150821/13a73494/attachment.html>


More information about the Concurrency-interest mailing list