I wrote this simple Java program:

This generate the following disassembled code for i++ and j++ (remaining disassembled code removed):

This is what I understand about the following assembly code:

mov r10,7d5d0e898h : Moves the pointer to the IncrementClass.class to register r10
inc dword ptr [r10+74h] : Increments the 4 byte value at the address at [r10 + 74h],(i.e. i)
mov r11d,dword ptr [r10+70h] :Moves the 4 value value at the address [r10 + 70h] to register r11d (i.e move value of j to r11d)
inc r11d : Increment r11d
mov dword ptr [r10+70h],r11d : write value of r11d to [r10 + 70h] so it is visible to other threads -lock add dword ptr [rsp],0h : lock the memory address represented by the stack pointer rsp and add 0 to it.
JMM states that before each volatile read there must be a load memory barrier and after every volatile write there must be a store barrier. My question is:

Why isn't there a load barrier before the read of j into r11d?
How does the lock and add to rsp ensure the value of j in r11d is propogated back to main memory. All I read from the intel specs is that lock provides the cpu with an exclusive lock on the specified memory address for the duration of the operation. Why is i++ not atomic or thread safe. If you look at the instruction incrementing i "inc dword ptr [r10+74h]" this should directly write to memory and every other thread should be able to see this value. From what I understand when the CPU writes to memory as above this value is cached in the cache line and doesn't go all the way to memory and so an explicit instruction is needed for it to write to memory. Which I believe is the LOCK statement but how does a LOCK on the stack pointer ensure the value in the cache gets written to memory[/code]

Volatile means that the value must be in memory, i.e not in a register. Volatile provides no guarantee that it is thread safe. If you need thread safe then use a mutex, a critical section or a lock.

About the cache thing. The cache coherency protocol ensure that all other cores will see the new value.

And memory barriers are more designed for transactions rather than thread safety.

Yes I understand that volatile is not thread safe or atomic. I am asking as to how does the above assembly code bypass the cache and ensure that the volatile variable is written to memory. Then why isn't the value of i not seen by other thread?

if the cache coherence policy will make the value of j to be seen by other threads will the value of i also be seen by other threads which is being incremented by this statement "inc dword ptr [r10+74h] ". Also what is the LOCK statement doing? What is it's role in making sure that the volatile write gets propogated to memory?

Volatile just means to always read and write a new value to/from memory. That is, don't keep it in a register. Originally it was used for I/O type memory that needs to see all changes (like a comms data port for example).

I reread your Qs and perhaps your confusion is because you are conflating caches with memory and idempotentcy. Volatile tells the compiler that the memory is not idempotent. The involvement of caches in no way affects the results of the program unless the caches have been configured incorrectly by the BIOS/OS on inappropriate memory (unlikely).