[concurrency-interest] Stricter read ordering

Oleksandr Otenko oleksandr.otenko at oracle.com
Wed Apr 23 12:08:38 EDT 2014


storeFence here can be replaced with a volatile load.

eg

this.next=next;
next=this.next;

will do. (plus the question of ordering normal loads in the middle of 
volatile loads)

Alex


On 23/04/2014 15:12, Tobias Lindaaker wrote:
> See comments below.
>
> On 23 Apr 2014, at 15:36 , Aleksey Shipilev 
> <aleksey.shipilev at oracle.com <mailto:aleksey.shipilev at oracle.com>> wrote:
>
>> 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.
>>
>> Thanks,
>> -Aleksey.
>>
>> [1]
>> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166e/StampedLock.java?revision=1.1
>
> Thank you Aleksey,
>
> Those incidental implementation implications of 
> Unsafe.get*Volatile(...) is exactly what we were looking for.
> I agree that it is scary and sad to have to rely on these things (and 
> that even in Java 8, many things you need is hidden behind the 
> discouraging name of "sun.misc.Unsafe"), but it's the reality of 
> working on the JVM. Given how far we've already ventured beyond those 
> gates, five more miles will make virtually no difference...
>
> As a side note, if we could move to Java 8, it is possible that 
> StampedLock could completely fulfil this use case, and that we could 
> use that to simplify our code here. Although we would have to measure 
> the implications of the indirection that would add.
>
>
> On 23 Apr 2014, at 15:16 , Oleksandr Otenko 
> <oleksandr.otenko at oracle.com <mailto:oleksandr.otenko at oracle.com>> wrote:
>> Your code does lead to inconsistencies.
>>
>> A permitted reordering is:
>>
>> this.x=x; can go ahead of this.next=next;, which will lead to the 
>> reading thread observe written==next, yet x being updated, and not y.
>>
>> Alex
>>
>
> You are right Alex, there is of course that reordering problem as 
> well, and I would need similar fencing there too.
>
> I would think this would suffice in Java 8:
>
>       public synchronized void update( int x, int y ) {
>         long next = this.next + 1;
>         this.next = next;
>         Unsafe.storeFence(); // <- this being the added line
>         this.x = x;
>         this.y = y;
>         this.written = next;
>       }
>
>
> ... and is there some primitive with similar incidental implications 
> to what Aleksey pointed out for the load fence (but for store fencing 
> in this case) that could be used in earlier JDKs?
>
> Thank you both,
> Tobias
>
>
> _______________________________________________
> 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/20140423/7ccbcf6d/attachment.html>


More information about the Concurrency-interest mailing list