Can ordered store be reordered with subsequent volatile load?

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Can ordered store be reordered with subsequent volatile load?

Vladimir Ozerov
Hi,

I am trying to wrap my head around the following problem. Consider we have a kind of lightweight locking algorithm between two threads which somewhat resembles classical Peterson's lock. One thread declares intent to acquire a lock and then checks whether state of another thread allows it.

The question is: provided very subtle "putOrdered" semantics and no data dependency between "a" and "b", do I have any guarantees that store and load will not be reordered in the code below?

int a, b;

boolean tryLock() {
    UNSAFE.putOrdered(a, 1); // Declare intent.

    // No StoreLoad here as store is not volatile.

    if (UNSAFE.getVolatile(b) == 1)) {
        // Reset intent and return false;
    }

    return true;
}

My hope is that ordering could be enforced by the fact that both store and load in this example are synchronization actions (see old comment from Doug: http://cs.oswego.edu/pipermail/concurrency-interest/2011-October/008324.html).

Vladimir.

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Can ordered store be reordered with subsequent volatile load?

Aleksey Shipilev-2
On 03/27/2016 12:32 AM, Vladimir Ozerov wrote:
> I am trying to wrap my head around the following problem. Consider we
> have a kind of lightweight locking algorithm between two threads which
> somewhat resembles classical Peterson's lock. One thread declares intent
> to acquire a lock and then checks whether state of another thread allows it.
>
> The question is: provided very subtle "putOrdered" semantics and no data
> dependency between "a" and "b", do I have any guarantees that store and
> load will not be reordered in the code below?

No, you don't have these guarantees. acquire/release-es (putOrdered is a
release in disguise) are not sequentially consistent.

In other words, you cannot freely change volatiles to acquire/releases
and hope it does not break code. Famous example: replace volatiles with
acq/rel in IRIW. I think Dekker/Peterson locks require the same
guarantees that IRIW validates.

> int a, b;
>
> boolean tryLock() {
>     UNSAFE.putOrdered(a, 1); // Declare intent.
>
>     // No StoreLoad here as store is not volatile.
>
>     if (UNSAFE.getVolatile(b) == 1)) {
>         // Reset intent and return false;
>     }
>
>     return true;
> }
Even in the naive barrier interpretation that usually gives stronger
answers, you have:

 [LoadStore|StoreStore]
 a = 1;

 r1 = b;
 [LoadLoad|LoadStore]

Oops.

> My hope is that ordering could be enforced by the fact that both
> store and load in this example are synchronization actions

Acq/rels are weird in the way they effectively induce synchronizes-with,
but have limited ties in total synchronization order. (This is at odds
with JMM spec as stated, and there is no easy way out: either you relax
SW is-suborder-of SO, and allow acq/rel in SW; or you push acq/rel into
SO and by extension into SW, effectively making them indistinguishable
from volatiles).

My personal rule of thumb is that acq/rel is okay in producer/consumer
scenarios where you can get away with only partial ordering. But in
locks, where you want to reason about multiple threads communicating in
both directions, you nominally need full SC, and the correctness of any
relaxation should be rigorously proved.

Thanks,
-Aleksey


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Can ordered store be reordered with subsequent volatile load?

Alex Otenko
In reply to this post by Vladimir Ozerov
I think the answer comes from the meaning of “Ordered” - the store is ordered with respect to what?

This store is underspecified - JMM doesn’t refer to it. Yet, given Aleksey’s answer, it seems to mean you have an hb edge between the store and the preceding operations, but no new edges with the succeeding operations.

To make matters worse, JMM requires synchronizes-with edges, for the observed order of operations to be transitively closed - that is the only way to make conclusions about the order of events observed in two different threads. This means that for putOrdered to make sense one would need an edge between a load of that value and the store. However, the current JMM only talks about synchronization operations that are always part of (total) synchronization order. If you make putOrdered part of synchronization order, it becomes no different from a volatile store. If you make putOrdered not part of synchronization order, you need to modify JMM to allow to synchronize-with operations that are not totally ordered, and specify what orders are not allowed (basically, the difficulty with specifying this in the JMM).

So, whereas Aleksey’s answer explains that volatile load of b can be reordered with putOrdered store of a, there’s still a question of whether the volatile load of b is observed in a deterministic order with the other operations preceding putOrdered store of a. In other words, does putOrdered create edges between all preceding operations and all succeeding operations, or does it only create an order between that single store and the preceding operations.


Alex


On 26 Mar 2016, at 21:32, Vladimir Ozerov <[hidden email]> wrote:

Hi,

I am trying to wrap my head around the following problem. Consider we have a kind of lightweight locking algorithm between two threads which somewhat resembles classical Peterson's lock. One thread declares intent to acquire a lock and then checks whether state of another thread allows it.

The question is: provided very subtle "putOrdered" semantics and no data dependency between "a" and "b", do I have any guarantees that store and load will not be reordered in the code below?

int a, b;

boolean tryLock() {
    UNSAFE.putOrdered(a, 1); // Declare intent.

    // No StoreLoad here as store is not volatile.

    if (UNSAFE.getVolatile(b) == 1)) {
        // Reset intent and return false;
    }

    return true;
}

My hope is that ordering could be enforced by the fact that both store and load in this example are synchronization actions (see old comment from Doug: http://cs.oswego.edu/pipermail/concurrency-interest/2011-October/008324.html).

Vladimir.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Can ordered store be reordered with subsequent volatile load?

Arno Haase
Here's my understanding of putOrdered - hope it helps.

* putOrdered is outside the JMM in the sense that its guarantees can not
be expressed in terms of hb or sw.

* But both putOrdered and the JMM can be expressed in terms of barriers
- see JSR-133 cookbook. As I understand it, in order to reason about
'putOrdered' you need to reason in terms of barriers, even for things
like volatile access that are covered in the JMM.

* Hotspot does two things for a volatile write.

Firstly, it emits a StoreStore barrier before it, ensuring that no other
write happening before the volatile write will be visible after the
volatile write.

Secondly, it emits a StoreLoad barrier after it, ensuring that no read
operation occurring after the volatile write will be executed before the
volatile write.

* putOrdered requires only the StoreStore barrier to be emitted. Since
the StoreStore barrier colloqually corresponds to 'ordering' and the
StoreLoad barrier to 'visibility' guarantees, one way to look at
putOrdered is that it ensures ordering - hence the name - but not
(immediate) visibility of written values. They are guaranteed to become
visible eventually, but not in the strict sense proscribed by the JMM
for volatile writes.

* Both StoreStore and StoreLoad barriers are superfluous on Intel
processors because they guarantee the corresponding restrictions for all
store operations anyway. But removing the StoreLoad barrier supposedly
makes for speedups on some other architectures.


- Arno


Am 28.03.2016 um 13:49 schrieb Alex Otenko:

> I think the answer comes from the meaning of “Ordered” - the store is
> ordered with respect to what?
>
> This store is underspecified - JMM doesn’t refer to it. Yet, given
> Aleksey’s answer, it seems to mean you have an hb edge between the store
> and the preceding operations, but no new edges with the succeeding
> operations.
>
> To make matters worse, JMM requires synchronizes-with edges, for the
> observed order of operations to be transitively closed - that is the
> only way to make conclusions about the order of events observed in two
> different threads. This means that for putOrdered to make sense one
> would need an edge between a load of that value and the store. However,
> the current JMM only talks about synchronization operations that are
> always part of (total) synchronization order. If you make putOrdered
> part of synchronization order, it becomes no different from a volatile
> store. If you make putOrdered not part of synchronization order, you
> need to modify JMM to allow to synchronize-with operations that are not
> totally ordered, and specify what orders are not allowed (basically, the
> difficulty with specifying this in the JMM).
>
> So, whereas Aleksey’s answer explains that volatile load of b can be
> reordered with putOrdered store of a, there’s still a question of
> whether the volatile load of b is observed in a deterministic order with
> the other operations preceding putOrdered store of a. In other words,
> does putOrdered create edges between all preceding operations and all
> succeeding operations, or does it only create an order between that
> single store and the preceding operations.
>
>
> Alex
>
>
>> On 26 Mar 2016, at 21:32, Vladimir Ozerov <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> Hi,
>>
>> I am trying to wrap my head around the following problem. Consider we
>> have a kind of lightweight locking algorithm between two threads which
>> somewhat resembles classical Peterson's lock. One thread declares
>> intent to acquire a lock and then checks whether state of another
>> thread allows it.
>>
>> The question is: provided very subtle "putOrdered" semantics and no
>> data dependency between "a" and "b", do I have any guarantees that
>> store and load will not be reordered in the code below?
>>
>> int a, b;
>>
>> boolean tryLock() {
>>     UNSAFE.putOrdered(a, 1); // Declare intent.
>>
>>     // No StoreLoad here as store is not volatile.
>>
>>     if (UNSAFE.getVolatile(b) == 1)) {
>>         // Reset intent and return false;
>>     }
>>
>>     return true;
>> }
>>
>> My hope is that ordering could be enforced by the fact that both store
>> and load in this example are synchronization actions (see old comment
>> from
>> Doug: http://cs.oswego.edu/pipermail/concurrency-interest/2011-October/008324.html).
>>
>> Vladimir.
>> _______________________________________________
>> Concurrency-interest mailing list
>> [hidden email]
>> <mailto:[hidden email]>
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Can ordered store be reordered with subsequent volatile load?

Vitaly Davidovich


On Monday, March 28, 2016, Arno Haase <[hidden email]> wrote:
Here's my understanding of putOrdered - hope it helps.

* putOrdered is outside the JMM in the sense that its guarantees can not
be expressed in terms of hb or sw.

* But both putOrdered and the JMM can be expressed in terms of barriers
- see JSR-133 cookbook. As I understand it, in order to reason about
'putOrdered' you need to reason in terms of barriers, even for things
like volatile access that are covered in the JMM.

* Hotspot does two things for a volatile write.

Firstly, it emits a StoreStore barrier before it, ensuring that no other
write happening before the volatile write will be visible after the
volatile write.

Secondly, it emits a StoreLoad barrier after it, ensuring that no read
operation occurring after the volatile write will be executed before the
volatile write.

* putOrdered requires only the StoreStore barrier to be emitted. Since
the StoreStore barrier colloqually corresponds to 'ordering' and the
StoreLoad barrier to 'visibility' guarantees, one way to look at
putOrdered is that it ensures ordering - hence the name - but not
(immediate) visibility of written values. They are guaranteed to become
visible eventually, but not in the strict sense proscribed by the JMM
for volatile writes.
Compiler can move loads before ordered store, changing ordering; it's not just about CPU. 

* Both StoreStore and StoreLoad barriers are superfluous on Intel
processors because they guarantee the corresponding restrictions for all
store operations anyway. But removing the StoreLoad barrier supposedly
makes for speedups on some other architectures.
I think you have this backwards.  StoreLoad is not superfluous on Intel, it's reorderable there (due to store buffers).  StoreStore (amongst the others) is nop but may have performance implications on weaker memory order CPUs.


- Arno


Am 28.03.2016 um 13:49 schrieb Alex Otenko:
> I think the answer comes from the meaning of “Ordered” - the store is
> ordered with respect to what?
>
> This store is underspecified - JMM doesn’t refer to it. Yet, given
> Aleksey’s answer, it seems to mean you have an hb edge between the store
> and the preceding operations, but no new edges with the succeeding
> operations.
>
> To make matters worse, JMM requires synchronizes-with edges, for the
> observed order of operations to be transitively closed - that is the
> only way to make conclusions about the order of events observed in two
> different threads. This means that for putOrdered to make sense one
> would need an edge between a load of that value and the store. However,
> the current JMM only talks about synchronization operations that are
> always part of (total) synchronization order. If you make putOrdered
> part of synchronization order, it becomes no different from a volatile
> store. If you make putOrdered not part of synchronization order, you
> need to modify JMM to allow to synchronize-with operations that are not
> totally ordered, and specify what orders are not allowed (basically, the
> difficulty with specifying this in the JMM).
>
> So, whereas Aleksey’s answer explains that volatile load of b can be
> reordered with putOrdered store of a, there’s still a question of
> whether the volatile load of b is observed in a deterministic order with
> the other operations preceding putOrdered store of a. In other words,
> does putOrdered create edges between all preceding operations and all
> succeeding operations, or does it only create an order between that
> single store and the preceding operations.
>
>
> Alex
>
>
>> On 26 Mar 2016, at 21:32, Vladimir Ozerov <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;ppozerov@gmail.com&#39;)">ppozerov@...
>> <mailto:<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;ppozerov@gmail.com&#39;)">ppozerov@...>> wrote:
>>
>> Hi,
>>
>> I am trying to wrap my head around the following problem. Consider we
>> have a kind of lightweight locking algorithm between two threads which
>> somewhat resembles classical Peterson's lock. One thread declares
>> intent to acquire a lock and then checks whether state of another
>> thread allows it.
>>
>> The question is: provided very subtle "putOrdered" semantics and no
>> data dependency between "a" and "b", do I have any guarantees that
>> store and load will not be reordered in the code below?
>>
>> int a, b;
>>
>> boolean tryLock() {
>>     UNSAFE.putOrdered(a, 1); // Declare intent.
>>
>>     // No StoreLoad here as store is not volatile.
>>
>>     if (UNSAFE.getVolatile(b) == 1)) {
>>         // Reset intent and return false;
>>     }
>>
>>     return true;
>> }
>>
>> My hope is that ordering could be enforced by the fact that both store
>> and load in this example are synchronization actions (see old comment
>> from
>> Doug: http://cs.oswego.edu/pipermail/concurrency-interest/2011-October/008324.html).
>>
>> Vladimir.
>> _______________________________________________
>> Concurrency-interest mailing list
>> <a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;Concurrency-interest@cs.oswego.edu&#39;)">Concurrency-interest@...
>> <mailto:<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;Concurrency-interest@cs.oswego.edu&#39;)">Concurrency-interest@...>
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> <a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;Concurrency-interest@cs.oswego.edu&#39;)">Concurrency-interest@...
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
_______________________________________________
Concurrency-interest mailing list
<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;Concurrency-interest@cs.oswego.edu&#39;)">Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


--
Sent from my phone

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Can ordered store be reordered with subsequent volatile load?

Alex Otenko
In reply to this post by Arno Haase
There are different kinds of barriers, too, (some providing local ordering, some being in a total global order) so you cannot easily reason about the barriers.

StoreLoad is not superfluous on Intel. Loads are allowed to go ahead of Stores, if the store is to a different location - just like in this case.

I don’t think it is easy to reason about “immediacy” of visibility when there is some distance between the observers. In a distributed system it is more productive to talk about agreement on the order of certain events between the observers. What people usually mean by “immediate” visibility can be described in terms of that agreement on the order of events. The fewer things are ordered, the further it is from a total order of all events, the more relaxed the model is, and the better it scales.

Alex

On 29 Mar 2016, at 01:50, Arno Haase <[hidden email]> wrote:

Here's my understanding of putOrdered - hope it helps.

* putOrdered is outside the JMM in the sense that its guarantees can not
be expressed in terms of hb or sw.

* But both putOrdered and the JMM can be expressed in terms of barriers
- see JSR-133 cookbook. As I understand it, in order to reason about
'putOrdered' you need to reason in terms of barriers, even for things
like volatile access that are covered in the JMM.

* Hotspot does two things for a volatile write.

Firstly, it emits a StoreStore barrier before it, ensuring that no other
write happening before the volatile write will be visible after the
volatile write.

Secondly, it emits a StoreLoad barrier after it, ensuring that no read
operation occurring after the volatile write will be executed before the
volatile write.

* putOrdered requires only the StoreStore barrier to be emitted. Since
the StoreStore barrier colloqually corresponds to 'ordering' and the
StoreLoad barrier to 'visibility' guarantees, one way to look at
putOrdered is that it ensures ordering - hence the name - but not
(immediate) visibility of written values. They are guaranteed to become
visible eventually, but not in the strict sense proscribed by the JMM
for volatile writes.

* Both StoreStore and StoreLoad barriers are superfluous on Intel
processors because they guarantee the corresponding restrictions for all
store operations anyway. But removing the StoreLoad barrier supposedly
makes for speedups on some other architectures.


- Arno


Am 28.03.2016 um 13:49 schrieb Alex Otenko:
I think the answer comes from the meaning of “Ordered” - the store is
ordered with respect to what?

This store is underspecified - JMM doesn’t refer to it. Yet, given
Aleksey’s answer, it seems to mean you have an hb edge between the store
and the preceding operations, but no new edges with the succeeding
operations.

To make matters worse, JMM requires synchronizes-with edges, for the
observed order of operations to be transitively closed - that is the
only way to make conclusions about the order of events observed in two
different threads. This means that for putOrdered to make sense one
would need an edge between a load of that value and the store. However,
the current JMM only talks about synchronization operations that are
always part of (total) synchronization order. If you make putOrdered
part of synchronization order, it becomes no different from a volatile
store. If you make putOrdered not part of synchronization order, you
need to modify JMM to allow to synchronize-with operations that are not
totally ordered, and specify what orders are not allowed (basically, the
difficulty with specifying this in the JMM).

So, whereas Aleksey’s answer explains that volatile load of b can be
reordered with putOrdered store of a, there’s still a question of
whether the volatile load of b is observed in a deterministic order with
the other operations preceding putOrdered store of a. In other words,
does putOrdered create edges between all preceding operations and all
succeeding operations, or does it only create an order between that
single store and the preceding operations.


Alex


On 26 Mar 2016, at 21:32, Vladimir Ozerov <[hidden email]
<[hidden email]>> wrote:

Hi,

I am trying to wrap my head around the following problem. Consider we
have a kind of lightweight locking algorithm between two threads which
somewhat resembles classical Peterson's lock. One thread declares
intent to acquire a lock and then checks whether state of another
thread allows it.

The question is: provided very subtle "putOrdered" semantics and no
data dependency between "a" and "b", do I have any guarantees that
store and load will not be reordered in the code below?

int a, b;

boolean tryLock() {
   UNSAFE.putOrdered(a, 1); // Declare intent.

   // No StoreLoad here as store is not volatile.

   if (UNSAFE.getVolatile(b) == 1)) {
       // Reset intent and return false;
   }

   return true;
}

My hope is that ordering could be enforced by the fact that both store
and load in this example are synchronization actions (see old comment
from
Doug: http://cs.oswego.edu/pipermail/concurrency-interest/2011-October/008324.html).

Vladimir.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
<[hidden email]>
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Can ordered store be reordered with subsequent volatile load?

Andrew Haley
In reply to this post by Arno Haase
On 29/03/16 01:50, Arno Haase wrote:
> * Hotspot does two things for a volatile write.
>
> Firstly, it emits a StoreStore barrier before it, ensuring that no other
> write happening before the volatile write will be visible after the
> volatile write.
>
> Secondly, it emits a StoreLoad barrier after it, ensuring that no read
> operation occurring after the volatile write will be executed before the
> volatile write.

It depends on the architecture.  AArch64 has an instruction (stlr)
which does everything we need for a volatile write.  We certainly
don't need a StoreLoad barrier.

Andrew.

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Can ordered store be reordered with subsequent volatile load?

Andrew Haley
In reply to this post by Arno Haase
On 29/03/16 01:50, Arno Haase wrote:
> * putOrdered requires only the StoreStore barrier to be emitted. Since
> the StoreStore barrier colloqually corresponds to 'ordering' and the
> StoreLoad barrier to 'visibility' guarantees, one way to look at
> putOrdered is that it ensures ordering - hence the name - but not
> (immediate) visibility of written values. They are guaranteed to become
> visible eventually, but not in the strict sense proscribed by the JMM
> for volatile writes.

If putOrdered really is a release store (I hate that name!) then
it's StoreStore|LoadStore.  StoreStore, as Hans Boehm has told us
many times, isn't much use on its own.

Andrew.

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Can ordered store be reordered with subsequent volatile load?

Vladimir Ozerov
In reply to this post by Aleksey Shipilev-2
Aleksey, 

> My personal rule of thumb is that acq/rel is okay in producer/consumer
scenarios where you can get away with only partial ordering. But in
locks, where you want to reason about multiple threads communicating in
both directions, you nominally need full SC, and the correctness of any
> relaxation should be rigorously proved.


True. Though, it looks like relaxed store could still be a viable option for unlock routine in some very specific cases.
Thanks for explanation.

Vladimir.

2016-03-27 13:42 GMT+03:00 Aleksey Shipilev <[hidden email]>:
On 03/27/2016 12:32 AM, Vladimir Ozerov wrote:
> I am trying to wrap my head around the following problem. Consider we
> have a kind of lightweight locking algorithm between two threads which
> somewhat resembles classical Peterson's lock. One thread declares intent
> to acquire a lock and then checks whether state of another thread allows it.
>
> The question is: provided very subtle "putOrdered" semantics and no data
> dependency between "a" and "b", do I have any guarantees that store and
> load will not be reordered in the code below?

No, you don't have these guarantees. acquire/release-es (putOrdered is a
release in disguise) are not sequentially consistent.

In other words, you cannot freely change volatiles to acquire/releases
and hope it does not break code. Famous example: replace volatiles with
acq/rel in IRIW. I think Dekker/Peterson locks require the same
guarantees that IRIW validates.

> int a, b;
>
> boolean tryLock() {
>     UNSAFE.putOrdered(a, 1); // Declare intent.
>
>     // No StoreLoad here as store is not volatile.
>
>     if (UNSAFE.getVolatile(b) == 1)) {
>         // Reset intent and return false;
>     }
>
>     return true;
> }

Even in the naive barrier interpretation that usually gives stronger
answers, you have:

 [LoadStore|StoreStore]
 a = 1;

 r1 = b;
 [LoadLoad|LoadStore]

Oops.

> My hope is that ordering could be enforced by the fact that both
> store and load in this example are synchronization actions

Acq/rels are weird in the way they effectively induce synchronizes-with,
but have limited ties in total synchronization order. (This is at odds
with JMM spec as stated, and there is no easy way out: either you relax
SW is-suborder-of SO, and allow acq/rel in SW; or you push acq/rel into
SO and by extension into SW, effectively making them indistinguishable
from volatiles).

My personal rule of thumb is that acq/rel is okay in producer/consumer
scenarios where you can get away with only partial ordering. But in
locks, where you want to reason about multiple threads communicating in
both directions, you nominally need full SC, and the correctness of any
relaxation should be rigorously proved.

Thanks,
-Aleksey



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Can ordered store be reordered with subsequent volatile load?

Martin Buchholz-3
In reply to this post by Andrew Haley
Recent versions of putOrdered spec documents the "memory_order_release".

    /**
     * Version of {@link #putObjectVolatile(Object, long, Object)}
     * that does not guarantee immediate visibility of the store to
     * other threads. This method is generally only useful if the
     * underlying field is a Java volatile (or if an array cell, one
     * that is otherwise only accessed using volatile accesses).
     *
     * Corresponds to C11 atomic_store_explicit(..., memory_order_release).
     */
    @ForceInline
    public void putOrderedObject(Object o, long offset, Object x) {

On Tue, Mar 29, 2016 at 2:48 AM, Andrew Haley <[hidden email]> wrote:

> On 29/03/16 01:50, Arno Haase wrote:
>> * putOrdered requires only the StoreStore barrier to be emitted. Since
>> the StoreStore barrier colloqually corresponds to 'ordering' and the
>> StoreLoad barrier to 'visibility' guarantees, one way to look at
>> putOrdered is that it ensures ordering - hence the name - but not
>> (immediate) visibility of written values. They are guaranteed to become
>> visible eventually, but not in the strict sense proscribed by the JMM
>> for volatile writes.
>
> If putOrdered really is a release store (I hate that name!) then
> it's StoreStore|LoadStore.  StoreStore, as Hans Boehm has told us
> many times, isn't much use on its own.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest