VarHandle get / setOpaque

Question

我继续战斗，以了解VarHandle::setOpaque和VarHandle::getOpaque被真正做的事情。到目前为止，这并不容易-我认为我得到了一些东西（但不会在问题本身中介绍它们，不要糊涂了它们），但总的来说，这对我来说最多是误导。

文档：

返回按程序顺序访问的变量的值...

据我了解，如果我有：

int xx = x; // read x
int yy = y; // read y

这些读取可以重新排序。另一方面，如果我有：

// simplified code, does not compile, but reads happen on the same "this" for example
int xx = VarHandle_X.getOpaque(x); 
int yy = VarHandle_Y.getOpaque(y);

这次不能重新订购吗？这就是“程序顺序”的意思吗？我们是否在谈论在这里插入障碍物以禁止这种重新排序？如果是这样，由于这是两个负载，是否会达到相同的效果？通过：

 int xx = x;
 VarHandle.loadLoadFence()
 int yy = y;

但这变得更加棘手：

...但不能保证相对于其他线程的内存排序效果。

我无法拿出一个例子来假装我理解这部分。

在我看来，该文档针对的是确切知道他们在做什么的人（我绝对不是一个人）...那么有人可以在这里阐明一些信息吗？

Answer 1

Well in my understanding if I have:

int xx = x; // read x
int yy = y; // read y

These reads can be re-ordered.

These reads may not only happen to be reordered, they may not happen at all. The thread may use an old, previously read value for x and/or y or values it did previously write to these variables whereas, in fact, the write may not have been performed yet, so the “reading thread” may use values, no other thread may know of and are not in the heap memory at that time (and probably never will).

On the other had if I have:

// simplified code, does not compile, but reads happen on the same "this" for example
int xx = VarHandle_X.getOpaque(x); 
int yy = VarHandle_Y.getOpaque(y);

This time re-orderings are not possible? And this is what it means "program order"?

Simply said, the main feature of opaque reads and writes, is, that they will actually happen. This implies that they can not be reordered in respect to other memory access of at least the same strength, but that has no impact for ordinary reads and writes.

The term program order is defined by the JLS:

… the program order of t is a total order that reflects the order in which these actions would be performed according to the intra-thread semantics of t.

That’s the evaluation order specified for expressions and statements. The order in which we perceive the effects, as long as only a single thread is involved.

Are we talking about insertions of barriers here for this re-ordering to be prohibited?

No, there is no barrier involved, which might be the intention behind the phrase “…but with no assurance of memory ordering effects with respect to other threads”.

Perhaps, we could say that opaque access works a bit like volatile was before Java 5, enforcing read access to see the most recent heap memory value (which makes only sense if the writing end also uses opaque or an even stronger mode), but with no effect on other reads or writes.

So what can you do with it?

A typical use case would be a cancellation or interruption flag that is not supposed to establish a happens-before relationship. Often, the stopped background task has no interest in perceiving actions made by the stopping task prior to signalling, but will just end its own activity. So writing and reading the flag with opaque mode would be sufficient to ensure that the signal is eventually noticed (unlike the normal access mode), but without any additional negative impact on the performance.

Likewise, a background task could write progress updates, like a percentage number, which the reporting (UI) thread is supposed to notice timely, while no happens-before relationship is required before the publication of the final result.

It’s also useful if you just want atomic access for long and double, without any other impact.

Since truly immutable objects using final fields are immune to data races, you can use opaque modes for timely publishing immutable objects, without the broader effect of release/acquire mode publishing.

一种特殊情况是定期检查期望值更新的状态，并在可用时以更强的模式查询该值（或显式执行匹配的fence指令）。原则上，无论如何都只能在写入与后续读取之间建立事前发生的关系，但是由于优化程序通常没有能力识别这种线程间用例，因此性能关键代码可以使用不透明访问来进行优化这种情况。