Re: When is "volatile" used instead of "lock" ?

Tech-Archive recommends: Fix windows errors by optimizing your registry

Peter Ritchie [C#MVP] <prsoco@xxxxxxxxxxxxxxxxx> wrote:

<snip>

Besides, I think we've sufficiently broken
Microsoft's online newsgroup reader with regard to this thread.

Agreed. I can address any of the points in your most recent post if you
really wish me to, but I suspect we're not going to convince each
other. However, we might at least be able to agree what we
agree/disagree on, which could serve as a useful summary of the thread
for anyone looking at it in the future. Here's what I believe - please
correct as appropriate :) (It's at a pretty high level to try to steer
clear of controversy.)


Things we agree on:

1) ECMA 335 is a weaker memory model than the .NET 2.0 model
2) ECMA 335 should be clearer
3) Variables declared as volatile have useful semantics, i.e. a change
made in one thread will be immediately visible in all other threads
4) If you use the locking protocol (as described by Vance) you don't
need to make variables volatile when running the .NET 2.0 CLR


Beliefs I hold:
1) Point 4 is also valid for the ECMA spec, i.e. ECMA 335 guarantees
that the locking protocol "works"
2) The ECMA spec should be deemed to govern overall visible system
behaviour, rather than only specifying what the JIT can do vs what the
CPU can do, unless it explicitly states that


Beliefs I believe you hold:
1) The locking protocol isn't guaranteed to work for all ECMA 335
compliant CLRs
2) There are places in the ECMA spec are implicitly only specifying
behaviour of the CPU or behaviour of the JIT compiler, rather than
overall visible system behaviour

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