[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