Webrev updated to remove the comparison with volatile loads and stores. On Sun, Dec 7, 2014 at 2:40 PM, David Holmes <david.hol...@oracle.com> wrote: > On 6/12/2014 7:49 AM, Martin Buchholz wrote: >> >> On Thu, Dec 4, 2014 at 5:55 PM, David Holmes <david.hol...@oracle.com> >> wrote: >> >>> 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" >> >> >> + * Ensures that loads before the fence will not be reordered with >> loads and >> + * stores after the fence; also known as a LoadLoad plus LoadStore >> barrier, >> >> I don't understand this. I believe they _are_ aliases. The first >> clause perfectly describes a "LoadLoad plus LoadStore barrier". > > > I find the language use inappropriate - you are defining the first to be the > second.
Am I missing something? Is there something else that "LoadLoad plus LoadStore barrier" (as used in hotspot sources and elsewhere) could possibly mean? >> - 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: >> >> >> Well, I'm defining "load-acquire fence" here in the javadoc - I'm >> claiming that loadFence is also known via other terminology, including >> "load-acquire fence". Although it's true that "load-acquire fence" is >> also used to refer to the corresponding C11 fence, which has subtly >> different semantics. > > > When you say "also known as XXX" it means that XXX is already defined > elsewhere. Unless there is a generally accepted definition of XXX then this > doesn't add much value. Everything about this topic is confusing, but I continue to think that "load-acquire fence" is a common industry term. One of the reasons I want to include them in the javadoc is precisely because these different terms are generally used synonymously.
