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

Vitaly Davidovich vitalyd at gmail.com
Fri Jul 7 13:52:52 EDT 2017


At worst, you can extract/pack CAS-width-compatible value (e.g. long) and
use that as the CAS storage.  Then materialize the VT from that on the fly
after reading the storage value out.  If that's not possible, then you use
locking, put it behind a heap object, or whatever other mechanism.

That's roughly what you do in the CLR, which doesn't allow CAS on structs
(irrespective of its size).

On Fri, Jul 7, 2017 at 1:42 PM Alex Otenko <oleksandr.otenko at gmail.com>
wrote:

> I think there is a bit of a split mind here: what the value class instance
> is (is it Object-like in the language spec, so does it behave like
> references?), and what the value class instance is implemented as by the
> JVM (is it Object-like in the actual memory layout, so does it behave like
> a reference?).
>
> The value class instance does not necessarily fit in a single machine word
> - time Instance certainly doesn’t. If the time Instance is “inlined” by the
> JVM, then you can’t guarantee atomicity of writes, and atomicity of reads
> also, so the reads also need to use a synchronized block - whether demand
> that explicitly from the programmer, or do that implicitly, like it’s done
> for volatile long on some platforms, does not matter. (Or use StampedLock,
> as Doug points out).
>
> If it’s done implicitly by the JVM that “inlines” the value class
> instance, then there is no need to require extra steps from the programmer.
>
>
> Alex
>
>
> > On 7 Jul 2017, at 14:26, Andrew Haley <aph at redhat.com> wrote:
> >
> > On 07/07/17 13:27, Alex Otenko wrote:
> >
> >> If you are updating a reference, then CAS can also work.
> >
> > Well, that is the subject of some contention here, because the spec
> > *explicitly* says you should not compare quality, and that is what a
> > CAS does.  But the re is no need for a CAS; synchronized will do, and
> > it allows you to call equals() rather than using reference equality.
> >
> > In practice, avoiding the use of reference equality is not a problem.
> > That is my point.
> >
> >> If you are talking about imitating update of the reference by
> >> mutating inlined object contents,
> >
> > You're not in this case.
> >
> >> then you do need synchronized for readers.
> >
> > --
> > 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
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20170707/d5e5e82b/attachment.html>


More information about the Concurrency-interest mailing list