473,225 Members | 577 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,225 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 1866
"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...
1
isladogs
by: isladogs | last post by:
The next online meeting of the Access Europe User Group will be on Wednesday 6 Dec 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, Mike...
0
by: VivesProcSPL | last post by:
Obviously, one of the original purposes of SQL is to make data query processing easy. The language uses many English-like terms and syntax in an effort to make it easy to learn, particularly for...
0
by: jianzs | last post by:
Introduction Cloud-native applications are conventionally identified as those designed and nurtured on cloud infrastructure. Such applications, rooted in cloud technologies, skillfully benefit from...
0
by: mar23 | last post by:
Here's the situation. I have a form called frmDiceInventory with subform called subfrmDice. The subform's control source is linked to a query called qryDiceInventory. I've been trying to pick up the...
0
by: abbasky | last post by:
### Vandf component communication method one: data sharing ​ Vandf components can achieve data exchange through data sharing, state sharing, events, and other methods. Vandf's data exchange method...
2
by: jimatqsi | last post by:
The boss wants the word "CONFIDENTIAL" overlaying certain reports. He wants it large, slanted across the page, on every page, very light gray, outlined letters, not block letters. I thought Word Art...
0
by: stefan129 | last post by:
Hey forum members, I'm exploring options for SSL certificates for multiple domains. Has anyone had experience with multi-domain SSL certificates? Any recommendations on reliable providers or specific...
0
Git
by: egorbl4 | last post by:
Скачал я git, хотел начать настройку, а там вылезло вот это Что это? Что мне с этим делать? ...
1
by: davi5007 | last post by:
Hi, Basically, I am trying to automate a field named TraceabilityNo into a web page from an access form. I've got the serial held in the variable strSearchString. How can I get this into the...

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.