[Multi-Threading] Instruction Re-Ordering

[Cool Guy]

In the following, is the volatile write *guaranteed* to happen before Bar()
is called?

class Test
{
volatile string t;

public void Foo() {
t = "test";
Bar();
}
}

 

[Cool Guy]

In the following, is the volatile write *guaranteed* to happen before Bar()
is called?

<snip>

In fact, make that:

class Test
{
volatile int t;

public void Foo() {
t = 5;
Bar();
}
}

 

[Lloyd Dupont]

I would think so...
otherwsie what would be the point of using volatile?
you could alway use Thread.MemoryBarrier() if you've got any doubt..

 

[Cool Guy]

I would think so...
otherwsie what would be the point of using volatile?

That's what I was thinking -- but then the documentation only states that a
volatile writes is guaranteed to happen after **memory accesses** prior to
the write instruction in the instruction sequence (see
<http://tinyurl.com/7gml4>), which I'm not 100% sure I understand.

 

[Cool Guy]

That's what I was thinking -- but then the documentation only states that a
volatile writes is guaranteed to happen after **memory accesses** prior to
the write instruction in the instruction sequence (see
<http://tinyurl.com/7gml4>), which I'm not 100% sure I understand.

IOW, I'm not entirely sure that I understand what they mean by 'memory
accesses' here.

 

[Cool Guy]

<snip>

In fact, make that:

class Test
{
volatile int t;

public void Foo() {
t = 5;
Bar();
}
}

Then again, I guess it doesn't matter anyway, since the write can't move
past the next read of /t/ anyway (I believe).

 

[Lloyd Dupont]

simple.
non volatile memory could be stored in register and manipulate in the
register, hence an oter thread accessing the variable might not see any
changes at all.
while volatile was created to address this issue by making the code always
access the memory (not use register to hold the memory) it's not enough as
Jon pointed out in some links.
However the x86 has a striong memory model which makes it right.

So, as a summary, if your variable is the size of a register (or less) and
volatile and your programs run on an x86, it would alway be uptodate and
have atomic updates.

 

[Cool Guy]

while volatile was created to address this issue by making the code always
access the memory (not use register to hold the memory) it's not enough as
Jon pointed out in some links.

Was that the double-checked locking thing, or something else?

 

[Lloyd Dupont]

uh... in some link I checked long ago, multi-threading seems to be his
favorite topic.

to make it short, on x86 (pentium, AMD, ..) you will never have this
problem.

but on processor such as.. uh.. other architecture the memory itself is in a
per processor cache and volatile only guarantee (IIRC) that you read/write
to this processor local cache. so the value would be shared by multiple
thread on the same processor, but not by multiple thread on multiple
processor.
not to mention there are multiple level of such cache memory.

however, don't worry, this doesn't apply to Pentium or AMD, even
multi-core/multi-processor one.


But worry that volatile write are not atomic for value bigger than a
register, in which case a lock is more appropriate.