Re: When is "volatile" used instead of "lock" ?
- From: "Peter Ritchie [C#MVP]" <prsoco@xxxxxxxxxxxxxxxxx>
- Date: Mon, 9 Jul 2007 19:17:39 -0400
It only makes sense to think that I was implying that if I had actuallyAgreed, you never explicitly said that.
made an assertion of "no JIT optimizations of members between
Enter/Exit".
So, you're not asserting there can be no JIT optimizations of members
between
Enter/Exit that aren't explicitly involved in a volatile operation, and
you're agreeing that:
int memberVariable;
//....
int a;
lock (someReference) {
a = memberVariable;
}
Console.WriteLine(a);
could, by my understanding of the memory model, but reordered to:
int a;
lock (someReference) {
}
a = memberVariable;
Console.WriteLine(a);
....which is what I was trying to get at originally with "the lock statement
surrounding access to a member doesn't stop the compiler from having
optimized use of a member by caching it to a register"...yes, the compiler
*could* assume that all members within the lock statement block are likely
accessible by multiple threads (implicit volatile); but that's not its
intention and it's certainly not documented as doing that". To which, your
response was quoting 335 12.6.5's "Acquiring a lock
(System.Threading.Monitor.Enter or entering a synchronized method) shall
implicitly perform a volatile read operation, and releasing a lock
(System.Threading.Monitor.Exit or leaving a synchronized method) shall
implicitly perform a volatile write operation." In fairness, by "lock
statement surrounding access to a member" I was intending a member within
the block (i.e. lock(...){member=something;}) not the reference being
locked; so I can see how the conversation side-tracked (I don't dispute the
reference sent to Monitor.Enter/Monitor.Exit is considered volatile, but
you'd think the IL generated for "lock" would have instructions with a
volatile prefix). This made me incorrectly think you were implying all
member access between Monitor.Enter and Monitor.Exit was volatile and not
subject to JIT optimizations. But, I think we agree we were talking about
different things.
A variation in your example would be
int a;
lock(someReference) {
memberVariable = a;
}
Console.WriteLine(memberVariable);
being optimized to
int a
lock(someReference){
}
memberVariable = a;
Console.WriteLine(memberVariable);
....which shouldn't occur if memberVariable were declared with "volatile".
One thing it may be worth considering is what the authors of the spec
*intended*. If everyone agrees on that, then at least the spec can
hopefully be improved in the future to reflect it.
Well, it may be moot at this point what was intended in the spec. I doubt
the .NET JIT can change what it's currently doing should "what's intended"
be different that what was implemented. But, I do agree. I think it's
vital to have a coherent unambigious quantifiable and qualifiable spec so
"compliance" means something so developers *can* develop truly platform
independant code. (*can* because they'll always be able to incorrectly
write code to works on only one platform). Where platform is as granular as
OS/architecture combination.
.
- Follow-Ups:
- Re: When is "volatile" used instead of "lock" ?
- From: Jon Skeet [C# MVP]
- Re: When is "volatile" used instead of "lock" ?
- References:
- Re: When is "volatile" used instead of "lock" ?
- From: Peter Ritchie [C#MVP]
- Re: When is "volatile" used instead of "lock" ?
- From: Jon Skeet [C# MVP]
- Re: When is "volatile" used instead of "lock" ?
- Prev by Date: Re: String foreach problem
- Next by Date: Re: String foreach problem
- Previous by thread: Re: When is "volatile" used instead of "lock" ?
- Next by thread: Re: When is "volatile" used instead of "lock" ?
- Index(es):
Relevant Pages
|
