Is volatile read happens-before volatile write?

Question

I try to understand why this example is a correctly synchronized program:

a - volatile
Thread1:
x=a
Thread2:
a=5

Because there are conflicting accesses (there is a write to and read of a) so in every sequential consistency execution must be happens-before relation between that accesses. Suppose one of sequential execution:

1. x=a
2. a=5

Is 1 happens-before 2, why?

Answer 1

Is 1 happens-before 2, why?

I'm not 100% sure I understand your question.

If you have a volatile variable a and one thread is reading from it and another is writing to it, the order of those accesses can be in either order. It is a race condition. What is guaranteed by the JVM and the Java Memory Model (JMM) depends on which operation happens first.

The write could have just happened and the read sees the updated value. Or the write could happen after the read. So x could be either 5 or the previous value of a.

every sequential consistency execution must be happens-before relation between that accesses

I'm not sure what this means so I'll try to be specific. The "happens before relation" with volatile means that all previous memory writes to a volatile variable prior to a read of the same variable are guaranteed to have finished. But this guarantee in no way explains the timing between the two volatile operations which is subject to the race condition. The reader is guaranteed to have seen the write, but only if the write happened before the read.

You might think this is a pretty weak guarantee, but in threads, whose performance is dramatically improved by using local CPU cache, reading the value of a field might come from a cached memory segment instead of central memory. The guarantee is critical to ensure that the local thread memory is invalidated and updated when a volatile read occurs so that threads can share data appropriately.

Again, the JVM and the JMM guarantee that if you are reading from a volatile field a, then any writes to the same field that have happened before the read, will be seen by it -- the value written will be properly published and visible to the reading thread. However, this guarantee in no way determines the ordering. It doesn't say that the write has to happen before the read.