[Multi-Threading] Instruction Re-Ordering

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Cool Guy - 18 Sep 2005 15:52 GMT

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();
}
}

Reply to this Message

Cool Guy - 18 Sep 2005 16:01 GMT

> 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();
}
}

Reply to this Message

Lloyd Dupont - 19 Sep 2005 01:45 GMT

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..

>> In the following, is the volatile write *guaranteed* to happen before
>> Bar()
[quoted text clipped - 13 lines]
> }
> }

Reply to this Message

Cool Guy - 19 Sep 2005 10:59 GMT

> 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.

Reply to this Message

Cool Guy - 19 Sep 2005 12:20 GMT

I wrote:

> 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.

Reply to this Message

Lloyd Dupont - 20 Sep 2005 23:57 GMT

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.

>I wrote:
>
[quoted text clipped - 7 lines]
> IOW, I'm not entirely sure that I understand what they mean by 'memory
> accesses' here.

Reply to this Message

Cool Guy - 21 Sep 2005 04:18 GMT

> 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?

Reply to this Message

Lloyd Dupont - 21 Sep 2005 07:36 GMT

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.

>> while volatile was created to address this issue by making the code
>> always
[quoted text clipped - 3 lines]
>
> Was that the double-checked locking thing, or something else?

Reply to this Message

Cool Guy - 19 Sep 2005 19:39 GMT

I wrote:

>> In the following, is the volatile write *guaranteed* to happen before Bar()
>> is called?
[quoted text clipped - 12 lines]
> }
> }

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

Reply to this Message

[Multi-Threading] Instruction Re-Ordering

Free Magazines