[concurrency-interest] Question about reordering and volatile
jmanson at cs.umd.edu
Tue Apr 1 17:06:25 EDT 2008
"Roach Motel" applies to synchronized blocks -- instructions can move
into them, but not out. So, normal accesses can be moved from after a
monitorexit to before it, and from before a monitorenter to after it.
That's the roach motel principle.
The same reasoning applies to volatiles under the assumption that a
volatile write is "the same" as a monitorexit and that a volatile read
is "the same" as a monitorenter.
So, your answer is that you *can* move normal accesses that occur after
a volatile write to before it.
Peter Veentjer wrote:
> I have a question about reorderings and volatile writes.
> Reorderings and volatile writes follow the 'roach motel' (just like
> synchronized blocks) that prevents instructions from jumping over.
> Allowing an instruction before a volatile write on variable x to jump
> over that write, can lead to not seeing the effects of that
> instruction when you do the volatile read on x.This is not allowed
> according to the JMM: all changes made in thread a when it does a
> volatile write on x, are visible when thread b does a volatile read
> on x. Ok.. no problem so far.
> But what about instructions after the volatile write? If these were
> allowed (and they are not according to the roach motel principle) to
> jump in front of the volatile write of x, thread b could see these
> changes as well. The results are exactly the same as the situation
> that the read of x (by thread b) happens after the instruction after
> the volatile write has executed (by thread a). So the letting the
> instruction after the write to (volatile variable) x, in front of this
> write, would not cause any havoc.
> So what is the reason that instructions after the volatile write are
> not allowed to jump over this volatile write?
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
More information about the Concurrency-interest