[concurrency-interest] Should I avoid compareAndSet with value-based classes?
shade at redhat.com
Tue Jul 11 15:01:11 EDT 2017
On 07/11/2017 08:22 PM, Gil Tene wrote:
> identityHash and synchronized have similarly strong behavior expectations
> when performed on the same object. If we say that the notion of "same object"
> applies to instances value based classes when evaluating ==, are we also
> saying that it also applies to synchronized and identityHash? [It must be.
> What's the alternative?]
Yes. You can get the instance of reference type, share it around, and it should
be fine: synchronized should work, identity hash code has to stay consistent. It
is irrelevant if that instance if the instance of value-based class or not.
What matters is that is _still_ a reference to an object, with all the
associated baggage. Which sucks. This is why you want value types in the
*language spec* that would make something that is not a reference type, and not
the primitive available at your disposal.
>> The only way out from here is to claim that either == is not reference
>> comparison, or there is some sort of conversion is taking place before ==.
> Value-purists might argue that == on a value based class is not a reference
> comparison because a field "referring" to an instance of value based class is
> not a reference. I'm not quite that pure tho.
Well, they can have their own non-compliant JVM then, because they ignore what
spec says "==" is, and come up with some interesting non-reference non-primitive
entity that is never mentioned in the language ;)
> I'd rely on ""Instances of a value-based class… are freely substitutable when
> equal, meaning that interchanging any two instances x and y that are equal
> according to equals() in any computation or method invocation should produce
> no visible change in behavior.".
Don't forget a *plus*, and this is a very large PLUS: behaviors with
identity-sensitive operations are unpredictable. Do I summarize it right that we
are arguing about what is the allowed behavior in the grey area of
"unpredictable behavior with identity-sensitive operations"?
You seem to claim that since identity-sensitive operations are unpredictable for
value-based classes, you might as well substitute instances. I seem to claim
that even the basic reflexivity rule in reference == prevents automatic
substitution, once the instance was created. You can play trick when creating
value-based class instances, though, and that's the freedom that definition
gives implementors. Once the instance is created, the ship had sailed.
Even if your claim is technically correct, and true in letter of the spec (which
I am still not sure about), I think it contradicts the spirit of it, which is:
- value types have no identity
- value-based classes have unknown (still stable) identity
- ordinary classes have known and stable identity
Value-based classes seem to be more of the library construct, that specifies the
overarching contract for any factory or method that creates them.
Value-based classes are the middle-ground between value types and ordinary
classes. They still are reference types. Their properties are almost as if they
are value types -- which might trip someone into believing they actually are --
but not quite, they differ in identity/nullability/etc properties.
I see no point in discussing this further without the actual language lawyers (I
think at valhalla- or somewhere-else-dev-).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the Concurrency-interest