How to use Volatile on field of type long ?

[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.

 

[Jon Skeet [C# MVP]]

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

 

[Truong Hong Thi]

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

 

[Guest]

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]

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.

 

[Guest]

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.

 

[Jon Skeet [C# MVP]]

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

Jon

 

[Jon Skeet [C# MVP]]

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

 

[Guest]

Thanks a lot Jon.

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

 

[Truong Hong Thi]

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

 

[Guest]

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.