Memory barrier and JVM concurrency

The memory barrier, also known as the memory fence, is a set of processor directives that enable you to limit the order of memory operations. This paper describes the effect of memory barrier on multithreaded routines. We will examine the relationship between the memory barrier and the JVM concurrency mechanism, such as variables (volatile), synchronization (synchronized), and atomic conditions (atomic conditional). This paper assumes that the reader has fully mastered the relevant concepts and Java memory model, and does not discuss concurrent mutexes, parallelism, and atomicity. The memory barrier is used to achieve the same important role as visibility (visibility) in concurrent programming.

Why is the memory barrier important?

A visit to main memory typically costs hundreds of times the hardware clock cycle. Processors can reduce the cost of memory latency from the order of magnitude through caching (caching) These caches reorder the pending memory operations for performance. That is, the program's read and write operations do not necessarily follow the order in which the processor is required. These optimizations are harmless when the data is immutable and/or the data limit is within the range of the thread. If these optimizations are combined with symmetric multiple processing (symmetric multi-processing) and shared mutable state, then it is a nightmare. When a memory operation based on a shared mutable state is reordered, the program may behave uncertainly. Data written by one thread may be visible to other threads because the sequence of data writes is inconsistent. The appropriate place memory barrier avoids this problem by forcing the processor order to perform pending memory operations.

The coordinating function of memory barrier

The memory barrier is not directly exposed by the JVM, instead they are inserted into the instruction sequence by the JVM to maintain the semantics of the language layer concurrent primitives. We study the source code and assembly instructions for several simple Java programs. First take a quick look at the memory barrier in the Dekker algorithm. The algorithm uses volatile variables to coordinate the access of shared resources between two threads.

Please do not pay attention to the excellent details of the algorithm. What parts are relevant? Each thread attempts to enter the critical area of the first line of code by signaling. If the thread is aware of the conflict in the third row (two threads are to be accessed), resolve it by turn the variable. Only one thread can access critical areas at any point in time.

//　code　run　by　first　thread　　　//　code　run　by　 second　thread

　 1　　intentFirst　=　true;　　　　　intentSecond　=　true;
　 2
　 3　　while　(intentSecond)　　while　(intentFirst)　　　　//　 volatile　read
　 4　　　if　(turn　!=　0)　{　　　if　(turn　!=　1)　{　　　　//　 volatile　read
　 5　　　　intentFirst　=　false;　　　　intentSecond　=　false;
　 6　　　　while　(turn　!=　0)　{}　　　　while　(turn　!=　1)　{}
　 7　　　　intentFirst　=　true;　　　　intentSecond　=　true;
　 8　　　}　　　　　　　　}
　 9
10　　criticalSection();　　criticalSection();
11
12　　turn　=　1;　　　turn　=　0;　　　　　　　　　//　volatile　 write
13　　intentFirst　=　false;　　intentSecond　=　false;　　　//　 volatile　write