[concurrency-interest] LoadStore and StoreStore , are both are required before lazySet and volatile write

Andrew Haley aph at redhat.com
Tue Sep 23 13:53:08 EDT 2014


On 09/23/2014 06:38 PM, Vitaly Davidovich wrote:
>>
>> As I understand it, there is nothing in a memory model
>> to prevent stores in Thread 2 after the load_acquire from floating up
>> past the x_init.store_write_release in Thread 1.
> 
> 
> Maybe nothing in memory model, but this would violate control flow
> dependency though, wouldn't it? In order for thread 2 to execute the store,
> it has to observe x_init being set to true -- there's explicit control
> dependency there.

That's right.  However, he goes on to say

"it doesn't make sense to enforce ordering based on dependencies"
http://www.hboehm.info/c++mm/dependencies.html

I think he's saying that the problem is that it while it is easy
enough to define what "dependence" means at the hardware level it's
much harder to define in the context of a memory model for a high-level
language.

But, to be honest, I am unaware of any compiler transformation which
would make the effect he's describing appear on any hardware of which
I'm aware.

> If thread 1 wrote that with a releasing store, then its
> preceding stores are also visible at this point, so I don't see how thread
> 2's store can float above thread 1's releasing store; thread 1's releasing
> store can get reordered within its own operations (like the x.a++ example),
> causing thread 2 to perform the write at an "earlier" point in thread 1's
> program order (is that what you meant?).

I am sorry, I was careless.  AIUI, it's the load in x.a++ which moves
after the the assignment x_init.

Thread 1:

x.a = 0; x.a++;
x_init.store_write_release(true);

Thread 2:

if (x_init.load_acquire())
    x.a = 42;

Andrew.


More information about the Concurrency-interest mailing list