471,334 Members | 1,347 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

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

Volatile fields

Hi all,

let be focus on sigle processor machine 32 bits.
1. with multi-threaded on single processor machine 32bit do i
have to sync access to atomic get/set properties of type less then 32 bits ?
2. for those properties is it enough to use volatile on single processor
machine ?
3 does volatile solve the problem for multi-processor machine ?
4. does the problems optimizations/reordering/caching
makes problems with multi-threading on single processor machine 32bit ?

Thanks all.
Dec 12 '05 #1
13 1711
"yaron" <ya***@discussions.microsoft.com> wrote in message
news:AB**********************************@microsof t.com...
Hi all,

let be focus on sigle processor machine 32 bits.
1. with multi-threaded on single processor machine 32bit do i
have to sync access to atomic get/set properties of type less then 32 bits
?
you should sync access to data of any type.
2. for those properties is it enough to use volatile on single processor
machine ?
No. from msdn: "The volatile keyword is a type qualifier used to declare
that an object can be modified in the program by something such as the
operating system, the hardware, or a concurrently executing thread."
Volatile keyword does not make your variable syncronized.
3 does volatile solve the problem for multi-processor machine ?
No.
4. does the problems optimizations/reordering/caching
makes problems with multi-threading on single processor machine 32bit ?


Volatile object are not used in optimization, because they can be modified
at any time.

--
Vladimir
Dec 12 '05 #2
Scherbina Vladimir wrote:
"yaron" <ya***@discussions.microsoft.com> wrote in message
news:AB**********************************@microsof t.com...
Hi all,

let be focus on sigle processor machine 32 bits.
1. with multi-threaded on single processor machine 32bit do i
have to sync access to atomic get/set properties of type less then 32 bits
?


you should sync access to data of any type.


Yes, although volatile serves that purpose.
2. for those properties is it enough to use volatile on single processor
machine ?


No. from msdn: "The volatile keyword is a type qualifier used to declare
that an object can be modified in the program by something such as the
operating system, the hardware, or a concurrently executing thread."
Volatile keyword does not make your variable syncronized.


Unless I'm mistaken, you're quoting from the C/C++ documentation, which
doesn't apply to C#.
3 does volatile solve the problem for multi-processor machine ?


No.


It does, actually - for types for which volatile is appropriate. (See
link below.)
4. does the problems optimizations/reordering/caching
makes problems with multi-threading on single processor machine 32bit ?


Volatile object are not used in optimization, because they can be modified
at any time.


It means a lot more than that. See
http://www.pobox.com/~skeet/csharp/t...latility.shtml

Jon

Dec 12 '05 #3
Hi Jon,

You answer on my questions on this topic before, but i didn't understand
what are the conclusions on my simple example.
what can be done on single processor 32 bit and what can't be done on
multi-processor machine ? (i means do i must use sync on those 32 bits
properties or volatile are enough ?)

Thanks a lot.

"Jon Skeet [C# MVP]" wrote:
Scherbina Vladimir wrote:
"yaron" <ya***@discussions.microsoft.com> wrote in message
news:AB**********************************@microsof t.com...
Hi all,

let be focus on sigle processor machine 32 bits.
1. with multi-threaded on single processor machine 32bit do i
have to sync access to atomic get/set properties of type less then 32 bits
?


you should sync access to data of any type.


Yes, although volatile serves that purpose.
2. for those properties is it enough to use volatile on single processor
machine ?


No. from msdn: "The volatile keyword is a type qualifier used to declare
that an object can be modified in the program by something such as the
operating system, the hardware, or a concurrently executing thread."
Volatile keyword does not make your variable syncronized.


Unless I'm mistaken, you're quoting from the C/C++ documentation, which
doesn't apply to C#.
3 does volatile solve the problem for multi-processor machine ?


No.


It does, actually - for types for which volatile is appropriate. (See
link below.)
4. does the problems optimizations/reordering/caching
makes problems with multi-threading on single processor machine 32bit ?


Volatile object are not used in optimization, because they can be modified
at any time.


It means a lot more than that. See
http://www.pobox.com/~skeet/csharp/t...latility.shtml

Jon

Dec 12 '05 #4
yaron wrote:
You answer on my questions on this topic before, but i didn't understand
what are the conclusions on my simple example.
what can be done on single processor 32 bit and what can't be done on
multi-processor machine ? (i means do i must use sync on those 32 bits
properties or volatile are enough ?)


The CLI spec makes no mention (that I remember anyway, in the relevant
section) of single or multi-processor boxes. Something is either
guaranteed to work according to the spec or it isn't.

If you use volatile variables, the "read" values are guaranteed to be
the most recent "written" values, and you'll never see "half" a write
(i.e. it's atomic as well as volatile).

Note that making a reference type variable volatile only makes that
variable's value - i.e. the reference - volatile. Changing the value of
the data in the object the reference refers to doesn't come into the
volatility.

Personally, I tend to use locks for all shared data. I would only use
volatile for predefined value types of 32 bits or less - int, bool,
char etc. It should work fine for those, however.

Jon

Dec 12 '05 #5
Hi Jon,
2. for those properties is it enough to use volatile on single processor machine ?
No. from msdn: "The volatile keyword is a type qualifier used to declare
that an object can be modified in the program by something such as the
operating system, the hardware, or a concurrently executing thread."
Volatile keyword does not make your variable syncronized.


Unless I'm mistaken, you're quoting from the C/C++ documentation, which
doesn't apply to C#.


I just checked the C# Programmer's Reference, and it quotes what Vladimir
posted. The link is:
http://winfx.msdn.microsoft.com/libr...ac036af009.asp
msdn : "The volatile keyword indicates that a field can be modified in the
program by something such as the operating system, the hardware, or a
concurrently executing thread."

and also: "The volatile modifier is usually used for a field that is
accessed by multiple threads without using the lock statement to serialize
access. Using the volatile modifier ensures that one thread retrieves the
most up-to-date value written by another thread.", which is what u also have
mentioned.

-Ab.
http://joehacker.blogspot.com

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com... Scherbina Vladimir wrote:
"yaron" <ya***@discussions.microsoft.com> wrote in message
news:AB**********************************@microsof t.com...
Hi all,

let be focus on sigle processor machine 32 bits.
1. with multi-threaded on single processor machine 32bit do i
have to sync access to atomic get/set properties of type less then 32 bits ?


you should sync access to data of any type.


Yes, although volatile serves that purpose.
2. for those properties is it enough to use volatile on single processor machine ?


No. from msdn: "The volatile keyword is a type qualifier used to declare
that an object can be modified in the program by something such as the
operating system, the hardware, or a concurrently executing thread."
Volatile keyword does not make your variable syncronized.


Unless I'm mistaken, you're quoting from the C/C++ documentation, which
doesn't apply to C#.
3 does volatile solve the problem for multi-processor machine ?


No.


It does, actually - for types for which volatile is appropriate. (See
link below.)
4. does the problems optimizations/reordering/caching
makes problems with multi-threading on single processor machine 32bit
?
Volatile object are not used in optimization, because they can be modified at any time.


It means a lot more than that. See
http://www.pobox.com/~skeet/csharp/t...latility.shtml

Jon

Dec 12 '05 #6
Abubakar wrote:
No. from msdn: "The volatile keyword is a type qualifier used to declare
that an object can be modified in the program by something such as the
operating system, the hardware, or a concurrently executing thread."
Volatile keyword does not make your variable syncronized.
Unless I'm mistaken, you're quoting from the C/C++ documentation, which
doesn't apply to C#.


I just checked the C# Programmer's Reference, and it quotes what Vladimir
posted.


Well, nearly - not exactly. The phrase "type qualifier" never appears,
for instance.
The link is:
<snip>
msdn : "The volatile keyword indicates that a field can be modified in the
program by something such as the operating system, the hardware, or a
concurrently executing thread."
That's unfortunate, in my view. It makes volatile fields sound too much
like C/C++ volatile fields, whereas I believe the behaviour is
significantly different.
and also: "The volatile modifier is usually used for a field that is
accessed by multiple threads without using the lock statement to serialize
access. Using the volatile modifier ensures that one thread retrieves the
most up-to-date value written by another thread.", which is what u also have
mentioned.


Indeed. There's more to it than that though, as it affects how *other*
fields are accessed.
See the previously specified link for more details.

Jon

Dec 12 '05 #7
> Well, nearly - not exactly. The phrase "type qualifier" never appears,
for instance.
yes I also noticed it. Thanks for the reply, I'll look into it.

Ab.
http://joehacker.blogspot.com

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com... Abubakar wrote:
> No. from msdn: "The volatile keyword is a type qualifier used to declare > that an object can be modified in the program by something such as the > operating system, the hardware, or a concurrently executing thread."
> Volatile keyword does not make your variable syncronized.

Unless I'm mistaken, you're quoting from the C/C++ documentation, which doesn't apply to C#.


I just checked the C# Programmer's Reference, and it quotes what Vladimir posted.


Well, nearly - not exactly. The phrase "type qualifier" never appears,
for instance.
The link is:


<snip>
msdn : "The volatile keyword indicates that a field can be modified in the program by something such as the operating system, the hardware, or a
concurrently executing thread."


That's unfortunate, in my view. It makes volatile fields sound too much
like C/C++ volatile fields, whereas I believe the behaviour is
significantly different.
and also: "The volatile modifier is usually used for a field that is
accessed by multiple threads without using the lock statement to serialize access. Using the volatile modifier ensures that one thread retrieves the most up-to-date value written by another thread.", which is what u also have mentioned.


Indeed. There's more to it than that though, as it affects how *other*
fields are accessed.
See the previously specified link for more details.

Jon

Dec 12 '05 #8
Thanks Jon and Abubakar.
"Abubakar" wrote:
Well, nearly - not exactly. The phrase "type qualifier" never appears,
for instance.


yes I also noticed it. Thanks for the reply, I'll look into it.

Ab.
http://joehacker.blogspot.com

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
Abubakar wrote:
> > No. from msdn: "The volatile keyword is a type qualifier used to declare > > that an object can be modified in the program by something such as the > > operating system, the hardware, or a concurrently executing thread."
> > Volatile keyword does not make your variable syncronized.
>
> Unless I'm mistaken, you're quoting from the C/C++ documentation, which > doesn't apply to C#.

I just checked the C# Programmer's Reference, and it quotes what Vladimir posted.


Well, nearly - not exactly. The phrase "type qualifier" never appears,
for instance.
The link is:


<snip>
msdn : "The volatile keyword indicates that a field can be modified in the program by something such as the operating system, the hardware, or a
concurrently executing thread."


That's unfortunate, in my view. It makes volatile fields sound too much
like C/C++ volatile fields, whereas I believe the behaviour is
significantly different.
and also: "The volatile modifier is usually used for a field that is
accessed by multiple threads without using the lock statement to serialize access. Using the volatile modifier ensures that one thread retrieves the most up-to-date value written by another thread.", which is what u also have mentioned.


Indeed. There's more to it than that though, as it affects how *other*
fields are accessed.
See the previously specified link for more details.

Jon


Dec 12 '05 #9

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
Abubakar wrote:
> > No. from msdn: "The volatile keyword is a type qualifier used to
> > declare
> > that an object can be modified in the program by something such as
> > the
> > operating system, the hardware, or a concurrently executing thread."
> > Volatile keyword does not make your variable syncronized.
>
> Unless I'm mistaken, you're quoting from the C/C++ documentation, which
> doesn't apply to C#.


I just checked the C# Programmer's Reference, and it quotes what Vladimir
posted.


Well, nearly - not exactly. The phrase "type qualifier" never appears,
for instance.
The link is:


<snip>
msdn : "The volatile keyword indicates that a field can be modified in
the
program by something such as the operating system, the hardware, or a
concurrently executing thread."


That's unfortunate, in my view. It makes volatile fields sound too much
like C/C++ volatile fields, whereas I believe the behaviour is
significantly different.


IMO the semantics are exactly the same, in what sense would they be
different?
The JIT compiler generates exactly the same native X86 instructions from the
IL stream as the C compiler back-end does from the C token stream for
volatile field accesses.

That means that following C# snip:

static volatile int v;
int u;
...

v = 0;
// other C# code statements that don't use i
....
u = i;
effectively writes the value 0 to the "memory location" at the point of the
assignment in the source code, and reads the same location back to store the
value in u.

Note that the JIT compiler produces the following X86 stream (comments
added).

xor edx, edx -> clear edx
mov [0x09122446], edx -> store edx into location at address 0x09122446
(fictive address)
....// other JITed code
mov eax, [0x09122446] -> load contents of volatile memory at 0x09122446
into eax
mov [0x0912245a] , eax -> move value read from volatile field to location
of u.

which is exactly the same as produced by the C++ back-end for the same code
snip.
Note here that the compilers are not allowed to:
- optimize away the first store,
- reuse edx to load the value into u
- to move the first store until after the load of v

So following is not allowed:

....// other JITed code
xor edx, edx -> clear edx
mov [0x0912245a] , edx -> don't bother about i and move 0 into u
mov [0x09122446], edx -> move O into v

while it's perfectly valid for optimized builds when v is not volatile.

Willy.

PS. Note that these kind of optimizations are not (yet) done b the JIT
compiler.


Dec 12 '05 #10
Willy Denoyette [MVP] <wi*************@telenet.be> wrote:
That's unfortunate, in my view. It makes volatile fields sound too much
like C/C++ volatile fields, whereas I believe the behaviour is
significantly different.


IMO the semantics are exactly the same, in what sense would they be
different?


I expect they're the same for managed code - sorry, I wasn't clear. I
think they're different than the semantics for *unmanaged* code, in
that the memory model is much more explicit. In particular, I'd expect
that in *some* implementations of C/C++, the volatility of one variable
doesn't affect how another variable is accessed. (That's the case in
Java.)

Put it this way - even if the MS compiler generates the same code, can
you point to places in the C specification which indicate that the same
semantics are required with respect to volatile in unmanaged C as in
managed code?

--
Jon Skeet - <sk***@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
Dec 12 '05 #11

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Willy Denoyette [MVP] <wi*************@telenet.be> wrote:
> That's unfortunate, in my view. It makes volatile fields sound too much
> like C/C++ volatile fields, whereas I believe the behaviour is
> significantly different.


IMO the semantics are exactly the same, in what sense would they be
different?


I expect they're the same for managed code - sorry, I wasn't clear. I
think they're different than the semantics for *unmanaged* code, in
that the memory model is much more explicit. In particular, I'd expect
that in *some* implementations of C/C++, the volatility of one variable
doesn't affect how another variable is accessed. (That's the case in
Java.)

Put it this way - even if the MS compiler generates the same code, can
you point to places in the C specification which indicate that the same
semantics are required with respect to volatile in unmanaged C as in
managed code?

--
Jon Skeet - <sk***@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


While the volatile keyword is part of the C++ language, but it's semantics
are platform dependant and the standard allows a compiler to ignore the
keywords.
But, what I refered to is MSFT's implementation as described in C/C++
documention Language Reference (MSDN).
MSFT C++ compiler (VC++) Volatile semantics apply to both managed and
unmanaged C++ language syntax for X86 and X64 platforms, note that the
example I gave is comparing C# and native VC++ behavior.

Willy.

Dec 12 '05 #12
Willy Denoyette [MVP] <wi*************@telenet.be> wrote:
Put it this way - even if the MS compiler generates the same code, can
you point to places in the C specification which indicate that the same
semantics are required with respect to volatile in unmanaged C as in
managed code? While the volatile keyword is part of the C++ language, but it's semantics
are platform dependant and the standard allows a compiler to ignore the
keywords.


Exactly. That was what I was trying (apparently somewhat unsuccessfully
:) to say.
But, what I refered to is MSFT's implementation as described in C/C++
documention Language Reference (MSDN).
MSFT C++ compiler (VC++) Volatile semantics apply to both managed and
unmanaged C++ language syntax for X86 and X64 platforms, note that the
example I gave is comparing C# and native VC++ behavior.


Looking again at MSDN, it certainly talks about acquire/release
semantics, but only mentions "global or static objects". Does this
include global variables of primitive types, for instance? I would
imagine it probably does, but I don't know enough details about C++
terminology to say for sure.

I guess what I'm really trying to say is that C/C++ programmers should
really look carefully at the .NET memory model, trying to put knowledge
of C/C++ memory models behind them, however similar they *may* be. I
believe it's easier to learn something from scratch than to try to work
out any precise differences.

--
Jon Skeet - <sk***@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
Dec 12 '05 #13

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Willy Denoyette [MVP] <wi*************@telenet.be> wrote:
> Put it this way - even if the MS compiler generates the same code, can
> you point to places in the C specification which indicate that the same
> semantics are required with respect to volatile in unmanaged C as in
> managed code? While the volatile keyword is part of the C++ language, but it's
semantics
are platform dependant and the standard allows a compiler to ignore the
keywords.


Exactly. That was what I was trying (apparently somewhat unsuccessfully
:) to say.
But, what I refered to is MSFT's implementation as described in C/C++
documention Language Reference (MSDN).
MSFT C++ compiler (VC++) Volatile semantics apply to both managed and
unmanaged C++ language syntax for X86 and X64 platforms, note that the
example I gave is comparing C# and native VC++ behavior.


Looking again at MSDN, it certainly talks about acquire/release
semantics, but only mentions "global or static objects". Does this
include global variables of primitive types, for instance? I would
imagine it probably does, but I don't know enough details about C++
terminology to say for sure.

Don't know why they only mention "global or static" objects, the VC compiler
also allows locals to be volatile (this is not true for C#). Yes, the same
primitive types are valid as long as their size is smaller than the
platforms native word size (32 bits on X86).
So for C++ we have bool, (unsigned/signed) char, short, int - float, and
pointer variables.


I guess what I'm really trying to say is that C/C++ programmers should
really look carefully at the .NET memory model, trying to put knowledge
of C/C++ memory models behind them, however similar they *may* be. I
believe it's easier to learn something from scratch than to try to work
out any precise differences.

Absolutely right, C++ programmers in general ignore the volatile qualifier
completely, the few who use it know (or should know) the memory model and
platform specifics, in general driver writers know how to use volatile.
--
Jon Skeet - <sk***@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


Willy.
Dec 12 '05 #14

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Andrew | last post: by
4 posts views Thread by Anh-Tu Vo | last post: by
22 posts views Thread by Assaf | last post: by
1 post views Thread by Eric | last post: by
14 posts views Thread by Pierre | last post: by
3 posts views Thread by Amir Shitrit | last post: by
94 posts views Thread by Samuel R. Neff | last post: by
5 posts views Thread by Mark Salsbery [MVP] | 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.