"Loads are not reorderd with other loads" is a fact !! Continued: Do not count on volatile

Volatile was mentioned in the previous article. In fact, due to the problems mentioned in the previous article, volatile is getting farther and farther away from its meaning. Before talking about this problem, we need to raise the. NET Memory Model (MM) question. I don't expect a long article here to explain how the memory model works. To put it simply, it is the following sentence:

 

First, the data dependency between load and store will not be changed

2. All store operations have release semantics, and all volatile loads have acquire semantics,

Third, all load and store cannot span the memory barrier (Full fence, full memory fence)

4. Load and store can be removed only when the adjacent load and store are in the same location.

 

What is acquire and release ~ Acquire can be understood as that there are no other operations (for memory) that can be adjusted to their own execution order before it; rather, release can be understood, no other operation can be performed after it is adjusted. But please note! Acquire and release are already half of memory barriers! It should have an impact on CPU visibility. Well, let's not mention this first. Assume that the mm of. Net on x64 isPerfect implementation. Let's see what msdn explains volatile:

 

First sentence:

TheVolatileKeyword indicates that a field might be modified by multiple threads that are executing at the same time.

This sentence does not actually cover any actual content.

Second sentence:

Fields that are declaredVolatileAre not subject to compiler optimizations that assume access by a single thread.

This sentence points out a role of volatile-to prevent the compiler from optimizing yourCodeAlthough the compiler does not consider volatile to be accessed by a single thread, it is only assume, which cannot solve any problem.

Third sentence:

This ensures that the most up-to-date value is present in the field at all times.

What is this? This fully demonstrates the role of volatile we mentioned above: Volatile load has the release syntax!

Fourth sentence:

TheVolatileModifier is usually used for a field that is accessed by multiple threads without using the lock statement to serialize access.

In fact, he wants to say that if you execute store to volatile, you will get the value of most up to date in load (even in another thread. In this way, we do not need to use lock to introduce synchronization or memory fence.

 

Well, according to the above explanation, if the mm of. NET is perfect, OK, it's all right! But please refer to the previous article, no!Volatile cannot guarantee that load is acquire.! That is, Microsoft's. net Framework implementation on x86 and Intel 64 platforms is vulnerable (this has nothing to do with Intel, do not misunderstand, yes. net mm issue )! Therefore, do not count on the msdn explanation. When you write a multi-thread application, keep one eye on it.

 

If you want to fix this vulnerability, the volatile load requires half of the memory fence, but please refer to the x86 and x64 documents and you will know that a full fence is required here. That is, volatile load won't be reordered at all. Is this suitable? I don't know. I don't know where the real official explanation of Java mm is, but at least some documents currently indicate that Java's volatile is a full fence.

 

Finally, I 'd like to explain something. Most of our comrades do not have to worry about it for most of the time. Please don't be panic :-)