471,318 Members | 2,668 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,318 software developers and data experts.

How to use Volatile on field of type long ?

Hi,

i read in documentation that the c# Volatile keyword cann't be use on long
type fields. this field is use by multiple threads but i don't want the
performance overhead of lock(obj) .

What to do ?

Thanks.

Nov 29 '05 #1
10 7355
yaron wrote:
i read in documentation that the c# Volatile keyword cann't be use on long
type fields. this field is use by multiple threads but i don't want the
performance overhead of lock(obj) .

What to do ?


Have you actually measured the performance overhead of locking? In my
experience, very few applications will actually notice any significant
difference if the lock is usually uncontested.

I don't believe there *are* any alternatives in this case.

Jon

Nov 29 '05 #2
Hi,

On 32bit systems, an operation on a long (64 bit) is not guaranteed
atomic. Interlock class has overloads of Increment/Decrement that take
long param are only atomic with respect to each other (that is, as long
as Increment and Decrement are the 2 only operations you ever want to
perform on them); otherwise, you need a lock.
Solution:
- consider using int instead of long if posible
- synchronize access to the var - not much overhead if the contention
is not high

Thi - http://thith.blogspot.com

Nov 29 '05 #3
Hi All,

thanks for your quick resposne.
please let me ask you another question :

Class Player
{
private bool enable;
public bool Enable
{
get {retturn enable;}
set {enable=value;}
}
}

in a multi-threading scenario on Player instance , do i need to put a lock
statement in the Enable property or can i be relax and trust that this is an
atomic operation.
what is good to do ?

Thanks you all.
"Truong Hong Thi" wrote:
Hi,

On 32bit systems, an operation on a long (64 bit) is not guaranteed
atomic. Interlock class has overloads of Increment/Decrement that take
long param are only atomic with respect to each other (that is, as long
as Increment and Decrement are the 2 only operations you ever want to
perform on them); otherwise, you need a lock.
Solution:
- consider using int instead of long if posible
- synchronize access to the var - not much overhead if the contention
is not high

Thi - http://thith.blogspot.com

Nov 29 '05 #4
Generally, I won't put lock statement inside get and set accessors like
above because such things cannot end up in a race condition. Note that
access is not guaranteed to be synchronized, but it is often
toleratable.

Nov 29 '05 #5
is it because the get and set operations are atomic operation in this case ?
let say instead of bool property it was of type long , then would you put a
lock in the get/set methods ?

Thanks a lot.
"Truong Hong Thi" wrote:
Generally, I won't put lock statement inside get and set accessors like
above because such things cannot end up in a race condition. Note that
access is not guaranteed to be synchronized, but it is often
toleratable.

Nov 29 '05 #6
yaron wrote:
is it because the get and set operations are atomic operation in this case ?
let say instead of bool property it was of type long , then would you put a
lock in the get/set methods ?


Atomicity is rarely sufficient, frankly. Unless you don't care whether
or not one thread sees the changes another thread makes, you need to
either use locking or volatility.

See http://www.pobox.com/~skeet/csharp/t...latility.shtml

Jon

Nov 29 '05 #7
Truong Hong Thi wrote:
Generally, I won't put lock statement inside get and set accessors like
above because such things cannot end up in a race condition. Note that
access is not guaranteed to be synchronized, but it is often
toleratable.


I'm not sure what you mean by "because such things cannot end up in a
race condition" (or rather, why that would mean you *won't* put locking
in).

My own guidance is really:

1) Only make things thread-safe if they really need to be
2) Document the thread-safety thoroughly
3) If you need to be thread-safe, don't try to be clever until you know
you've got a performance problem. Using locks is a very simple way of
getting things right (if you're reasonably careful). Things like
double-checked locking are just asking for trouble.
4) Unless you need to expose something for other objects to lock on,
always lock on private references. If you need multiple locks, document
carefully what order they should be taken out in.

Jon

Nov 29 '05 #8
Thanks a lot Jon.

"Jon Skeet [C# MVP]" wrote:
Truong Hong Thi wrote:
Generally, I won't put lock statement inside get and set accessors like
above because such things cannot end up in a race condition. Note that
access is not guaranteed to be synchronized, but it is often
toleratable.


I'm not sure what you mean by "because such things cannot end up in a
race condition" (or rather, why that would mean you *won't* put locking
in).

My own guidance is really:

1) Only make things thread-safe if they really need to be
2) Document the thread-safety thoroughly
3) If you need to be thread-safe, don't try to be clever until you know
you've got a performance problem. Using locks is a very simple way of
getting things right (if you're reasonably careful). Things like
double-checked locking are just asking for trouble.
4) Unless you need to expose something for other objects to lock on,
always lock on private references. If you need multiple locks, document
carefully what order they should be taken out in.

Jon

Nov 29 '05 #9
>I'm not sure what you mean by "because such things cannot end up in a
race condition" I mean such operations are atomic. The bool cannot be partially
updated.
(or rather, why that would mean you *won't* put lockingin).

I did said access to the var is not synchronized. On multi-processor
box, one thread might not see changes made by other thread. In some
situations, that is not a problem. In situations that matters, I often
lock the call to property instead of lock inside the property. That is
whay I said "I won't".

Thi

Nov 30 '05 #10
Hi all,

let be focus on sigle processor machine 32 bits.
1. so if i understand you , then on single processor machine 32bit i don't
have to sync access to atomic get/set properties of type less then 32 bits or
do i still have to use volatile on single processor machine ?

2. does the problems you mention before optimizations/reordering/caching
makes problems with multi-threading on single processor machine 32bit ?

Thanks all.
"Truong Hong Thi" wrote:
I'm not sure what you mean by "because such things cannot end up in a
race condition"

I mean such operations are atomic. The bool cannot be partially
updated.
(or rather, why that would mean you *won't* put locking
in).

I did said access to the var is not synchronized. On multi-processor
box, one thread might not see changes made by other thread. In some
situations, that is not a problem. In situations that matters, I often
lock the call to property instead of lock inside the property. That is
whay I said "I won't".

Thi

Dec 1 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Andrew | last post: by
9 posts views Thread by Tim Rentsch | last post: by
22 posts views Thread by Assaf | last post: by
13 posts views Thread by yaron | last post: by
10 posts views Thread by Lau Lei Cheong | last post: by
18 posts views Thread by Mark | last post: by
6 posts views Thread by red floyd | last post: by
6 posts views Thread by titan nyquist | last post: by
94 posts views Thread by Samuel R. Neff | last post: by
reply views Thread by rosydwin | last post: by

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.