[cpp-threads] A draft memory model paper

[Peter Dimov]

Herb Sutter wrote:
> Peter wrote:
>> How do you expect a compiler that follows this memory model to
> translate:
> [code with interlocked variables]
>
> Same as JSR-133 cookbook for Java volatile, no?

Yes indeed. :-)

> BTW, the paper uses "interlocked" simply to avoid the V-word, since
> "volatile" is a lightning rod even though this is similar to Java and
> .NET volatile.
>
>> extern interlocked int x;
>>
>> void f()
>> {
>>     x = 1;
>
> On IA64, st.rel [x] = 1. On IA32 plain store + mfence is one way, I
> suppose?
>
>> }
>>
>> and:
>>
>> extern interlocked int y;
>> extern void h();
>>
>> void g()
>> {
>>     if( y ) h();
>
> On IA64, ld.acq [y] = 1. On IA32 plain load, I suppose?
>
>> }

But if you later call f(); g(); in sequence, st.rel can be reordered with 
ld.acq, and the MM doesn't allow that. So one of the two needs an additional 
mf. On x86, plain load is ld.acq and plain store is st.rel, but translating 
stores to plain store + mfence would indeed impose a total order.

Unfortunately it can also impose a performance hit.