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 invalidat
On Wed, Dec 17, 2014 at 1:28 AM, Peter Levart wrote:
> On 12/17/2014 03:28 AM, David Holmes wrote:
>>
>> On 17/12/2014 10:06 AM, Martin Buchholz wrote:
>> Hans allows for the nonsensical, in my view, possibility that the load of
>> x.a can happen after the x_init=true store and yet somehow be subj
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
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 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
On 17/12/2014 10:06 AM, Martin Buchholz wrote:
On Thu, Dec 11, 2014 at 1:08 AM, Andrew Haley 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 g
On Thu, Dec 11, 2014 at 1:08 AM, Andrew Haley 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 went thro
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 engine
On Wed, Dec 10, 2014 at 1:02 PM, 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
On Wed, Dec 10, 2014 at 4:52 PM, David Holmes 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
> constraints but the name
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 of
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 afte
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 a
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 10/12/2014 4:15 AM, Martin Buchholz wrote:
On Mon, Dec 8, 2014 at 8:35 PM, David Holmes 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 in
On Mon, Dec 8, 2014 at 8:35 PM, David Holmes 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 can choose to
On Mon, Dec 8, 2014 at 8:51 PM, David Holmes 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
> same semantics!
I c
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 wrote:
On 6/12/2014 7:49 AM, Martin Buchholz wrote:
On Thu, Dec 4, 2014 at 5:55 PM, David Holmes
wrote
Hi Martin,
On 9/12/2014 5:17 AM, Martin Buchholz wrote:
On Mon, Dec 8, 2014 at 12:46 AM, David Holmes 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 so
Webrev updated to remove the comparison with volatile loads and stores.
On Sun, Dec 7, 2014 at 2:40 PM, David Holmes wrote:
> On 6/12/2014 7:49 AM, Martin Buchholz wrote:
>>
>> On Thu, Dec 4, 2014 at 5:55 PM, David Holmes
>> wrote:
>>
>>> In general phrasing like: " also known as a LoadLoad plus
On Mon, Dec 8, 2014 at 12:46 AM, David Holmes 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 see:
"""Returning to t
er 2014 6:42 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
&
On Sun, Dec 7, 2014 at 2:58 PM, David Holmes 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 sources don't
On 6/12/2014 7:29 AM, Martin Buchholz wrote:
On Thu, Dec 4, 2014 at 5:36 PM, David Holmes 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
On 6/12/2014 7:49 AM, Martin Buchholz wrote:
On Thu, Dec 4, 2014 at 5:55 PM, David Holmes 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 sem
On Thu, Dec 4, 2014 at 5:55 PM, David Holmes 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 sho
On Thu, Dec 4, 2014 at 5:36 PM, David Holmes 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 entire comment block
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 e
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 tran
On Dec 2, 2014, at 1:58 AM, Doug Lea 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.
> (http://cr.openjdk.java.net/~martin/webrevs/openjdk9/fence-intr
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 h
On Mon, Dec 1, 2014 at 1:51 PM, Hans Boehm 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 similar semant
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 prog
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 co
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).
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 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) C++ atomic_t
, dhol...@ieee.org
Subject: Re: [concurrency-interest] RFR: 8065804: JEP 171:
Clarifications/corrections for fence intrinsics
I basically agree with David's observation. However the C++
atomic_thread_fence(memory_order_acquire)
actually has somewhat different semantics fr
It seems to me that a (dubiuously named) loadFence is intended to have
essentially the same semantics as the (perhaps slightly less dubiously
named) C++ atomic_thread_fence(memory_order_acquire), and a storeFence
matches atomic_thread_fence(memory_order_release). The C++ standard and,
even more so
I basically agree with David's observation. However the C++
atomic_thread_fence(memory_order_acquire)
actually has somewhat different semantics from load(memory_order_acquire).
It basically ensures that prior atomic loads L are not reordered with later
(i.e. following the fence in program order)
, concurrency-interest
, Martin Buchholz
, core-libs-dev
, dhol...@ieee.org
Subject:Re: [concurrency-interest] RFR: 8065804: JEP 171:
Clarifications/corrections for fence intrinsics
I basically agree with David's observation. However the C++
a
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 wrote:
>
> Hi Martin,
>
> Thanks for looking in
David Holmes wrote:
> 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
> > >
> > > loa
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 prec
On 11/26/2014 09:56 PM, David Holmes wrote:
Martin Buchholz writes:
On Wed, Nov 26, 2014 at 5:08 PM, David Holmes
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
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 wh
Martin writes:
> On Wed, Nov 26, 2014 at 7:00 PM, 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
> r
On Wed, Nov 26, 2014 at 7:00 PM, 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 effecti
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
acqui
Martin Buchholz writes:
> On Wed, Nov 26, 2014 at 5:08 PM, David Holmes
> 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 copy-paste typ
On Tue, Nov 25, 2014 at 1:41 PM, Andrew Haley 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 may be a lit
On Tue, Nov 25, 2014 at 6:04 AM, Paul Sandoz 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 * although
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
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
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 v
53 matches
Mail list logo
