How to prevent statements from being reordered by the JVM

Question

is there way to ensure that doA is executed before doB? One thing I thought of was wrapping each statement in a synchronized block.

object1.doA();
object2.doB();

Do method calls on a volatile variable act as volatile writes?

Edit - what I actually need is for other threads to see the effects of doA before those of doB.

Answer 1

These statements won't be reordered from the perspective of the thread that executes that piece of code (they may be reordered in practice, but only if the reordering has no effect from the perspective of that thread).

However another thread may see the results of doB before seeing the results of doA. If that is an issue, you should lock around the code to make it atomic, for example by using a synchronized block.

Note that using two synchronized blocks does not achieve much - in particular it is very likely that the JVM will merge them into one anyway (assuming they use the same monitor, but if they don't then you won't necessarily achieve atomicity).

Answer 2

It all depends on where you observe the effects of the calls to doA() and doB() from.

• If you observe the effects from the same thread as is executing the calls, then you are guaranteed to see them as is there had been no reordering. Reordering is not allowed to change the single-threaded behaviour. If the code as written says that doA() is called before doB(), then that is what the thread will observe ... if it is looking. In short, no surprises.

• If you observe the effects from a different thread, then that thread is guaranteed to be able to observe a state consistent with the single-threaded case at synchronization points. However if one thread attempts to observe the actions of another thread without proper synchronization, then it may observe the effects of reordering.

So ...

How to prevent statements from being reordered by the JVM

Actually, I don't think that you can. But if you code your (multi-threaded) application correctly, it won't be able to observe the effects of reordering. And if it can't observe the effects, it doesn't make any difference to the behaviour if there is or isn't any reordering.

Do method calls on a volatile variable act as volatile writes?

No.

The calls themselves have no specific synchronizing behaviour, but they are preceded by a volatile read (naturally).

... what I actually need is for other threads to see the effects of doA before those of doB.

Then the code must be written so that there is proper synchronization when the state changed by the respective calls is accessed. Technically, there needs to be proper "happens-before" ordering between the writes on one thread and subsequent reads on other threads ... for all of the state that is affected by the method calls.

No magic. No short-cuts. Just properly written synchronization.