[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.
David
More information about the core-libs-dev
mailing list