[cpp-threads] [Javamemorymodel-discussion] there's a happens-before orderhere. right?

[Alexander Terekhov]

On Mon, Dec 15, 2008 at 6:37 PM, Anthony Williams
<anthony at justsoftwaresolutions.co.uk> wrote:

[... redundant atomic_thread_fence(memory_order_acquire) ...]

>>>>>>>>  int data; //= 0
>>>>>>>>  atomic<int> x; //= 0
>>>>>>>>
>>>>>>>>  thread 1:
>>>>>>>>  ------------
>>>>>>>>  if (x.load(relaxed) > 0)
           atomic_thread_fence(memory_order_acquire), // redundant
>>>>>>>>   data = 1;
>>>>>>>>
>>>>>>>>  thread 2:
>>>>>>>>  ------------
>>>>>>>>  data = 2;
>>>>>>>>  x.store(+1, release);
>>>>>>>>
>
> [snip]
>
>>> It doesn't matter what operation thread 1 is doing on data.
>>
>> And that is actually the key reason of inefficiency in the model.
>
> Maybe, but that's how it is at the moment. Are you planning on writing a
> paper that will change that?

Not in foreseeable future. In my current setting, ROI on such work is
miserable and I'd rather continue to stick to assembly.

>
>>> Thread 2 is doing a write, so if thread 1 does *any* operation on data
>>> without ordering, you have a data race.
>>
>> But there's ordering here... think of it as having an implied (due to
>> control dependency) "atomic_thread_fence(memory_order_acquire)" (see
>> 29.6 Fences in the current draft) affecting stores but not loads.
>>
>>   int data; //= 0
>>   atomic<int> x; //= 0
>>
>>   thread 1:
>>   ------------
>>   data = 1;
>>   x.store(1, release);
>>
>>   thread 2:
>>   ------------
>>   if (x.load(relaxed)) {
>>     atomic_thread_fence(memory_order_acquire); // redundant
>>     data = 2;
>>   }
>
> Under the current C++0x memory model, the fence is not redundant, it is
> required. Control dependencies don't create happens-before relationships
> between threads; only release-acquire pairings can do that.
>
> On some current processor architectures it is not required, but that's a
> different issue.

Just out of curiosity, are you aware of any processor architecture
specs discussing the example above and insisting on having the fence?

>
> Are you planning to write a paper that proposes changing the C++0x memory
> model to automatically add such orderings?

Not in foreseeable future.

regards,
alexander.