How to use "volatile" for Int64 value?

[Lau Lei Cheong]

Hello,

I really need to use volatile System.Int64 for a .NET v1.1 program
in C#. But the compiler complains "a volatile field can not be of type
long". How to work around it? Or is there any other way to get similar
effect for Int64 type?

Another question less urging question is, why long variables can't
be used as volatile? I understand that in 32-bit arch. 64-bit operations are
not atomic, but seems that there could be locks or so applied, and for most
programmers they won't care as long as it works. (Hence would change it from
error to warning that the "volatile" is not so "volatile")

Thanks for any inputs.

Regards,
Lau Lei Cheong

 

[Jon Skeet [C# MVP]]

I really need to use volatile System.Int64 for a .NET v1.1 program
in C#.

I doubt that you do. You may need the same effects as volatile, but
that's not the same thing.

But the compiler complains "a volatile field can not be of type
long". How to work around it? Or is there any other way to get similar
effect for Int64 type?

That depends on exactly what you're trying to achieve. Could you give
more information? Usually locking every time you access or change the
variable is good enough.

Another question less urging question is, why long variables can't
be used as volatile? I understand that in 32-bit arch. 64-bit operations are
not atomic, but seems that there could be locks or so applied, and for most
programmers they won't care as long as it works. (Hence would change it from
error to warning that the "volatile" is not so "volatile")

I for one wouldn't want the compiler to be changing my code to start
automatically adding lock statements in. It's not hard to add them
yourself, and it would make the code clearer.

 

[Nick Hounsome]

Hello,

I really need to use volatile System.Int64 for a .NET v1.1 program
in C#. But the compiler complains "a volatile field can not be of type
long". How to work around it? Or is there any other way to get similar
effect for Int64 type?

You ahve answered your own question further on.

Another question less urging question is, why long variables can't
be used as volatile? I understand that in 32-bit arch. 64-bit operations
are not atomic
Correct.

, but seems that there could be locks or so applied, and for most
programmers they won't care as long as it works. (Hence would change it
from error to warning that the "volatile" is not so "volatile")

volatile has no significant performance impact and do not affect thread
sheduling whereas locks do.

If you want a lock just use your own.

object lockObj = new object();

lock(lockObj)
{
// do Int64 stuff
}

If the compiler did it it would have to create an object to act as the lock
for every variable and it would have to acquire and release the lock for
just the time of access. This fine granularity of locking performs really
badly.

 

[Lau Lei Cheong]

Thanks Jon and Nick.

So I guess I'll implement using lock. I was asking in the mind to "sniff"
the value out without impacting the worker threads' performance, but a
second thought also told me it's not possible to get the value without stop
the worker for a while. How I'll try to update at a larger time interval in
order to minimize the impact.

Thanks again.

 

[Adam Benson]

The interlocked methods may be of use to you.
Look at System.Threading.Interlocked.*

HTH,

Adam.
===========

 

[Willy Denoyette [MVP]]

Note that Interlocked methods using 64 bit values are not atomic on 32 bit
OS, so they are only thread safe on 64 bit systems.

Willy.

| The interlocked methods may be of use to you.
| Look at System.Threading.Interlocked.*
|
| HTH,
|
| Adam.
| ===========
|
| | > Thanks Jon and Nick.
| >
| > So I guess I'll implement using lock. I was asking in the mind to
"sniff"
| > the value out without impacting the worker threads' performance, but a
| > second thought also told me it's not possible to get the value without
| > stop the worker for a while. How I'll try to update at a larger time
| > interval in order to minimize the impact.
| >
| > Thanks again.
| >
| > "Nick Hounsome" <[email protected]>
| > ¼¶¼g©ó¶l¥ó·s»D:[email protected]...
| >>
| >> | >>> Hello,
| >>>
| >>> I really need to use volatile System.Int64 for a .NET v1.1
| >>> program in C#. But the compiler complains "a volatile field can not be
| >>> of type long". How to work around it? Or is there any other way to get
| >>> similar effect for Int64 type?
| >>
| >> You ahve answered your own question further on.
| >>
| >>> Another question less urging question is, why long variables
| >>> can't be used as volatile? I understand that in 32-bit arch. 64-bit
| >>> operations are not atomic
| >>
| >> Correct.
| >>
| >>>, but seems that there could be locks or so applied, and for most
| >>>programmers they won't care as long as it works. (Hence would change it
| >>>from error to warning that the "volatile" is not so "volatile")
| >>
| >> volatile has no significant performance impact and do not affect thread
| >> sheduling whereas locks do.
| >>
| >> If you want a lock just use your own.
| >>
| >> object lockObj = new object();
| >>
| >> lock(lockObj)
| >> {
| >> // do Int64 stuff
| >> }
| >>
| >> If the compiler did it it would have to create an object to act as the
| >> lock for every variable and it would have to acquire and release the
lock
| >> for just the time of access. This fine granularity of locking performs
| >> really badly.
| >>
| >>
| >
| >
|
|

 

[Lau Lei Cheong]

Yes, I've already know about those "interlock*" APIs. But if 64-bit
arithmatic operations are not atomic, I doubt parameter passing are atomic
too.

If parameter passing can be atomic, I guess I'll just wrap the whole routine
in a function and pass the values as parameter.

 

[Nick Hounsome]

Yes, I've already know about those "interlock*" APIs. But if 64-bit
arithmatic operations are not atomic, I doubt parameter passing are atomic
too.

If parameter passing can be atomic, I guess I'll just wrap the whole
routine in a function and pass the values as parameter.

Now you've completely confused everyone.
What have parameters got to do with anything?
Parameters and threads have nothing to do with each other because a
parameter is on the stack which is not shared between threads.

 

[Jon Skeet [C# MVP]]

Now you've completely confused everyone.
What have parameters got to do with anything?
Parameters and threads have nothing to do with each other because a
parameter is on the stack which is not shared between threads.

But if you use the interlocked APIs, you need to pass the variables you
want to increment/exchange/whatever by reference as parameters. I very
much suspect that that's what the previous post was referring to.

(For what it's worth though, I would expect it to work, just because
it's pointless to have the API available if it's not fit for purpose.)

Jon

 

[Nick Hounsome]

But if you use the interlocked APIs, you need to pass the variables you
want to increment/exchange/whatever by reference as parameters. I very
much suspect that that's what the previous post was referring to.

(For what it's worth though, I would expect it to work, just because
it's pointless to have the API available if it's not fit for purpose.)

But reference = pointer in the underlying implementation so there is no
problem.

 

[Willy Denoyette [MVP]]

| Nick Hounsome wrote:
| > > Yes, I've already know about those "interlock*" APIs. But if 64-bit
| > > arithmatic operations are not atomic, I doubt parameter passing are
atomic
| > > too.
| > >
| > > If parameter passing can be atomic, I guess I'll just wrap the whole
| > > routine in a function and pass the values as parameter.
| >
| > Now you've completely confused everyone.
| > What have parameters got to do with anything?
| > Parameters and threads have nothing to do with each other because a
| > parameter is on the stack which is not shared between threads.
|
| But if you use the interlocked APIs, you need to pass the variables you
| want to increment/exchange/whatever by reference as parameters. I very
| much suspect that that's what the previous post was referring to.
|
| (For what it's worth though, I would expect it to work, just because
| it's pointless to have the API available if it's not fit for purpose.)
|
| Jon
|
The API's available don't make the destinction between the OS versions you
are running your code on. That means that the operation is only guaranteed
to be atomic on 64 bit windows (64 bit CPU), also, you must properly align
the value on it's natural boundary or the functions will behave
unpredictably on MP systems, note that the latter is taken care of by the
..NET runtime.

Willy.