How to use Volatile on field of type long ?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

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.
 
yaron said:
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 ?
Click to expand...

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
 
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
 
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.
 
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.
 
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.
 
yaron said:
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 ?
Click to expand...

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/threads/volatility.shtml

Jon
 
Truong said:
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.
Click to expand...

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
 
Thanks a lot Jon.

Jon Skeet said:
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
Click to expand...
 
I'm not sure what you mean by "because such things cannot end up in a
race condition"
Click to expand...
I mean such operations are atomic. The bool cannot be partially
updated.
(or rather, why that would mean you *won't* put locking
in).
Click to expand...
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
 
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.
 
Back
Top