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

Peter Veentjer alarmnummer at gmail.com
Sun Oct 17 17:22:13 EDT 2010

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/7b381d16/attachment.html>

More information about the Concurrency-interest mailing list