use of volatile keyword

[Assaf]

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

[Stoitcho Goutsev \(100\) [C# MVP]]

Re: use of volatile keyword

Hi Assaf,
I take it you use c#.
[color=blue]
> 1. i use volatile when 2 threads access the same variable
> is this the proper use of volatile?[/color]
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.
[color=blue]
>
> 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[/color]
place[color=blue]
> them in the CPU.[/color]


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" <assafwo_YOU_KN OW_WHAT_TO_DO_@ hotmail.com> wrote in message
news:eSTTavd5DH A.1040@TK2MSFTN GP10.phx.gbl...

[Hilton]

Re: use of volatile keyword

Stoitcho Goutsev (100) [C# MVP] wrote:[color=blue]
> Hi Assaf,
> I take it you use c#.
>[color=green]
> > 1. i use volatile when 2 threads access the same variable
> > is this the proper use of volatile?[/color]
> 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,[/color]
aren't[color=blue]
> you. Even with volatile you will have access to shared resource so locks[/color]
or[color=blue]
> other sync techniques should be used.[/color]

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

[color=blue][color=green]
> > 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[/color]
> place[color=green]
> > them in the CPU.[/color]
>
>
> I couldn't find any info why *long* variables cannot be *volatile* and I
> believe they are not rather than they are always.[/color]

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

Hilton

[Miha Markic [MVP C#]]

Re: use of volatile keyword


[color=blue][color=green]
> > I couldn't find any info why *long* variables cannot be *volatile* and I
> > believe they are not rather than they are always.[/color]
>
> Probably because loading/storing a long is not an atomic operation and
> therfore isn't safe.[/color]

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

https://www.rthand.com

[Assaf]

Re: use of volatile keyword

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:OJVEIzk5DH A.2432@TK2MSFTN GP10.phx.gbl...[color=blue]
>
>[color=green][color=darkred]
> > > I couldn't find any info why *long* variables cannot be *volatile* and[/color][/color][/color]
I[color=blue][color=green][color=darkred]
> > > believe they are not rather than they are always.[/color]
> >
> > Probably because loading/storing a long is not an atomic operation and
> > therfore isn't safe.[/color]
>
> 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
>
>[/color]

[Miha Markic [MVP C#]]

Re: use of volatile keyword

Hi Assaf,

"Assaf" <assafwo_YOU_KN OW_WHAT_TO_DO_ at hotmail dot com> wrote in message
news:ex3ddml5DH A.2720@TK2MSFTN GP09.phx.gbl...[color=blue]
> hi
>
> 1. why is volatile usefull for atomic types only?[/color]

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.
[color=blue]
> 2. what is your statement based on?[/color]

10.4.3 Volatile fields
[color=blue]
> 3. 64 bit not atomic - is that not cpu dependant?[/color]

It is.
[color=blue]
> 4. so do you mean that 'long' is _always_ 'volatile'?[/color]

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

https://www.rthand.com

[Philip Rieck]

Re: use of volatile keyword

Just for more info, see also:

http://discuss.develop.com/archives/wa.exe?A2=ind0203B&L=DOTNET&P=R375

"Miha Markic [MVP C#]" <miha at rthand com> wrote in message
news:ufmIsWm5DH A.1664@TK2MSFTN GP11.phx.gbl...[color=blue]
> Hi Assaf,
>
> "Assaf" <assafwo_YOU_KN OW_WHAT_TO_DO_ at hotmail dot com> wrote in message
> news:ex3ddml5DH A.2720@TK2MSFTN GP09.phx.gbl...[color=green]
> > hi
> >
> > 1. why is volatile usefull for atomic types only?[/color]
>
> 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.
>[color=green]
> > 2. what is your statement based on?[/color]
>
> 10.4.3 Volatile fields
>[color=green]
> > 3. 64 bit not atomic - is that not cpu dependant?[/color]
>
> It is.
>[color=green]
> > 4. so do you mean that 'long' is _always_ 'volatile'?[/color]
>
> 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
>
>[/color]

[Jerry III]

Re: use of volatile keyword

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:ufmIsWm5DH A.1664@TK2MSFTN GP11.phx.gbl...[color=blue]
> Hi Assaf,
>
> "Assaf" <assafwo_YOU_KN OW_WHAT_TO_DO_ at hotmail dot com> wrote in message
> news:ex3ddml5DH A.2720@TK2MSFTN GP09.phx.gbl...[color=green]
> > hi
> >
> > 1. why is volatile usefull for atomic types only?[/color]
>
> 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.
>[color=green]
> > 2. what is your statement based on?[/color]
>
> 10.4.3 Volatile fields
>[color=green]
> > 3. 64 bit not atomic - is that not cpu dependant?[/color]
>
> It is.
>[color=green]
> > 4. so do you mean that 'long' is _always_ 'volatile'?[/color]
>
> 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
>
>[/color]

[Assaf]

Re: use of volatile keyword

hi jerry.

your statement is in DIRECT CONTRADICTION to the docs.

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

assaf


"Jerry III" <jerryiii@hotma il.com> wrote in message
news:ucHzpfp5DH A.2656@TK2MSFTN GP11.phx.gbl...[color=blue]
> 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:ufmIsWm5DH A.1664@TK2MSFTN GP11.phx.gbl...[color=green]
> > Hi Assaf,
> >
> > "Assaf" <assafwo_YOU_KN OW_WHAT_TO_DO_ at hotmail dot com> wrote in[/color][/color]
message[color=blue][color=green]
> > news:ex3ddml5DH A.2720@TK2MSFTN GP09.phx.gbl...[color=darkred]
> > > hi
> > >
> > > 1. why is volatile usefull for atomic types only?[/color]
> >
> > 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[/color][/color]
the[color=blue][color=green]
> > processors can have different variable versions in their cache.
> > Here comes volatile keyword into play. It forces processors to look at[/color][/color]
the[color=blue][color=green]
> > same variable.
> > Using volatile for complex types (or non-atomic) doesn't make sense[/color][/color]
since[color=blue][color=green]
> > you will always need to synchronize access to them.
> >[color=darkred]
> > > 2. what is your statement based on?[/color]
> >
> > 10.4.3 Volatile fields
> >[color=darkred]
> > > 3. 64 bit not atomic - is that not cpu dependant?[/color]
> >
> > It is.
> >[color=darkred]
> > > 4. so do you mean that 'long' is _always_ 'volatile'?[/color]
> >
> > 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
> >
> >[/color]
>
>[/color]

[Jon Skeet [C# MVP]]

Re: use of volatile keyword

Jerry III <jerryiii@hotma il.com> wrote:[color=blue]
> 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.[/color]

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 - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[Assaf]

Re: use of volatile keyword

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" <assafwo_YOU_KN OW_WHAT_TO_DO_@ hotmail.com> wrote in message
news:eSTTavd5DH A.1040@TK2MSFTN GP10.phx.gbl...[color=blue]
> 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[/color]
place[color=blue]
> them in the CPU.
>
> any help or thoughts is very much appreciated.
>
> assaf
>
>
>[/color]

[Jerry III]

Re: use of volatile keyword

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

Jerry

"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.1a836e 2e864f352998a00 e@msnews.micros oft.com...[color=blue]
> Jerry III <jerryiii@hotma il.com> wrote:[color=green]
> > volatile will not help you use variables without synchronization . If[/color][/color]
you'd[color=blue][color=green]
> > 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[/color][/color]
access[color=blue][color=green]
> > and so on). So be careful, especially if you test on a single CPU[/color][/color]
machine[color=blue][color=green]
> > and it seems to work.[/color]
>
> 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 - <skeet@pobox.co m>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too[/color]

[Jon Skeet [C# MVP]]

Re: use of volatile keyword

Assaf <assafwo_YOU_KN OW_WHAT_TO_DO_@ hotmail.com> wrote:[color=blue]
> could someone please tell me what to assume?
> long is volatile by default?
> yes or no?[/color]

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 - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[Assaf]

Re: use of volatile keyword

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]" <skeet@pobox.co m> wrote in message
news:MPG.1a8425 e63121fa98a014@ msnews.microsof t.com...[color=blue]
> Assaf <assafwo_YOU_KN OW_WHAT_TO_DO_@ hotmail.com> wrote:[color=green]
> > could someone please tell me what to assume?
> > long is volatile by default?
> > yes or no?[/color]
>
> 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 - <skeet@pobox.co m>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too[/color]

[Jon Skeet [C# MVP]]

Re: use of volatile keyword

Assaf <assafwo_YOU_KN OW_WHAT_TO_DO_@ hotmail.com> wrote:[color=blue]
> i am a little confused about lock vs. volatile.
> as far as i understand,
> there is no corelation between the two concepts![/color]

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.
[color=blue]
> why do people keep refering to 'locking'
> when i am talking about 'caching' (volatile)?[/color]

Because they're intimately related.
[color=blue]
> 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![/color]

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.
[color=blue]
> in any case,
> as to your statement:
> 'No, long is not volatile by default'
> what do you base it on?[/color]

The fact that nothing is volatile by default - why would it be?
[color=blue]
> 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[/color]

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

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

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too