[concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics
david.holmes at oracle.com
Fri Dec 5 01:55:22 UTC 2014
On 2/12/2014 6:46 AM, Martin Buchholz wrote:
> David, Paul (i.e. Reviewers) and Doug,
> I'd like to commit corrections so we make progress.
> I think the current webrev is simple progress with the exception of my
> attempt to translate volatiles into fences, which is marginal (but was
> a good learning exercise for me).
Looking at the actual API changes ...
In general phrasing like: " also known as a LoadLoad plus LoadStore
barrier ..." is misleading to me as these are not "aliases"- the
loadFence (in this case) is being specified to have the same semantics
as the loadload|storeload. It should say "corresponds to a LoadLoad plus
LoadStore barrier" - as per the "Corresponds to a C11 ...". And
referring to things like "load-acquire fence" is meaningless without
some reference to a definition - who defines a load-acquire fence? Is
there a universal definition? I would be okay with something looser eg:
* Ensures that loads before the fence will not be reordered with
* stores after the fence. Corresponds to a LoadLoad plus LoadStore
* and also to the C11 atomic_thread_fence(memory_order_acquire).
* Sometimes referred to as a "load-acquire fence".
Also I find this comment strange:
! * A pure StoreStore fence is not provided, since the addition of
! * is almost always desired, and most current hardware
! * provide a StoreStore barrier also provide a LoadStore barrier
because inside hotspot we use storeStore barriers a lot, without any
loadStore at the same point.
More information about the core-libs-dev