[concurrency-interest] Should I avoid compareAndSet with value-based classes?

Andrew Haley aph at redhat.com
Mon Jul 10 05:22:22 EDT 2017


On 08/07/17 13:22, Gil Tene wrote:
> 
>> On Jul 8, 2017, at 1:19 AM, Andrew Haley <aph at redhat.com> wrote:
>>
>> On 08/07/17 07:38, Gil Tene wrote:
>>
>>> My arguments here are not about trying to justify some compiler
>>> optimizations, or trying to justify the choices of making these
>>> things subclasses the Object. They are about pointing out the actual
>>> meaning of things as defined and the (very high risk) of coding
>>> against it based on a hope that some temporarily observed behavior
>>> is actually reliable, when everything that describes what it does
>>> says otherwise.
>>
>> I disagree with this interpretation.  You're interpreting the language
>> in that paragraph as overriding some fundamental properties in the JLS.
> 
> To keep this to a simple case that
> 
> What specific property of the JLS requires that == not be always-false?

I think the ontion that

> I.e., what is it in the JLS that requires that this loop ever
> terminate when there is no external interference by another thread?:
> 
>   // David Lloyd's example from earlier in the thread (Jul 6, 10:48AM PDT):
>   AtomicReference<Instant> atomic;
>   Instant a, b;
>   ...
>   do {
>       a = atomic.get();
>       b = compute(a);
>   } while (! atomic.compareAndSet(a, b));
> 
> 
> or for that matter, that this loop ever terminate when there is no
> external interference by another thread?:
> 
>   volatile Instant thing;
>   Instant a, b;
>>   boolean success = false;
>   do {
>       a = thing;
>       b = compute(a);
>       if (thing == a) {
>           thing = b;
>           success = true;      
>       }
>   } while (!success);
> 
> The termination of both of these loops relies on the notion of
> identity (the logical value of a reference) being preserved between
> the reading of a reference to an instance of a value-based class
> from memory, and the eventual comparison of that instance's
> reference with another one stored in a memory location.

Indeed.  I already quoted the language in the JLS I'm relying on, and
said that I find it convincing.  I believe that 15.21.3, "Reference
Equality Operators == and !=" would have to be changed in order for
your interpretation of reference equality to be correct.

So let's move on to another matter, the JVM specification, and the way
that Java maps on to the JVM.  In the JVM, the instruction if_acmpeq
is supposed to return true if value1 = value2.  So,

   dup; if_acmpeq

is bound to succeed.

You could argue that it is theoretically possible that Java could be
compiled onto the JVM in some other way, so that your interpretation
of the JLS would be correct, but I don't think it's much to worry
about.  You could also argue that the section which describes
value-based classes implicitly changes the JVM specification, but I'd
like to see that in writing.

-- 
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