[concurrency-interest] AtomicReference.updateAndGet() mandatory updating
gil at azul.com
Fri May 26 12:22:07 EDT 2017
> On May 26, 2017, at 6:56 AM, Doug Lea <dl at cs.oswego.edu> wrote:
> On 05/26/2017 09:35 AM, Andrew Haley wrote:
>> On 26/05/17 13:56, Andrew Dinn wrote:
>>>> Initially (in Java5) requiring it has led to some questionable reliance.
>>>> So we cannot change it. But there's not much motivation to do so anyway:
>>>> As implied by Nathan Reynolds, encountering some (local) fence overhead
>>>> on CAS failure typically reduces contention and may improve throughput.
>>> It would be useful to know if that reduction in contention is specific
>>> to, say, x86 hardware or also occurs on weak memory architectures like
>>> AArch64 or ppc. Perhaps Nathan could clarify that?
> The main issues are not tightly bound to architecture.
> In the vast majority of cases, the response to CAS failure is
> some sort of retry (although perhaps with some intermediate
> processing). The fence here plays a similar role to
> Thread.onSpinWait. And in fact, on ARM, is likely to be
> exactly the same implementation as onSpinWait.
> As Alex mentioned, in the uncommon cases where this
> is a performance issue, people can use one of the weak CAS
Actually this is another case where the Java 9 spec needs to be adjusted…
In Java 8, weakCompareAnbdSet is explicitly discussed in the j.u.c.atomic JavaDoc package description with this sentence:
"weakCompareAndSet atomically reads and conditionally writes a variable but does not create any happens-before orderings, so provides no guarantees with respect to previous or subsequent reads and writes of any variables other than the target of the weakCompareAndSet."
However, the current JavaDoc for VarHandle.weakCompareAndSet() (http://download.java.net/java/jdk9/docs/api/java/lang/invoke/VarHandle.html#weakCompareAndSet-java.lang.Object…- ) says:
"Possibly atomically sets the value of a variable to the newValue with the memory semantics of setVolatile(java.lang.Object...) if the variable's current value, referred to as the witness value, == the expectedValue, as accessed with the memory semantics of getVolatile(java.lang.Object…)."
It also mentions setVolatile(Object...), getVolatile(Object…) in the "see also" section.
This should probably be changed to drop the mentions of memory semantics requirement from weakCompareAnbdSet, and maybe even explicitly state that it makes no memory semantics guarantees (like the language in Java 8 did).
>> Just thinking about AArch64, and how to implement such a thing as well
>> as possible.
> "As well as possible" may be just to unconditionally issue fence,
> at least for plain CAS; maybe differently for the variants.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest