[concurrency-interest] AtomicReference.updateAndGet() mandatory updating
oleksandr.otenko at gmail.com
Fri May 26 04:52:42 EDT 2017
A store is not never happened, it is a store of the same value that is already there.
Boolean response of CAS in the Java 8 semantics provided witness of mutual exclusion. weakCompareAndSet doesn’t provide such a witness. Use weakCompareAndSet, when you don’t care about the visibility of prior stores on fail.
> On 26 May 2017, at 09:44, Andrew Haley <aph at redhat.com> wrote:
> On 25/05/17 18:15, Gil Tene wrote:
>> Sent from my iPad
>>> On May 25, 2017, at 3:42 AM, Doug Lea <dl at cs.oswego.edu> wrote:
>>>> On 05/25/2017 06:16 AM, Andrew Haley wrote:
>> While on this subject, was the relative "weakening" of compareAndSet (and other) memory semantics between Java 8 and java 9 discussed elsewhere?
>> In java 8, a compareAndSet has the memory semantics of a volatile write regardless of whether or not the write occurred. In java 9 it only has a volatile write effect if the write occurs. While the loosening in the non-writing case may allow for additional optimizations, I worry that it may break existing code that could rely on the previous behavior.
> That property of compareAndSet is very ugly, and is a pain to implement.
> Most of the CAS instructions I know about don't have such a property,
> and making it work requires either an unconditional full fence after every
> CAS or a conditional one if it fails. Either way sucks mightily and
> is unlikely to be useful except in the most pathological cases.
> Besides, how does it ever make sense to synchronize with a store that
> never happened?
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest