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
22  2237 
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...
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Radde |
last post by:
HI,
Can volatile variables be accessed by many processess..or only one
process can access it..
Cheers..
|
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...
|
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...
|
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:
...
|
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...
|
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...
|
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...
|
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...
|
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...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
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...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
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...
|
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...
|
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,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
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...
|
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,...
| |
