If we look at using purely store fences and purely load fences in the
initialized flag example as in this discussion, I think it's worth
distinguishing too possible scenarios:
1) We guarantee some form of dependency-based ordering, as most real
computer architectures do. This probably
On 12/17/2014 03:28 AM, David Holmes wrote:
On 17/12/2014 10:06 AM, Martin Buchholz wrote:
On Thu, Dec 11, 2014 at 1:08 AM, Andrew Haley a...@redhat.com wrote:
On 11/12/14 00:53, David Holmes wrote:
There are many good uses of storestore in the various lock-free
algorithms inside hotspot.
On 12/17/2014 10:28 AM, Peter Levart wrote:
The example would then become:
T1:
store x.a - 0
load r - x.a
store x.a - r+1
; store-store
store x_init - true
T2:
load r - x.a
; load-load
if (r)
store x.a - 42
Sorry the above has an error. I meant:
T2:
load r - x_init
; load-load
if (r)
On Thu, Dec 11, 2014 at 1:08 AM, Andrew Haley a...@redhat.com wrote:
On 11/12/14 00:53, David Holmes wrote:
There are many good uses of storestore in the various lock-free
algorithms inside hotspot.
There may be many uses, but I am extremely suspicious of how good
they are. I wonder if we
On 17/12/2014 10:06 AM, Martin Buchholz wrote:
On Thu, Dec 11, 2014 at 1:08 AM, Andrew Haley a...@redhat.com wrote:
On 11/12/14 00:53, David Holmes wrote:
There are many good uses of storestore in the various lock-free
algorithms inside hotspot.
There may be many uses, but I am extremely
On 11/12/14 00:53, David Holmes wrote:
On 11/12/2014 7:02 AM, Andrew Haley wrote:
On 12/05/2014 09:49 PM, Martin Buchholz wrote:
The actual implementations of storestore (see below) seem to
universally give you the stronger ::release barrier, and it seems
likely that hotspot engineers are
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.
On 12/05/2014 09:49 PM, Martin Buchholz wrote:
The actual implementations of storestore (see below) seem to
universally give you the stronger ::release barrier, and it seems
likely that hotspot engineers are implicitly relying on that, that
some uses of ::storestore in the hotspot sources are
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
On 11/12/2014 7:02 AM, Andrew Haley wrote:
On 12/05/2014 09:49 PM, Martin Buchholz wrote:
The actual implementations of storestore (see below) seem to
universally give you the stronger ::release barrier, and it seems
likely that hotspot engineers are implicitly relying on that, that
some uses
On Wed, Dec 10, 2014 at 4:52 PM, David Holmes david.hol...@oracle.com wrote:
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
On Wed, Dec 10, 2014 at 1:02 PM, Andrew Haley a...@redhat.com wrote:
On 12/05/2014 09:49 PM, Martin Buchholz wrote:
The actual implementations of storestore (see below) seem to
universally give you the stronger ::release barrier, and it seems
likely that hotspot engineers are implicitly
On Mon, Dec 8, 2014 at 8:51 PM, David Holmes david.hol...@oracle.com wrote:
Then please point me to the common industry definition of it because I
couldn't find anything definitive. And as you state yourself above one
definition of it - the corresponding C11 fence - does not in fact have the
On Mon, Dec 8, 2014 at 8:35 PM, David Holmes david.hol...@oracle.com wrote:
So (as you say) with TSO you don't have a total order of stores if you
read your own writes out of your own CPU's write buffer. However, my
interpretation of multiple-copy atomic is that the initial
publishing thread
On 10/12/2014 4:15 AM, Martin Buchholz wrote:
On Mon, Dec 8, 2014 at 8:35 PM, David Holmes david.hol...@oracle.com wrote:
So (as you say) with TSO you don't have a total order of stores if you
read your own writes out of your own CPU's write buffer. However, my
interpretation of multiple-copy
On Sun, Dec 7, 2014 at 2:58 PM, David Holmes david.hol...@oracle.com wrote:
I believe the comment _does_ reflect hotspot's current implementation
(entirely from exploring the sources).
I believe it's correct to say all of the platforms are
multiple-copy-atomic except PPC.
... current hotspot
PM
To: David Holmes
Cc: David Holmes; Vladimir Kozlov; core-libs-dev; concurrency-interest
Subject: Re: [concurrency-interest] RFR: 8065804: JEP 171:
Clarifications/corrections for fence intrinsics
On Sun, Dec 7, 2014 at 2:58 PM, David Holmes
david.hol...@oracle.com wrote:
I believe
On Mon, Dec 8, 2014 at 12:46 AM, David Holmes davidchol...@aapt.net.au wrote:
Martin,
The paper you cite is about ARM and Power architectures - why do you think
the lack of mention of x86/sparc implies those architectures are
multiple-copy-atomic?
Reading some more in the same paper, I
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
On 9/12/2014 5:25 AM, Martin Buchholz wrote:
Webrev updated to remove the comparison with volatile loads and stores.
Thanks. More inline ...
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
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
On 6/12/2014 7:29 AM, Martin Buchholz wrote:
On Thu, Dec 4, 2014 at 5:36 PM, David Holmes david.hol...@oracle.com wrote:
Martin,
On 2/12/2014 6:46 AM, Martin Buchholz wrote:
Is this finalized then? You can only make one commit per CR.
Right. I'd like to commit and then perhaps do another
On Thu, Dec 4, 2014 at 5:36 PM, David Holmes david.hol...@oracle.com wrote:
Martin,
On 2/12/2014 6:46 AM, Martin Buchholz wrote:
Is this finalized then? You can only make one commit per CR.
Right. I'd like to commit and then perhaps do another round of clarifications.
I still find this
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
Martin,
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.
Is this finalized then? You can only make one commit per CR.
I think the current webrev is simple progress with the exception of my
attempt to
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
On Dec 2, 2014, at 1:58 AM, Doug Lea d...@cs.oswego.edu wrote:
On 12/01/2014 03:46 PM, Martin Buchholz wrote:
David, Paul (i.e. Reviewers) and Doug,
I'd like to commit corrections so we make progress.
The current one looks OK to me.
Am Dienstag, 25. November 2014, 11:15:36 schrieb Hans Boehm:
I'm no hardware architect, but fundamentally it seems to me that
load x
acquire_fence
imposes a much more stringent constraint than
load_acquire x
Consider the case in which the load from x is an L1 hit, but a preceding
I see time to time comments in the jvm sources referencing membars and fences.
Would you say that they are used interchangeably ? Having the same meaning but
for different CPU arch.
Sent from my iPhone
On Nov 25, 2014, at 6:04 AM, Paul Sandoz paul.san...@oracle.com wrote:
Hi Martin,
concurrency-inter...@cs.oswego.edu, Martin Buchholz
marti...@google.com, core-libs-dev
core-libs-dev@openjdk.java.net, dhol...@ieee.org
Subject:Re: [concurrency-interest] RFR: 8065804: JEP 171:
Clarifications/corrections for fence intrinsics
I basically agree with David's
Hans,
(Thanks for your excellent work on C/C++ 11 and your eternal patience)
On Tue, Nov 25, 2014 at 11:15 AM, Hans Boehm bo...@acm.org wrote:
It seems to me that a (dubiuously named) loadFence is intended to have
essentially the same semantics as the (perhaps slightly less dubiously
named)
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).
Needless to say, I would clearly also like to see a simple correspondence.
But this does raise the interesting question of whether put/get and
store(..., memory_order_relaxed)/load(memory_order_relaxed) are intended to
have similar semantics. I would guess not, in that the former don't
satisfy
On 12/01/2014 03:46 PM, Martin Buchholz wrote:
David, Paul (i.e. Reviewers) and Doug,
I'd like to commit corrections so we make progress.
The current one looks OK to me.
(http://cr.openjdk.java.net/~martin/webrevs/openjdk9/fence-intrinsics/)
-Doug
I think the current webrev is simple
On Mon, Dec 1, 2014 at 1:51 PM, Hans Boehm bo...@acm.org wrote:
Needless to say, I would clearly also like to see a simple correspondence.
But this does raise the interesting question of whether put/get and
store(..., memory_order_relaxed)/load(memory_order_relaxed) are intended to
have
I think that requiring coherence for ordinary Java accesses would be a
performance problem. The pre-2005 Java memory model actually promised it,
but implementations ignored that requirement. That was one significant
motivation of the 2005 memory model overhaul.
The basic problem is that if you
On 11/26/2014 09:56 PM, David Holmes wrote:
Martin Buchholz writes:
On Wed, Nov 26, 2014 at 5:08 PM, David Holmes
david.hol...@oracle.com wrote:
Please explain why you have changed the defined semantics for
storeFence.
You have completely reversed the direction of the barrier.
Yes. I
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
On Tue, Nov 25, 2014 at 1:41 PM, Andrew Haley a...@redhat.com wrote:
On 11/24/2014 08:56 PM, Martin Buchholz wrote:
+ * Currently hotspot's implementation of a Java language-level volatile
+ * store has the same effect as a storeFence followed by a relaxed store,
+ * although that
Martin Buchholz writes:
On Wed, Nov 26, 2014 at 5:08 PM, David Holmes
david.hol...@oracle.com wrote:
Please explain why you have changed the defined semantics for
storeFence.
You have completely reversed the direction of the barrier.
Yes. I believe the current spec of storeFence was a
Can I make an observation about acquire() and release() - to me they are
meaningless when considered in isolation. Given their definitions they allow
anything to move into a region bounded by acquire() and release(), then you
can effectively move the whole program into the region and thus the
On Wed, Nov 26, 2014 at 7:00 PM, David Holmes davidchol...@aapt.net.au wrote:
Can I make an observation about acquire() and release() - to me they are
meaningless when considered in isolation. Given their definitions they allow
anything to move into a region bounded by acquire() and release(),
Martin writes:
On Wed, Nov 26, 2014 at 7:00 PM, David Holmes
davidchol...@aapt.net.au wrote:
Can I make an observation about acquire() and release() - to me they are
meaningless when considered in isolation. Given their
definitions they allow
anything to move into a region bounded by
On 11/27/2014 04:00 AM, David Holmes wrote:
Can I make an observation about acquire() and release() - to me they are
meaningless when considered in isolation. Given their definitions they allow
anything to move into a region bounded by acquire() and release(), then you
can effectively move the
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
On 11/24/2014 08:56 PM, Martin Buchholz wrote:
Hi folks,
Review carefully - I am trying to learn about fences by explaining them!
I have borrowed some wording from my reviewers!
+ * Currently hotspot's implementation of a Java language-level volatile
+ * store has the same effect as
Stephan Diestelhorst writes:
Am Dienstag, 25. November 2014, 11:15:36 schrieb Hans Boehm:
I'm no hardware architect, but fundamentally it seems to me that
load x
acquire_fence
imposes a much more stringent constraint than
load_acquire x
Consider the case in which the load
47 matches
Mail list logo
