[Multi-Threading] Instruction Re-Ordering

  • Thread starter Thread starter Cool Guy
  • Start date Start date
C

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 said:
In the following, is the volatile write *guaranteed* to happen before Bar()
is called?
Click to expand...

<snip>

In fact, make that:

class Test
{
volatile int t;

public void Foo() {
t = 5;
Bar();
}
}
 
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..
 
Lloyd Dupont said:
I would think so...
otherwsie what would be the point of using volatile?
Click to expand...

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.
 
I said:
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.
Click to expand...

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

In fact, make that:

class Test
{
volatile int t;

public void Foo() {
t = 5;
Bar();
}
}
Click to expand...

Then again, I guess it doesn't matter anyway, since the write can't move
past the next read of /t/ anyway (I believe).
 
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.
 
Lloyd Dupont said:
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.
Click to expand...

Was that the double-checked locking thing, or something else?
 
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.
 
Back
Top