473,396 Members | 1,892 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,396 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 1872
"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 thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
by: Andrew | last post by:
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...
4
by: Anh-Tu Vo | last post by:
Hi all, I have a weird problem on a variable assignment. It seems that the variable is only updated with the value at the second time the function is called. My program looks like this: ...
22
by: Assaf | last post by:
hi all i know that i should not cross-post, but i am not sure to which group to post this question. 2 quesions about volatile: 1. i use volatile when 2 threads access the same variable...
1
by: Eric | last post by:
I have some questions about the volatile keyword... 1) If I use the volatile keyword with a reference type such as a class like so: public volatile UserTotals totals = new UserTotals(); Are...
14
by: Pierre | last post by:
Using the "volatile" keyword, creates a problem if I intend to use any of the interlocked APIs. The compiler generates an error if I use the following line, for example: ...
3
by: Amir Shitrit | last post by:
Hello. How come it's safe to read non-volatile fields that are shared across threads using locks for synchronization (for example, Monitor.Enter or EventWaitHandle), but it's not safe to access...
3
by: Ole Nielsby | last post by:
I have objects that sometimes overwrite themselves by something else, using placement new. I will spare you for the details, but the objects serve as stack frames and are placed contiguosly, and...
94
by: Samuel R. Neff | last post by:
When is it appropriate to use "volatile" keyword? The docs simply state: " The volatile modifier is usually used for a field that is accessed by multiple threads without using the lock...
5
by: Mark Salsbery [MVP] | last post by:
I have an member variable (int) that is accessed by multiple threads using Interlocked.Increment(), Interlocked.Decrement(), and read directly. Using volatile gives me "CS0420: a reference to a...
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
0
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
0
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...

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.