[concurrency-interest] sequential consistency between volatile write and volatile read

Boehm, Hans hans.boehm at hp.com
Sun Oct 17 19:03:42 EDT 2010


So long as your code doesn't allow simultaneous conflicting accesses to a non-volatile variable, the Java memory model guarantees sequential consistency (with the exception of a few j.u.c. methods that explicitly don't, like lazySet).  If I understand your code correctly, that applies here, and your assumption is incorrect.

I'm not sure that all implementations get this 100% right, but the specification does not allow the kind of reordering you describe.

Hans

From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Peter Veentjer
Sent: Sunday, October 17, 2010 2:22 PM
To: concurrency-interest at cs.oswego.edu
Subject: [concurrency-interest] sequential consistency between volatile write and volatile read

I'm struggling with the following problem (part of the commit of an stm).

        ___value = tranlocal.value;
        ___version = tranlocal.version+1;

        //JMM problem here, the volatile read of ___listeners could jump in front of the volatile write of
        //version, meaning that it could lead to not picking up the listeners that is done after the write. And
        //this could lead to a deadlock.
        Listeners listenersAfterWrite = ___listeners;

        if(listenersAfterWrite != null){
           listenersAfterWrite = ___removeListenersAfterWrite();
        }

In this example ___value, ___version and ___listeners are volatile and the rest is a normal variable. The problem here is that the read of ___listeners could jump in front of the volatile write of ___version or even ___value. The consequence is that it could happen that listeners that should been picked up after writing the value, don't need to be picked up (because the read happened too early) and this could lead to a deadlock since listeners that should have been notified, are not notified.

Is my assumption correct that this problem could happen?

I'm currently trying to figure out why transaction enter a deadlock and this deadlock can be explained by this bug in the stm code.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20101017/d12f0081/attachment.html>


More information about the Concurrency-interest mailing list