What does the Java – loadload barrier really do?

In Java, when two threads share the following variables:

int a;
volatile int b;

If thread 1 executes:

a = 5;
b = 6;

Then insert a storestore barrier between the two instructions, and "a" is refreshing back to main memory

Now if thread 2:

if(b == 6)
 a++;

Insert a loadload barrier between them. We guarantee that if the new value 'B' is visible, the new value 'a' is also visible But how is it actually achieved? Does loadload invalidate the CPU cache / registers? Or just instruct the CPU to get the value of the variable read from volatile again from the CPU?

I've found information about the loadload barrier（ http://gee.cs.oswego.edu/dl/jmm/cookbook.html )：

But it does not really explain how this is achieved

Solution

I will give an example to illustrate how to implement it You can read more details about here For x86 processors, you point out that loadload eventually becomes no ops Point out in my linked article

So essentially, the only obstacle needed is storeload. Net for x86 architecture So how to achieve it at a low level?

This is a blog excerpt

The following code is generated for volatile and nonvolatile reads:

nop                       ;*synchronization entry
mov    0x10(%rsi),%rax    ;*getfield x

For volatile writing:

xchg   %ax,%ax
movq   $0xab,0x10(%rbx)
lock addl $0x0,(%rsp)     ;*putfield x

The lock instruction is storeload. Com listed in Doug's recipe However, the lock instruction also synchronizes all reads with other processes as listed

This reduces the overhead of issuing loadload loadstore barriers for volatile loads

All this, I will reiterate what assylias pointed out It's not important for developers that this happens (if you're interested in the processor / compiler implementer of another story) Volatile keyword is an interface term

>You will get the latest update written by another thread > you will not be burned by JIT compiler optimization