[concurrency-interest] Stricter read ordering

Aleksey Shipilev aleksey.shipilev at oracle.com
Wed Apr 23 09:36:14 EDT 2014

On 04/23/2014 05:05 PM, Tobias Lindaaker wrote:
> Yes, I had a look at StampedLock and Unsafe.loadFence(), and it seems
> to do exactly what I want, and if I was fortunate enough to be able
> to move to Java 8 I would use it. Unfortunately we are still stuck on
> Java 7. We even have customers who are still strongly requesting Java
> 6 compatibility.

These constraints make the problem unresolvable.

You might want to look for pre-JDK8 prototype for StampedLock [1]:

     * As noted in Boehm's paper (above), sequence validation (mainly
     * method validate()) requires stricter ordering rules than apply
     * to normal volatile reads (of "state").  In the absence of (but
     * continual hope for) explicit JVM support of intrinsics with
     * double-sided reordering prohibition, or corresponding fence
     * intrinsics, we for now uncomfortably rely on the fact that the
     * Unsafe.getXVolatile intrinsic must have this property
     * (syntactic volatile reads do not) for internal purposes anyway,
     * even though it is not documented.

    public boolean validate(long stamp) {
        return (stamp & SBITS) == (U.getLongVolatile(this, STATE) & SBITS);

But if Unsafe.loadFence() is risky since it is not specified (yet)
JMM-wise, and so interactions with other volatile ops and fences is just
undocumented... then using Unsafe.getXVolatile is double-risky because
the behavioral effect of read ordering is *REALLY*
implementation-specific, and you if are using it for read ordering, you
are five miles past the gateway to Hell already.



More information about the Concurrency-interest mailing list