Volatile & ECMA Specification

[Andrew]

Section 17.4.3 of the ECMA-334 C# Language Specification says

1 When a field-declaration includes a volatile modifier, the fields introduced by that declaration are volatile fields. 2 For non-volatile fields, optimization techniques that reorder instructions can lead to unexpected and unpredictable results in multi-threaded programs that access fields without synchronization such as that provided by the lock-statement (15.12). 3 These optimizations can be performed by the compiler, by the runtime system, or by hardware. 4 For volatile fields, such reordering optimizations are restricted: 5 A read of a volatile field is called a volatile read. 6 A volatile read has "acquire semantics"; that is, it is guaranteed to occur prior to any references to memory that occur after it in the instruction sequence. 7 A write of a volatile field is called a volatile write. 8 A volatile write has "release semantics"; that is, it is guaranteed to happen after any memory references prior to the write instruction in the instruction sequence.

A literal reading of part 6 is that a read of a volatile field "x" is guaranteed to occur before all other references to memory after the read in the instruction sequence, including references to fields other than "x"

Similarly, a literal reading of part 7 is that a write to a volatile field "x" is guaranteed to happen after all memory references prior to the write in the instruction sequence, including references to fields other than "x"

Are the literal readings correct, or are the guarantees only with respect to a single field at one time ("x")? For example, suppose we have two field

volatile int x
int y

and y is initialized to 0, a long time goes by, and some thread A executes this

y = 3

and then a different thread B executes this

x = x + 1
Console.WriteLine("x={0} y={1}", x, y)

Is guaranteed that the value printed for y is 3

[Eric Gunnerson [MS]]

Andrew,

Can you drop me an email at Er****@microsoft.com with this question, and
I'll try to find you an answer.

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://weblogs.asp.net/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.
"Andrew" <an*******@discussions.microsoft.com> wrote in message
news:10**********************************@microsof t.com...

Section 17.4.3 of the ECMA-334 C# Language Specification says:

1 When a field-declaration includes a volatile modifier, the fields introduced by that declaration are volatile fields. 2 For non-volatile
fields, optimization techniques that reorder instructions can lead to
unexpected and unpredictable results in multi-threaded programs that access
fields without synchronization such as that provided by the lock-statement
(15.12). 3 These optimizations can be performed by the compiler, by the
runtime system, or by hardware. 4 For volatile fields, such reordering
optimizations are restricted: 5 A read of a volatile field is called a
volatile read. 6 A volatile read has "acquire semantics"; that is, it is
guaranteed to occur prior to any references to memory that occur after it in
the instruction sequence. 7 A write of a volatile field is called a
volatile write. 8 A volatile write has "release semantics"; that is, it is
guaranteed to happen after any memory references prior to the write
instruction in the instruction sequence.
A literal reading of part 6 is that a read of a volatile field "x" is guaranteed to occur before all other references to memory after the read in
the instruction sequence, including references to fields other than "x".
Similarly, a literal reading of part 7 is that a write to a volatile field "x" is guaranteed to happen after all memory references prior to the write
in the instruction sequence, including references to fields other than "x".
Are the literal readings correct, or are the guarantees only with respect to a single field at one time ("x")? For example, suppose we have two
fields
volatile int x;
int y;

and y is initialized to 0, a long time goes by, and some thread A executes this:
y = 3;

and then a different thread B executes this:

x = x + 1;
Console.WriteLine("x={0} y={1}", x, y);

Is guaranteed that the value printed for y is 3?

[Andrew]

Done. Thanks.

[Jon Skeet [C# MVP]]

Andrew <an*******@discussions.microsoft.com> wrote:

<snip>

Are the literal readings correct, or are the guarantees only with
respect to a single field at one time ("x")? For example, suppose we
have two fields

volatile int x;
int y;

and y is initialized to 0, a long time goes by, and some thread A
executes this:

y = 3;

and then a different thread B executes this:

x = x + 1; Console.WriteLine("x={0} y={1}", x, y);

Is guaranteed that the value printed for y is 3?

Yes, I believe that's guaranteed - I believe your literal readings are
correct. I'll be interested to hear what response you get back from
Eric though - please post it!

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

[Andrew]

Here's what Chris Brumme sent me

-

From cb*****@microsoft.com Thu Feb 12 07:43:42 200

Your literal readings of part 6 & 7 are correct

In your example, assuming that thread B performs the update to x >after< the other thread assigns 3 to y, then you are guaranteed that thread B will see the value 3. Of course, the way you show it there is no explicit synchronization. So I just have to believe you when you say the other thread has already made the assignment

If you want to read about the differences between the ECMA .NET memory model and the CLR's memory model (which is much stronger and which therefore doesn't require volatile for the example you show), have a look at http://blogs.msdn.com/cbrumme/archiv.../17/51445.aspx. In the CLR, all stores have release semantics (even without volatile). Reads do not have acquire semantics unless you use volatile

Chris
http://blogs.msdn.com/cbrumm