Interesting processor load/store re-ordering issues

[Dilip]

I found this post pretty interesting (if a tad confusing if you cannot
recite Intel assembly language instructions in your sleep :-)):

http://www.bluebytesoftware.com/blog/PermaLink,guid,8bb27ef2-d53a-4e9f-b4e4-cc1607d06f37.aspx

[Chris Thomasson]

"Dilip" <rdi...@lycos.com> wrote in message
news:73f6a594-7e44-46e6...@34g2000hsh.googlegroups.com...

>
> I found this post pretty interesting (if a tad confusing if you cannot
> recite Intel assembly language instructions in your sleep :-)):
>
> http://www.bluebytesoftware.com/blog/PermaLink,guid,8bb27ef2-d53a-4e9f-b4e4-cc1607d06f37.aspx

I am not exactly sure why the author find the "discovery" deeply disturbing.
Its clearly documented in the referenced Intel white paper:

http://www.intel.com/products/processor/manuals/318147.pdf

AFAICT, the jist of the article is that there may be a bug in the .NET
memory model.

BTW, check this thread out Dilip:

http://groups.google.com/group/comp.programming.threads/browse_frm/thread/e07adf138f0091d

You may find it interesting as well. You can indeed get some specific
orderings with "current" x86 without using any explicit fence
instructions... Simple example:

__________________________________________________________
vars: A, B, C, ORDER - all set to 0
cpus: P1, P2, P3

P1: A = 1; B = 2; C = 3; ORDER = 1;

P2: if (ORDER == 1) {
assert(A == 1 && B == 2 && C == 3);
A = 2; B = 3; C = 4; ORDER = 2;
}

P3: if (ORDER == 2) {
assert(A == 2 && B == 3 && C == 4);
}
__________________________________________________________

The asserts will not trip. Neither will the following:

__________________________________________________________
vars: A, B, C - all set to 0
cpus: P1, P2, P3

P1: A = 1; B = 2;

P2: if (B == 2) {
assert(A == 1);
B = 3; C = 4;
}

P2: if (C == 4) {
assert(A == 1 && B == 3);
}
__________________________________________________________