[concurrency-interest] AtomicReference.updateAndGet() mandatory updating

Andrew Haley aph at redhat.com
Fri May 26 04:44:12 EDT 2017


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


More information about the Concurrency-interest mailing list