[cpp-threads] A draft memory model paper

Herb Sutter hsutter at microsoft.com
Tue Aug 8 04:52:34 BST 2006


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?

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?

> }
> 
> into x86 assembly? 

I'm certainly no expert on x86 assembly. I know about [l|m|s]fence and
that most aren't needed in practice today because production x86 never
reorders stores (as far as I know), though it will reorder loads across
other stores.

Herb




More information about the cpp-threads mailing list