472,135 Members | 1,491 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,135 software developers and data experts.

Volatile & ECMA Specification

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
Jul 21 '05 #1
4 1817
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?

Jul 21 '05 #2
Done. Thanks.

Jul 21 '05 #3
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
Jul 21 '05 #4
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
Jul 21 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by Florian Proch | last post: by
6 posts views Thread by Tony Whitter | last post: by
22 posts views Thread by Assaf | last post: by
14 posts views Thread by Pierre | last post: by
4 posts views Thread by Andrew | last post: by
9 posts views Thread by Edward Diener | last post: by
28 posts views Thread by Andre | last post: by
94 posts views Thread by Samuel R. Neff | last post: by
reply views Thread by leo001 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.