On Tue, Nov 25, 2014 at 6:04 AM, Paul Sandoz <paul.san...@oracle.com> wrote: > Hi Martin, > > Thanks for looking into this. > > 1141 * Currently hotspot's implementation of a Java language-level > volatile > 1142 * store has the same effect as a storeFence followed by a relaxed > store, > 1143 * although that may be a little stronger than needed. > > IIUC to emulate hotpot's volatile store you will need to say that a fullFence > immediately follows the relaxed store.
Right - I've been groking that. > The bit that always confuses me about release and acquire is ordering is > restricted to one direction, as talked about in orderAccess.hpp [1]. So for a > release, accesses prior to the release cannot move below it, but accesses > succeeding the release can move above it. And that seems to apply to > Unsafe.storeFence [2] (acting like a monitor exit). Is that contrary to C++ > release fences where ordering is restricted both to prior and succeeding > accesses? [3] > > So what about the following? > > a = r1; // Cannot move below the fence > Unsafe.storeFence(); > b = r2; // Can move above the fence? I think the hotspot docs need to be more precise about when they're talking about movement of stores and when about loads. > // release. I.e., subsequent memory accesses may float above the > // release, but prior ones may not float below it. As I've said elsewhere, the above makes no sense without restricting the type of access.
