[concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics

David Holmes david.holmes at oracle.com
Thu Dec 11 00:52:02 UTC 2014

On 11/12/2014 3:31 AM, Martin Buchholz wrote:
> Today I Leaned
> that "release fence" and "acquire fence" are technical terms defined
> in the C/C++ 11 standards.
> So my latest version reads instead:
>       * Ensures that loads and stores before the fence will not be reordered with
>       * stores after the fence; a "StoreStore plus LoadStore barrier".
>       *
>       * Corresponds to C11 atomic_thread_fence(memory_order_release)
>       * (a "release fence").

Thank you Martin - I find the updated wording much more appropriate.

For the email record, as I have written in the bug report, I think the 
"correction" of the semantics for storeFence have resulted in 
problematic naming where storeFence and loadFence have opposite 
directionality constraints but the names suggest the same directionality 
constraints. Had the original API suggested these names with the revised 
semantics I would have argued against them. This area is confusing 
enough without adding to that confusion with names that don't suggest 
the action.


More information about the core-libs-dev mailing list