The Interlocked on the Edge of Forever

William Stacey [C# MVP] <william.stacey> wrote:
> | Joe Duffy has replied to the blog post, by the way, confirming this.
>
> Thanks. Good to see his reply. So he is saying Interlocked *would prevent
> the clr re-order issue? So doing something like:
>
> int a = x;
> int b = Interlocked.Read(ref y);
>
> to your example would fix this example in terms of clr reorder issue? As he
> said, it is easier to use volatile, but just to finish the thread. Or would
> you need Interlocked.Read on both lines?

I *think* that you only need the one, although you can't do it with an
int because there's no Interlocked.Read(ref int value). It's
unfortunate that the docs for Interlocked.Read imply that all
Interlocked is used for is atomic reads, rather than preventing
reordering.

Personally though, I'd usually use a lower-tech approach, such as
locking, even for a single value. I consider even volatile to be
somewhat high-tech!

--
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

William Stacey [C# MVP] wrote:

> | Joe Duffy has replied to the blog post, by the way, confirming this.
>
> Thanks. Good to see his reply. So he is saying Interlocked *would prevent
> the clr re-order issue? So doing something like:
>
> int a = x;
> int b = Interlocked.Read(ref y);

Interlocked.Read is for reading 64-bit values atomically on 32-bit
platforms. Thread.VolatileRead is what you want here (or preferably mark
y as volatile).

> to your example would fix this example in terms of clr reorder issue?

It's not just a CLR issue, it's a CPU issue too - as Joe indicates in
the reply to Jon's blog post, IA64 will reorder reads etc. more than
e.g. x86.

> As he
> said, it is easier to use volatile, but just to finish the thread. Or would
> you need Interlocked.Read on both lines?

Thread.VolatileRead will be a read barrier, and the normal way of
understanding "read barrier" is that it prevents later reads moving
before it, but when you're mixing read-barriers with normal reads, the
barrier-based mental model gets a little shaky. What, in that model,
stops the read of 'x' into local 'a' moving after the call (i.e. in the
other direction)? IMO both x and y should be marked volatile, or both
should be read with Thread.VolatileRead, to nail them down. I'd stay
away from "mix and match" volatile / non-volatile variables.

Even better, use a lock unless performance timing indicates that this
trickery is absolutely necessary.

-- Barry

--
http://barrkel.blogspot.com/

William Stacey [C# MVP] wrote:

> | Joe Duffy has replied to the blog post, by the way, confirming this.
>
> Thanks. Good to see his reply. So he is saying Interlocked *would prevent
> the clr re-order issue? So doing something like:
>
> int a = x;
> int b = Interlocked.Read(ref y);

Interlocked.Read is for reading 64-bit values atomically on 32-bit
platforms. Thread.VolatileRead is what you want here (or preferably mark
y as volatile).

> to your example would fix this example in terms of clr reorder issue?

It's not just a CLR issue, it's a CPU issue too - as Joe indicates in
the reply to Jon's blog post, IA64 will reorder reads etc. more than
e.g. x86.

> As he
> said, it is easier to use volatile, but just to finish the thread. Or would
> you need Interlocked.Read on both lines?

Thread.VolatileRead will be a read barrier, and the normal way of
understanding "read barrier" is that it prevents later reads moving
before it, but when you're mixing read-barriers with normal reads, the
barrier-based mental model gets a little shaky. What, in that model,
stops the read of 'x' into local 'a' moving after the call (i.e. in the
other direction)? IMO both x and y should be marked volatile, or both
should be read with Thread.VolatileRead, to nail them down. I'd stay
away from "mix and match" volatile / non-volatile variables.

Even better, use a lock unless performance timing indicates that this
trickery is absolutely necessary.

-- Barry

--
http://barrkel.blogspot.com/