[concurrency-interest] AtomicReference.updateAndGet() mandatory updating
gergg at cox.net
Sat May 27 21:19:44 EDT 2017
If there are 5 stores before that store, and it’s those values, plus the CAS target that move your state forward, then the fence on CAS can be vital to correct software. Since the MM interactions are costly, they are always targets for elimination by systems architects and developers who are aware of those details. Processors with huge, costly MM interactions are the bigger concern. Why are we still fighting against the processor, instead of having highly performant systems which don’t care about the processor? That’s a big question that I’ve asked for more than a decade now. We keep coming back around to micromanaging cache lines and other MM interactions in our software because that model of core to core data synchronization has never really proven to be a solution as much as it is a reason why software can be randomly wrong.
> On May 26, 2017, at 3:44 AM, 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