The reasons for the
memory consistency error
cause memory consistency errors are many and complex. Different CPU architectures, different instruction reading modes, and different memory management modes can cause memory inconsistency errors. Typically, the server provider provides some strategies for better computing performance, but better performance can also result in memory consistency errors, so the server provider provides new policies to circumvent memory consistency errors. Just like we usually do when programming, no one strategy can solve all the problems, according to the business to choose. The server provider has the same problem as we do, so the provider also offers a variety of strategies for developers to choose from, some with strong computational power, but more prone to memory consistency errors. Some are just the opposite. There are a lot of server providers, and the policies offered are different, and developers need to know the policies that are available on the program's running machines, usually the server provider makes a pact with the developer, what kind of statement will adopt the strategy, and this Convention is also called the memory model (memory models). For developers, this is a lot of work, the finished program will run well on one machine, and it will produce strange results on another machine. Because two machines cannot guarantee that the program's statement will be executed in the same way. Fortunately we are not directly interacting with the hardware, we are programming on the operating system, the operating system to help us assimilate different hardware. If a program is running on a virtual machine (the JVM or the. NET Framework), the virtual machine also optimizes the instructions, and the virtual machine provides the developer with a memory model that balances performance and memory consistency. With the above description, there seems to be no way to make a clear description of the running state of the memory consistency error. All we can do is follow the conventions in the memory model (the conventions in the memory model can also be called Happens-before relationship) to program.
Thread interference
It is possible for multiple threads to manipulate a variable to generate thread interference. Threading interference refers to the following: A variable A, computed at the same time by Thread1 and Thread2, Thread2 ignores the thread1 operation, or vice versa. For example: There is a statement C + +, executed by thread1,thread2. C + + This statement generated instructions are:
First step: Get the current value of C
Step two: The value returned on the first step is +1
Part III: Store the results of the second step in C.
Assuming that the current C value is 0, if Thread1 performs the third step, Thread2 performs the first step and then returns 2. If Thread1 performs step one or step two o'clock, Thread2 executes step one. Then the result will return 1.
At first glance, there is something similar to a memory consistency error, but they cause different reasons for the error. In the case of a memory consistency error, it is possible that even if the THREAD1 performs the third step, Thread2 begins the first step, possibly with a 1 result. Because the first step of thread2 does not see the execution result of the third step of Thread1.
Summarize
When writing multithreaded program, not only attention to thread interference, but also to consider memory consistency errors.
In addition, three are provided in Java and the contract java.util.concurrent,java.util.concurrent.atomic,java.util.concurrent.locks. Their main purpose is not to upgrade existing line Cheng (Synchronization,wait,notify,interrupt,join), but to develop a series of business models using existing semantics, Developers should first think about whether their business model matches the model provided by Java when writing multithreaded program. If the match should be used preferentially the class under the Java.util.concurrent,java.util.concurrent.atomic,java.util.concurrent.locks package. These classes, written by Oracle's concurrency experts, can be very good at avoiding thread interference and memory consistency errors, as well as avoiding deadlocks, starvation locks, active locks, and other common problems, while avoiding inefficiencies caused by a large number of synchronization.