Java和C#中的volatile语义背后的原因是什么? [英] what is the reasoning behind volatile semantics in Java and C#
问题描述
C#和Java都定义了
* volatile读取具有获取语义
* volatile写入具有发布语义
我的问题是:
- 这是定义volatile的唯一正确方法。
- 如果没有,如果语义被颠倒,那么事情就会大不相同,那就是
- volatile读取具有释放语义
- volatile写入具有获取语义
volatile背后的原因
语义植根于
Both C# and Java define that
* volatile reads have acquire semantics
* volatile writes have release semantics
My questions are:
- Is this the only correct way to define volatile.
- If not, will things be awfully different if the semantics were reversed, that is
- volatile reads have release semantics
- volatile writes have acquire semantics
The reasoning behind the volatile
semantic is rooted in the Java Memory Model, which is specified in terms of actions:
- reads and writes to variables
- locks and unlocks of monitors
- starting and joining with threads
The Java Memory Model defines a partial ordering called happens-before for the actions which can occur in a Java program. Normally there is no guarantee, that threads can see the results of each other actions.
Let's say you have two actions A and B. In order to guarantee, that a thread executing action B can see the results of action A, there must be a happens-before relationship between A and B. If not, the JVM is free to reorder them as it likes.
A program which is not correctly synchronized might have data races. A data race occurs, when a variable is read by > 1 threads and written by >= 1 thread(s), but the read and write actions are not ordered through the happens-before ordering.
Hence, a correctly synchronized program has no data races, and all actions within the program happen in a fixed order.
So actions are generally only partially ordered, but there is also a total order between:
- lock acquisition and release
- reads and writes to volatile variables
These actions are totally ordered.
This makes it sensible to describe happens-before in terms of "subsequent" lock acquisitions and reads of volatile variables.
Regarding your questions:
- With the happen-before relationship you have an alternative definition of
volatile
- Reversing the order would not make sense to the definition above, especially since there is a total order involved.
This illustrates the happens-before relation when two threads synchronize using a common lock. All the actions within thread A are ordered by the program order rule, as are the actions within thread B. Because A releases lock M and B subsequently acquires M, all the actions in A before releasing the lock are therefore ordered before the actions in B after acquiring the lock. When two threads synchronize on different locks, we can't say anything about the ordering of actions between themthere is no happens-before relation between the actions in the two threads.
Source: Java Concurrency in Practice
这篇关于Java和C#中的volatile语义背后的原因是什么?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!