java - final 变量和 lazySet 实现都需要 LoadStore 和 StoreStore 吗？

Question

我正在阅读 Hans 的一篇文章，他认为在 lazySet 或最终变量写入之前也需要 LoadStore。

他展示了一种我无法理解的特殊竞争条件。

http://www.hboehm.info/c++mm/no_write_fences.html 查看 收件人写入对象。

x.a = 43 的线程 1 存储如何通过 StoreStore 屏障完成，这是非常违反直觉的，因为这完全违背了 StoreStore 屏障的目的。

这里有类似的论点 http://shipilev.net/blog/2014/all-fields-are-final/

在此处复制 Shiplev :

“JSR 133 Cookbook 仅需要 StoreStore，但可能还需要 LoadStore 障碍。这涵盖了当最终字段从其他经历过活泼更新的字段中初始化时的极端情况。 这种极端情况可以通过运行时优化来启用，运行时优化会找出不需要最终存储的方法，将值放入局部变量中，从而打破单独使用 StoreStore 的顺序保证“

*运行时如何确定不需要最终存储，如果负载正在传递/重新排序 StoreStore 屏障，那么存储到本地变量也正在通过 storeStore 屏障传递/重新排序，这是我不需要的部分很好理解，为什么存储到局部变量可以用 StoreStore Barrier 重新排序。运行时如何/何时可以确定存储到局部变量就足够了 *

如果有人能通过一些简单的例子更详细地解释他们都提到的竞争条件是什么，那将非常有帮助。

Answer 1

我帖子中的引述令人困惑和过时，我很久以前就修复了它；对困惑感到抱歉。欢迎您在下次发生时给我发邮件。真的，它遵循Hans Boehm's example ，这很简单:

x.a = 0; x.a++;
x_init.store_write_release(true);

and the code that uses x in thread 2 updates it, with e.g.

if (x_init.load_acquire())
    x.a = 42;

If the release store in thread 1 were restricted to only ensure completion of prior stores (writes), the load of x.a in thread 1 (part of x.a++) could effectively be reordered with the assignment x_init, and could hence see a value of 42, causing x.a to be initialized to 43.