同步块中的读取障碍和写入障碍是什么

Question

I am looking into how a synchronized and volatile variable works in java and i came across a concept called read and write barrier . Can anyone help me to understand the meaning of this terms

Answer 1

( the answers above are quite complete), I just want to demonstrate the concept with a simple scheme

 Thread 1                                                             Thread 2


   |          
   |                                                                      
   |                                                                      |
   |                                                                      |
   |  Everything Thread 1                                                 |
   |   wrote before here                                                  |
   |                                                                      |
   |                                                                      |
    _ _ _ _ _ _ _ _ _ _                                                   |
      ( write  barrier)         (happens before)         (read barrier)   |
   |                                                     _ _  _ _ _ _ _ _  
   |
   |                                                   is guaranteed      |
   |                                                  to be visible to    |
   |                                                  Thread 2            |
   |                                                                      |

Answer 2

A memory barrier is a conceptual "line" in your code that prevents the compiler from making certain optimizations and may insert special "sync up" commands to the processor. Normally, the compiler can look within a particular method and see that certain instructions can be moved around without changing the meaning of the code. For example, if you have

int x = 0, y = 0;
x++;
y++;

If the compiler figured that there was some benefit, it could instead output code for

y++;
x++;

However, if x and y are fields in some class, so that they can be seen from other threads, the other thread might be modifying the values while your method is running.

A memory barrier forces the compiler to recheck the values of specific variables (in Java, those are ones that are volatile and the Atomic* classes) in case some other thread has modified them while the method's been running, and it keeps the compiler from making reorderings that might accidentally change the results of a calculation. On systems that support multiple cores/processors, the compiler will also force the processor to check to make sure that some other processor or hardware device hasn't modified the variable in the meantime. Java (as of Java 5) has an extremely well-defined set of rules for how this works called happens-before .

This FAQ has some useful explanations that were written at the time the Java Memory Model was being developed. Note that while the concept of a memory barrier is cross-language, most languages don't have as clearly defined rules about them as Java.

Answer 3

When you enter a synchronized block of code you pass the "read barrier" and when it is exited you pass the "write barrier".

Is is used in reference to volatile attributes, and give an indication when Threads need to update their values of the volatile attributes. They should update it when they are passing the read barrier if anyone else passed the write barrier.

Similar reading from a volatile attribute makes yout thread pass the read barrier and writing to a volatile attribute makes you pass the write barrier, hence much more fine grained than a synchronized block.

Answer 4

Read and write barriers are used to implement the semantics of the Java Memory Model at the lowest level by JVMs.

However that terminology is absent from the Java Language Specification, which only reasons in terms of happens-before relationships. In particular

• a write to a volatile variable happens-before a subsequent read of that same variable
• exiting a synchronized block happens-before a subsequent entry of that same syncchronized block

When a happens-before relationship exists between two actions in your program, you have the guarantee that those two actions will be executed in a sequentially consistent order (ie as if there were only one thread and without unintuitive reorderings).

Delving into the implementation details of the JVMs is unnecessary to write a correct multi-threaded program. However, if you want the gory details, the JSR-133 cookbook is an interesting read.