473,287 Members | 1,492 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,287 software developers and data experts.

use of volatile keyword

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
is this the proper use of volatile?

2. when declaring a variable of type long, i get a compilation error
cannot use volatile with long!
does this mean that all long's are automatically volatile?
i am assuming that since they are 64 bit, the compiler will never place
them in the CPU.

any help or thoughts is very much appreciated.

assaf

Nov 15 '05 #1
22 2231
Hi Assaf,
I take it you use c#.
1. i use volatile when 2 threads access the same variable
is this the proper use of volatile? Yes, this is one of the places where *volatile* modifier is used. However
you are not expecting to have thread safety by using *volatile* only, aren't
you. Even with volatile you will have access to shared resource so locks or
other sync techniques should be used.

2. when declaring a variable of type long, i get a compilation error
cannot use volatile with long!
does this mean that all long's are automatically volatile?
i am assuming that since they are 64 bit, the compiler will never place them in the CPU.

I couldn't find any info why *long* variables cannot be *volatile* and I
believe they are not rather than they are always.
For one variable to be volatile is not enough not to be cached int the CPU
registers. It affect optimization done by the c# compiler and JIT compiler.

HTH
B\rgds
100

"Assaf" <as**************************@hotmail.com> wrote in message
news:eS**************@TK2MSFTNGP10.phx.gbl...
Nov 15 '05 #2
Stoitcho Goutsev (100) [C# MVP] wrote:
Hi Assaf,
I take it you use c#.
1. i use volatile when 2 threads access the same variable
is this the proper use of volatile? Yes, this is one of the places where *volatile* modifier is used. However
you are not expecting to have thread safety by using *volatile* only,

aren't you. Even with volatile you will have access to shared resource so locks or other sync techniques should be used.


Volatile used to cause a build error in the CF. Make it actually compiles
before you think things through too much.

2. when declaring a variable of type long, i get a compilation error
cannot use volatile with long!
does this mean that all long's are automatically volatile?
i am assuming that since they are 64 bit, the compiler will never

place
them in the CPU.

I couldn't find any info why *long* variables cannot be *volatile* and I
believe they are not rather than they are always.


Probably because loading/storing a long is not an atomic operation and
therfore isn't safe.

Hilton
Nov 15 '05 #3

I couldn't find any info why *long* variables cannot be *volatile* and I
believe they are not rather than they are always.


Probably because loading/storing a long is not an atomic operation and
therfore isn't safe.


Yes, it volatile is useful only for atomic types which (64bit integer
certainly isn't).

--
Miha Markic [MVP C#] - RightHand .NET consulting & software development
miha at rthand com
www.rthand.com
Nov 15 '05 #4
hi

1. why is volatile usefull for atomic types only?
2. what is your statement based on?
3. 64 bit not atomic - is that not cpu dependant?
4. so do you mean that 'long' is _always_ 'volatile'?

assaf

"Miha Markic [MVP C#]" <miha at rthand com> wrote in message
news:OJ**************@TK2MSFTNGP10.phx.gbl...

I couldn't find any info why *long* variables cannot be *volatile* and I believe they are not rather than they are always.


Probably because loading/storing a long is not an atomic operation and
therfore isn't safe.


Yes, it volatile is useful only for atomic types which (64bit integer
certainly isn't).

--
Miha Markic [MVP C#] - RightHand .NET consulting & software development
miha at rthand com
www.rthand.com

Nov 15 '05 #5
Hi Assaf,

"Assaf" <assafwo_YOU_KNOW_WHAT_TO_DO_ at hotmail dot com> wrote in message
news:ex**************@TK2MSFTNGP09.phx.gbl...
hi

1. why is volatile usefull for atomic types only?
AFAIK volatile is used when you read/write from a variable that is not
synchronized via any synchronization method.
Writing and reading to an integer (where size is equal or less then CPU
bytes) is an atomic operation and doesn't need to be synchronized.
However, if you are practising this on dual or more processor machines the
processors can have different variable versions in their cache.
Here comes volatile keyword into play. It forces processors to look at the
same variable.
Using volatile for complex types (or non-atomic) doesn't make sense since
you will always need to synchronize access to them.
2. what is your statement based on?
10.4.3 Volatile fields
3. 64 bit not atomic - is that not cpu dependant?
It is.
4. so do you mean that 'long' is _always_ 'volatile'?


No. It means that can't be volatile because you have to sync access.

--
Miha Markic [MVP C#] - RightHand .NET consulting & software development
miha at rthand com
www.rthand.com
Nov 15 '05 #6
Just for more info, see also:

http://discuss.develop.com/archives/...=DOTNET&P=R375

"Miha Markic [MVP C#]" <miha at rthand com> wrote in message
news:uf**************@TK2MSFTNGP11.phx.gbl...
Hi Assaf,

"Assaf" <assafwo_YOU_KNOW_WHAT_TO_DO_ at hotmail dot com> wrote in message
news:ex**************@TK2MSFTNGP09.phx.gbl...
hi

1. why is volatile usefull for atomic types only?


AFAIK volatile is used when you read/write from a variable that is not
synchronized via any synchronization method.
Writing and reading to an integer (where size is equal or less then CPU
bytes) is an atomic operation and doesn't need to be synchronized.
However, if you are practising this on dual or more processor machines the
processors can have different variable versions in their cache.
Here comes volatile keyword into play. It forces processors to look at the
same variable.
Using volatile for complex types (or non-atomic) doesn't make sense since
you will always need to synchronize access to them.
2. what is your statement based on?


10.4.3 Volatile fields
3. 64 bit not atomic - is that not cpu dependant?


It is.
4. so do you mean that 'long' is _always_ 'volatile'?


No. It means that can't be volatile because you have to sync access.

--
Miha Markic [MVP C#] - RightHand .NET consulting & software development
miha at rthand com
www.rthand.com

Nov 15 '05 #7
volatile will not help you use variables without synchronization. If you'd
run your code on multiple CPUs writing into a volatile variable will not
necessarily update that memory location in all CPUs that cached it. That
only happens when you use synchronization code (locks, interlocked access
and so on). So be careful, especially if you test on a single CPU machine
and it seems to work.

Jerry

"Miha Markic [MVP C#]" <miha at rthand com> wrote in message
news:uf**************@TK2MSFTNGP11.phx.gbl...
Hi Assaf,

"Assaf" <assafwo_YOU_KNOW_WHAT_TO_DO_ at hotmail dot com> wrote in message
news:ex**************@TK2MSFTNGP09.phx.gbl...
hi

1. why is volatile usefull for atomic types only?


AFAIK volatile is used when you read/write from a variable that is not
synchronized via any synchronization method.
Writing and reading to an integer (where size is equal or less then CPU
bytes) is an atomic operation and doesn't need to be synchronized.
However, if you are practising this on dual or more processor machines the
processors can have different variable versions in their cache.
Here comes volatile keyword into play. It forces processors to look at the
same variable.
Using volatile for complex types (or non-atomic) doesn't make sense since
you will always need to synchronize access to them.
2. what is your statement based on?


10.4.3 Volatile fields
3. 64 bit not atomic - is that not cpu dependant?


It is.
4. so do you mean that 'long' is _always_ 'volatile'?


No. It means that can't be volatile because you have to sync access.

--
Miha Markic [MVP C#] - RightHand .NET consulting & software development
miha at rthand com
www.rthand.com

Nov 15 '05 #8
hi jerry.

your statement is in DIRECT CONTRADICTION to the docs.

(but what do i know?
im just a programmer)

assaf
"Jerry III" <je******@hotmail.com> wrote in message
news:uc**************@TK2MSFTNGP11.phx.gbl...
volatile will not help you use variables without synchronization. If you'd
run your code on multiple CPUs writing into a volatile variable will not
necessarily update that memory location in all CPUs that cached it. That
only happens when you use synchronization code (locks, interlocked access
and so on). So be careful, especially if you test on a single CPU machine
and it seems to work.

Jerry

"Miha Markic [MVP C#]" <miha at rthand com> wrote in message
news:uf**************@TK2MSFTNGP11.phx.gbl...
Hi Assaf,

"Assaf" <assafwo_YOU_KNOW_WHAT_TO_DO_ at hotmail dot com> wrote in message news:ex**************@TK2MSFTNGP09.phx.gbl...
hi

1. why is volatile usefull for atomic types only?


AFAIK volatile is used when you read/write from a variable that is not
synchronized via any synchronization method.
Writing and reading to an integer (where size is equal or less then CPU
bytes) is an atomic operation and doesn't need to be synchronized.
However, if you are practising this on dual or more processor machines the processors can have different variable versions in their cache.
Here comes volatile keyword into play. It forces processors to look at the same variable.
Using volatile for complex types (or non-atomic) doesn't make sense since you will always need to synchronize access to them.
2. what is your statement based on?


10.4.3 Volatile fields
3. 64 bit not atomic - is that not cpu dependant?


It is.
4. so do you mean that 'long' is _always_ 'volatile'?


No. It means that can't be volatile because you have to sync access.

--
Miha Markic [MVP C#] - RightHand .NET consulting & software development
miha at rthand com
www.rthand.com


Nov 15 '05 #9
Jerry III <je******@hotmail.com> wrote:
volatile will not help you use variables without synchronization. If you'd
run your code on multiple CPUs writing into a volatile variable will not
necessarily update that memory location in all CPUs that cached it. That
only happens when you use synchronization code (locks, interlocked access
and so on). So be careful, especially if you test on a single CPU machine
and it seems to work.


Actually, the whole point of volatile variables is that they *won't* be
cached. See section 12.6.7 (IIRC) from partition I of the ECMA spec.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #10
hi all.

i'm sorry for opening a new sub-branch.
but,
could someone please tell me what to assume?
long is volatile by default?
yes or no?

assaf
"Assaf" <as**************************@hotmail.com> wrote in message
news:eS**************@TK2MSFTNGP10.phx.gbl...
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
is this the proper use of volatile?

2. when declaring a variable of type long, i get a compilation error
cannot use volatile with long!
does this mean that all long's are automatically volatile?
i am assuming that since they are 64 bit, the compiler will never place them in the CPU.

any help or thoughts is very much appreciated.

assaf

Nov 15 '05 #11
You're right (and so is Assaf). I'm not sure what I was thinking when I
wrote that...

Jerry

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Jerry III <je******@hotmail.com> wrote:
volatile will not help you use variables without synchronization. If you'd run your code on multiple CPUs writing into a volatile variable will not
necessarily update that memory location in all CPUs that cached it. That
only happens when you use synchronization code (locks, interlocked access and so on). So be careful, especially if you test on a single CPU machine and it seems to work.


Actually, the whole point of volatile variables is that they *won't* be
cached. See section 12.6.7 (IIRC) from partition I of the ECMA spec.

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

Nov 15 '05 #12
Assaf <as**************************@hotmail.com> wrote:
could someone please tell me what to assume?
long is volatile by default?
yes or no?


No, long is not volatile by default. You'll need to take out a specific
lock in order to handle the data correctly - which is the general case,
to be honest. (You can, however, use the Interlocked class with longs.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #13
hi jon

i am a little confused about lock vs. volatile.
as far as i understand,
there is no corelation between the two concepts!

why do people keep refering to 'locking'
when i am talking about 'caching' (volatile)?

i just took a look at the Interlocked class that you mentioned,
and there is no mention there that the variable will not be cached!

in any case,
as to your statement:
'No, long is not volatile by default'
what do you base it on?

if it is not volatile,
it might be cached,
in which case, i'll solve it,
but not by means of a lock,
unless the compiler is smart not to cached variables
accessed in locked sections

(which i doubt it does,
it would certainly degrade performatnce
not to use caching for all variables
in locked sections)

assaf
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP**********************@msnews.microsoft.com ...
Assaf <as**************************@hotmail.com> wrote:
could someone please tell me what to assume?
long is volatile by default?
yes or no?


No, long is not volatile by default. You'll need to take out a specific
lock in order to handle the data correctly - which is the general case,
to be honest. (You can, however, use the Interlocked class with longs.)

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

Nov 15 '05 #14
Assaf <as**************************@hotmail.com> wrote:
i am a little confused about lock vs. volatile.
as far as i understand,
there is no corelation between the two concepts!
Yes there is. Taking out a lock involves a memory barrier, as does
releasing a lock. In effect, so long as your "reading" and "writing"
sections of code both take out locks on the same reference, you get
volatile behaviour. I suggest you read the CLR spec's memory model.
Note that the reference to be locked is automatically treated as
volatile for the purposes of locking.
why do people keep refering to 'locking'
when i am talking about 'caching' (volatile)?
Because they're intimately related.
i just took a look at the Interlocked class that you mentioned,
and there is no mention there that the variable will not be cached!
The whole point of the Interlocked class is to make things thread-safe
- it does "the right thing". However, it's really only useful when
you're incrementing/decrementing/exchanging values, not just reading
them.
in any case,
as to your statement:
'No, long is not volatile by default'
what do you base it on?
The fact that nothing is volatile by default - why would it be?
if it is not volatile, it might be cached, in which case, i'll solve
it, but not by means of a lock, unless the compiler is smart not to
cached variables accessed in locked sections
So how would you solve it without a lock?
(which i doubt it does, it would certainly degrade performatnce not
to use caching for all variables in locked sections)


Hopefully once you've read the spec you'll understand how it works.

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

concerning your statement:
'I suggest you read the CLR spec's memory model.'
could you please give me a link to the spec?
if it comes with visual studio, than just tell me the file name.

tnx

assaf

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Assaf <as**************************@hotmail.com> wrote:
i am a little confused about lock vs. volatile.
as far as i understand,
there is no corelation between the two concepts!


Yes there is. Taking out a lock involves a memory barrier, as does
releasing a lock. In effect, so long as your "reading" and "writing"
sections of code both take out locks on the same reference, you get
volatile behaviour. I suggest you read the CLR spec's memory model.
Note that the reference to be locked is automatically treated as
volatile for the purposes of locking.
why do people keep refering to 'locking'
when i am talking about 'caching' (volatile)?


Because they're intimately related.
i just took a look at the Interlocked class that you mentioned,
and there is no mention there that the variable will not be cached!


The whole point of the Interlocked class is to make things thread-safe
- it does "the right thing". However, it's really only useful when
you're incrementing/decrementing/exchanging values, not just reading
them.
in any case,
as to your statement:
'No, long is not volatile by default'
what do you base it on?


The fact that nothing is volatile by default - why would it be?
if it is not volatile, it might be cached, in which case, i'll solve
it, but not by means of a lock, unless the compiler is smart not to
cached variables accessed in locked sections


So how would you solve it without a lock?
(which i doubt it does, it would certainly degrade performatnce not
to use caching for all variables in locked sections)


Hopefully once you've read the spec you'll understand how it works.

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

Nov 15 '05 #16
Assaf <as**************************@hotmail.com> wrote:
concerning your statement:
'I suggest you read the CLR spec's memory model.'
could you please give me a link to the spec?
if it comes with visual studio, than just tell me the file name.


http://www.ecma-international.org/pu...s/Ecma-335.htm

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #17
If you use a lock the compiler might still "cache" (I really have no idea
what you mean by that as compiler doesn't cache anything, the CPU caches the
memory - maybe you're talking about optimizations where the compiler decides
not to fetch the variable from the memory but rather uses a register value
left over from some previous computing) but the CPU cache will be refreshed
every time you use a locking function (such as when you acquire/release a
lock) or when you use an interlocked function. For details you should read
the documentation, Win32 API docs is very detailed about this (and it's
generic enough so it doesn't really apply to Win32 API only but to any code
running on pretty much any CPU, even though the implementation details vary
by CPU). I suggest you start here:
http://msdn.microsoft.com/library/en...ronization.asp -
the About Synchronization section is really useful.

Jerry

"Assaf" <as**************************@hotmail.com> wrote in message
news:ek**************@TK2MSFTNGP10.phx.gbl...
hi jon

i am a little confused about lock vs. volatile.
as far as i understand,
there is no corelation between the two concepts!

why do people keep refering to 'locking'
when i am talking about 'caching' (volatile)?

i just took a look at the Interlocked class that you mentioned,
and there is no mention there that the variable will not be cached!

in any case,
as to your statement:
'No, long is not volatile by default'
what do you base it on?

if it is not volatile,
it might be cached,
in which case, i'll solve it,
but not by means of a lock,
unless the compiler is smart not to cached variables
accessed in locked sections

(which i doubt it does,
it would certainly degrade performatnce
not to use caching for all variables
in locked sections)

assaf
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP**********************@msnews.microsoft.com ...
Assaf <as**************************@hotmail.com> wrote:
could someone please tell me what to assume?
long is volatile by default?
yes or no?


No, long is not volatile by default. You'll need to take out a specific
lock in order to handle the data correctly - which is the general case,
to be honest. (You can, however, use the Interlocked class with longs.)

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


Nov 15 '05 #18
If you use a lock the compiler might still "cache" (I really have no idea
what you mean by that as compiler doesn't cache anything, the CPU caches the
memory - maybe you're talking about optimizations where the compiler decides
not to fetch the variable from the memory but rather uses a register value
left over from some previous computing) but the CPU cache will be refreshed
every time you use a locking function (such as when you acquire/release a
lock) or when you use an interlocked function. For details you should read
the documentation, Win32 API docs is very detailed about this (and it's
generic enough so it doesn't really apply to Win32 API only but to any code
running on pretty much any CPU, even though the implementation details vary
by CPU). I suggest you start here:
http://msdn.microsoft.com/library/en...ronization.asp -
the About Synchronization section is really useful.

Jerry

"Assaf" <as**************************@hotmail.com> wrote in message
news:ek**************@TK2MSFTNGP10.phx.gbl...
hi jon

i am a little confused about lock vs. volatile.
as far as i understand,
there is no corelation between the two concepts!

why do people keep refering to 'locking'
when i am talking about 'caching' (volatile)?

i just took a look at the Interlocked class that you mentioned,
and there is no mention there that the variable will not be cached!

in any case,
as to your statement:
'No, long is not volatile by default'
what do you base it on?

if it is not volatile,
it might be cached,
in which case, i'll solve it,
but not by means of a lock,
unless the compiler is smart not to cached variables
accessed in locked sections

(which i doubt it does,
it would certainly degrade performatnce
not to use caching for all variables
in locked sections)

assaf
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP**********************@msnews.microsoft.com ...
Assaf <as**************************@hotmail.com> wrote:
could someone please tell me what to assume?
long is volatile by default?
yes or no?


No, long is not volatile by default. You'll need to take out a specific
lock in order to handle the data correctly - which is the general case,
to be honest. (You can, however, use the Interlocked class with longs.)

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


Nov 15 '05 #19
hi Jerry.

you are quoting Win32?
what has that got anything to do with .NET?

assaf

"Jerry III" <je******@hotmail.com> wrote in message
news:#h*************@TK2MSFTNGP12.phx.gbl...
If you use a lock the compiler might still "cache" (I really have no idea
what you mean by that as compiler doesn't cache anything, the CPU caches the memory - maybe you're talking about optimizations where the compiler decides not to fetch the variable from the memory but rather uses a register value
left over from some previous computing) but the CPU cache will be refreshed every time you use a locking function (such as when you acquire/release a
lock) or when you use an interlocked function. For details you should read
the documentation, Win32 API docs is very detailed about this (and it's
generic enough so it doesn't really apply to Win32 API only but to any code running on pretty much any CPU, even though the implementation details vary by CPU). I suggest you start here:
http://msdn.microsoft.com/library/en...ronization.asp -
the About Synchronization section is really useful.

Jerry

"Assaf" <as**************************@hotmail.com> wrote in message
news:ek**************@TK2MSFTNGP10.phx.gbl...
hi jon

i am a little confused about lock vs. volatile.
as far as i understand,
there is no corelation between the two concepts!

why do people keep refering to 'locking'
when i am talking about 'caching' (volatile)?

i just took a look at the Interlocked class that you mentioned,
and there is no mention there that the variable will not be cached!

in any case,
as to your statement:
'No, long is not volatile by default'
what do you base it on?

if it is not volatile,
it might be cached,
in which case, i'll solve it,
but not by means of a lock,
unless the compiler is smart not to cached variables
accessed in locked sections

(which i doubt it does,
it would certainly degrade performatnce
not to use caching for all variables
in locked sections)

assaf
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP**********************@msnews.microsoft.com ...
Assaf <as**************************@hotmail.com> wrote:
> could someone please tell me what to assume?
> long is volatile by default?
> yes or no?

No, long is not volatile by default. You'll need to take out a specific lock in order to handle the data correctly - which is the general case, to be honest. (You can, however, use the Interlocked class with longs.)
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too



Nov 15 '05 #20
hi Jerry.

you are quoting Win32?
what has that got anything to do with .NET?

assaf

"Jerry III" <je******@hotmail.com> wrote in message
news:#h*************@TK2MSFTNGP12.phx.gbl...
If you use a lock the compiler might still "cache" (I really have no idea
what you mean by that as compiler doesn't cache anything, the CPU caches the memory - maybe you're talking about optimizations where the compiler decides not to fetch the variable from the memory but rather uses a register value
left over from some previous computing) but the CPU cache will be refreshed every time you use a locking function (such as when you acquire/release a
lock) or when you use an interlocked function. For details you should read
the documentation, Win32 API docs is very detailed about this (and it's
generic enough so it doesn't really apply to Win32 API only but to any code running on pretty much any CPU, even though the implementation details vary by CPU). I suggest you start here:
http://msdn.microsoft.com/library/en...ronization.asp -
the About Synchronization section is really useful.

Jerry

"Assaf" <as**************************@hotmail.com> wrote in message
news:ek**************@TK2MSFTNGP10.phx.gbl...
hi jon

i am a little confused about lock vs. volatile.
as far as i understand,
there is no corelation between the two concepts!

why do people keep refering to 'locking'
when i am talking about 'caching' (volatile)?

i just took a look at the Interlocked class that you mentioned,
and there is no mention there that the variable will not be cached!

in any case,
as to your statement:
'No, long is not volatile by default'
what do you base it on?

if it is not volatile,
it might be cached,
in which case, i'll solve it,
but not by means of a lock,
unless the compiler is smart not to cached variables
accessed in locked sections

(which i doubt it does,
it would certainly degrade performatnce
not to use caching for all variables
in locked sections)

assaf
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP**********************@msnews.microsoft.com ...
Assaf <as**************************@hotmail.com> wrote:
> could someone please tell me what to assume?
> long is volatile by default?
> yes or no?

No, long is not volatile by default. You'll need to take out a specific lock in order to handle the data correctly - which is the general case, to be honest. (You can, however, use the Interlocked class with longs.)
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too



Nov 15 '05 #21
Because the Win32 documents explain how the hardware handles memory access.
..Net only wraps this in a nice package for you, the basics are still the
same. If you understand how memory is being accessed in general then you
would understand the different options .Net gives you.

Jerry

"Assaf" <assafwo_YOU_KNOW_WHAT_TO_DO_ at hotmail dot com> wrote in message
news:e7**************@TK2MSFTNGP09.phx.gbl...
hi Jerry.

you are quoting Win32?
what has that got anything to do with .NET?

assaf

"Jerry III" <je******@hotmail.com> wrote in message
news:#h*************@TK2MSFTNGP12.phx.gbl...
If you use a lock the compiler might still "cache" (I really have no idea
what you mean by that as compiler doesn't cache anything, the CPU caches

the
memory - maybe you're talking about optimizations where the compiler

decides
not to fetch the variable from the memory but rather uses a register value left over from some previous computing) but the CPU cache will be

refreshed
every time you use a locking function (such as when you acquire/release a lock) or when you use an interlocked function. For details you should read the documentation, Win32 API docs is very detailed about this (and it's
generic enough so it doesn't really apply to Win32 API only but to any

code
running on pretty much any CPU, even though the implementation details

vary
by CPU). I suggest you start here:
http://msdn.microsoft.com/library/en...ronization.asp - the About Synchronization section is really useful.

Jerry

"Assaf" <as**************************@hotmail.com> wrote in message
news:ek**************@TK2MSFTNGP10.phx.gbl...
hi jon

i am a little confused about lock vs. volatile.
as far as i understand,
there is no corelation between the two concepts!

why do people keep refering to 'locking'
when i am talking about 'caching' (volatile)?

i just took a look at the Interlocked class that you mentioned,
and there is no mention there that the variable will not be cached!

in any case,
as to your statement:
'No, long is not volatile by default'
what do you base it on?

if it is not volatile,
it might be cached,
in which case, i'll solve it,
but not by means of a lock,
unless the compiler is smart not to cached variables
accessed in locked sections

(which i doubt it does,
it would certainly degrade performatnce
not to use caching for all variables
in locked sections)

assaf
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP**********************@msnews.microsoft.com ...
> Assaf <as**************************@hotmail.com> wrote:
> > could someone please tell me what to assume?
> > long is volatile by default?
> > yes or no?
>
> No, long is not volatile by default. You'll need to take out a

specific > lock in order to handle the data correctly - which is the general case, > to be honest. (You can, however, use the Interlocked class with longs.) >
> --
> Jon Skeet - <sk***@pobox.com>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too



Nov 15 '05 #22
Because the Win32 documents explain how the hardware handles memory access.
..Net only wraps this in a nice package for you, the basics are still the
same. If you understand how memory is being accessed in general then you
would understand the different options .Net gives you.

Jerry

"Assaf" <assafwo_YOU_KNOW_WHAT_TO_DO_ at hotmail dot com> wrote in message
news:e7**************@TK2MSFTNGP09.phx.gbl...
hi Jerry.

you are quoting Win32?
what has that got anything to do with .NET?

assaf

"Jerry III" <je******@hotmail.com> wrote in message
news:#h*************@TK2MSFTNGP12.phx.gbl...
If you use a lock the compiler might still "cache" (I really have no idea
what you mean by that as compiler doesn't cache anything, the CPU caches

the
memory - maybe you're talking about optimizations where the compiler

decides
not to fetch the variable from the memory but rather uses a register value left over from some previous computing) but the CPU cache will be

refreshed
every time you use a locking function (such as when you acquire/release a lock) or when you use an interlocked function. For details you should read the documentation, Win32 API docs is very detailed about this (and it's
generic enough so it doesn't really apply to Win32 API only but to any

code
running on pretty much any CPU, even though the implementation details

vary
by CPU). I suggest you start here:
http://msdn.microsoft.com/library/en...ronization.asp - the About Synchronization section is really useful.

Jerry

"Assaf" <as**************************@hotmail.com> wrote in message
news:ek**************@TK2MSFTNGP10.phx.gbl...
hi jon

i am a little confused about lock vs. volatile.
as far as i understand,
there is no corelation between the two concepts!

why do people keep refering to 'locking'
when i am talking about 'caching' (volatile)?

i just took a look at the Interlocked class that you mentioned,
and there is no mention there that the variable will not be cached!

in any case,
as to your statement:
'No, long is not volatile by default'
what do you base it on?

if it is not volatile,
it might be cached,
in which case, i'll solve it,
but not by means of a lock,
unless the compiler is smart not to cached variables
accessed in locked sections

(which i doubt it does,
it would certainly degrade performatnce
not to use caching for all variables
in locked sections)

assaf
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP**********************@msnews.microsoft.com ...
> Assaf <as**************************@hotmail.com> wrote:
> > could someone please tell me what to assume?
> > long is volatile by default?
> > yes or no?
>
> No, long is not volatile by default. You'll need to take out a

specific > lock in order to handle the data correctly - which is the general case, > to be honest. (You can, however, use the Interlocked class with longs.) >
> --
> Jon Skeet - <sk***@pobox.com>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too



Nov 15 '05 #23

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

17
by: Radde | last post by:
HI, Can volatile variables be accessed by many processess..or only one process can access it.. Cheers..
5
by: ben | last post by:
Hello All, I am trying to make sense of a bit of syntax, is there a guru out there that can clear this up for me. I have a buffer declared as static volatile u8 buffer; and I have a...
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: ...
13
by: yaron | last post by:
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...
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...
3
by: Rakesh Kumar | last post by:
Hi - I am actually trying to get my feet in multi-threaded C++ programming. While I am aware that the C++ standard does not talk about threads (at least, for now - in C++03) - my question is more...
7
by: George2 | last post by:
Hello everyone, In the MSDN volatile sample, http://msdn2.microsoft.com/en-us/library/12a04hfd(VS.80).aspx I do not understand what is the purpose of the sample. I have tried to remove...
3
by: C++Liliput | last post by:
It seems that the keyword "volatile" is used to make sure that threads reading (or writing to) the same data should see a consistent picture of the variable i.e. updates made to the common data...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
by: MeoLessi9 | last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: marcoviolo | last post by:
Dear all, I would like to implement on my worksheet an vlookup dynamic , that consider a change of pivot excel via win32com, from an external excel (without open it) and save the new file into a...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...

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.