JMM, volatile keyword, memory barriers, happens-before principle, cache coherency

0. Introduction

In learning about the volatile keyword me, collecting a lot of information online when basic will see these keywords in the title, then I looked up to me with information as to the concept of the series and resolution. This article is a summary of the multi-information, in the text there will be many key parts labeled reference link, you can click on to view more detail.

 

 

 

1, cache coherency problem

 

Description: To compensate for differences in the speed of the CPU and memory, the cache will be separated (Cache) between the CPU and memory. In a multi-level cache architecture, each core multi-core CPU has their own level cache ( reference link ), in this case, the multi-threaded operation will generate cache coherency problem. To shared variables between threads i ++, for example, the initial value of i is 0, then at the beginning of each cache stores a value of 0 i, when the first piece of the kernel do i ++, the value of its cache became 1, even immediately written back to main memory, then after the second write-back cache block i kernel value is still 0, i ++ its implementation, the memory will be written back to cover an operation of the first core, so that the final memory the result is 1, instead of the expected 2. So in order to avoid this situation, we need some way to achieve consistency between the various cache CPU.

 

A bus lock: When one of the processors to the shared memory operation, issue a LOCK # signal on the bus, this signal so that other processors can not gain access to the data to the shared memory by a bus, the CPU and memory bus lock communication between the locked, which makes during locking, other processors can not operate the other data memory address bus lock overhead is relatively large, this mechanism is clearly inappropriate.

 

MESI protocol: In order to achieve consistent data access, each processor needs to follow some protocol when accessing the cache, operate according to the protocol at the time of reading and writing, there is common agreement MSI, MESI, MOSI and so on. The most common is the MESI protocol. About MESI can view the venue ( reference link ) Note: MEIS solve is inconsistent with core proprietary cache problem, the actual CPU architecture is very complex, there are a lot of cache, buffer, queue, they are also CPU architecture does not support the case of MESI.
 
 
 
 
 
 
 
 
2、JMM(JAVA Memory Model)
 
The concept: Java Virtual Machine Specification trying to define a Java Memory Model (JMM), to block out the memory access a variety of hardware and operating system differences, so that Java programs on a variety of platforms to achieve the same effect memory access.
 
(Oracle defined :) multithreaded behavior may be confusing and counterintuitive, especially when not properly synchronized. This chapter describes the semantics of multithreaded programs; it includes a number of rules governing the update is multi-threaded shared memory which can be read to value. Because this definition with different hardware platform system memory model is very similar, so these are generally referred to as semantic memory model java programming language. There is no ambiguity, we can simply call these rules "memory model"      
 
( Wikipedia :) memory model describes the interaction java multithreading and shared memory. Furthermore, java memory model describes the value in shared memory is modified and read multithreaded process, a predetermined order of execution visibility and shared variables.
 
( JSR133 ) 11 page describes the related memory model.
 
Anyway, provides for a series of memory access operations rules, defines the set of grammar, the syntax is projected into the Java language is volatile, synchronized and other keywords.
 
Note: the JVM memory structure is entirely two things, details => ( reference link )
 
Three principles: JMM mainly centered on how to how to handle the atomic concurrent process, visibility and order of these three features to build, by addressing these three issues, the problem can be lifted cache inconsistency. About three characteristics, you can refer to this article ( refer links )
 
 
 
 
 
 
 
 
 
3, happens-before principles:
 
Description: In the ordering, some default provision JMM "innate principle" principle known as happens-before, happens-before A B A refers to perform before B, and the result of the operation A to be visible to B
 
Specifically: ( reference link )

 

 

 

 

 
4, volatile keyword and memory barrier
 
1) volatile keyword to ensure the visibility of the JMM memory model
2) volatile does not guarantee atomicity
3) volatile at compile time can prevent rearrangement JAVA code to ensure orderly implementation principle is the memory barrier
volatile memory barrier strategy is very closely guarded, and no sense of security very pessimistic state of mind:
  • Inserted before each write operation in volatile StoreStore (the SS) barrier , the barrier is inserted StoreLoad write operation;
  • Volatile inserted before each read operation LoadLoad (LL) barrier , the barrier is inserted LoadStore After the read operation;
 
Specific can see links ( reference links , reference links )
 
 
 
 
 
 
5, MESI and JMM is not directly in the volatile strong association!
 
引入缓存一致性的问题描述是为了帮助理解后面的 volatile 的知识点,但是很多时候会被人搞混,volatile 只是在语言语义层面做了规定,与实际的实现相比是经过了许多层的抽象,其中就有可能用到 MESI 来解决,所以说联系不是没有,但是搞清楚 MESI 与 JMM 甚至 volatile 没有直接的关系,拿过来直接进行比较实际上是不太对的。详情可见(参考连接
 
 
 
 
 
 
6、链接集合

 

Guess you like

Origin www.cnblogs.com/qwertiLH/p/12501518.html