[concurrency-interest] Question about reordering and volatile

Peter Veentjer alarmnummer at gmail.com
Tue Apr 1 09:56:08 EDT 2008

Sorry for my unclarity.  I mean one volatile write, and other non
special and of course non dependent operations.

so something like:

int a;
volatile int b;

void original_foo(){

void illegal_reordened_foo(){

On Tue, Apr 1, 2008 at 3:23 PM, Dhanji R. Prasanna <dhanji at gmail.com> wrote:
> On Tue, Apr 1, 2008 at 5:34 PM, Peter Veentjer <alarmnummer at gmail.com>
> 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.
> I'm not sure I understand correctly--are you saying that volatile operations
> can safely be reordered (wrt other threads) to occur prior to a given
> volatile write? Won't that make it no different than a non-volatile
> variable?
> Or do you mean non-volatile operations (i.e. not involving a volatile
> variable) can be reordered around the volatile write?
> Dhanji.

More information about the Concurrency-interest mailing list