[RESOLVED] volatile fields

[RaleTheBlade]

Im pretty sure I have a firm understanding of what making a class field volatile does. But Im just looking for some confirmation other than MS's fancy smancy explanation.

Basically when you add the keyword volatile to a field, it makes that variable "auto-locking" when it is accessed. So if you have two threads trying to access the same field, one thread will wait until the other thread has finished with accessing the field before it attempts to access the field, correct? volatile is essentially the same thing as locking the field for the duration of time that it is accessed, then unlocking it when the thread is done accessing it, am I right?

[Mutant_Fruit]

Im pretty sure I have a firm understanding of what making a class field volatile does. But Im just looking for some confirmation other than MS's fancy smancy explanation.

Basically when you add the keyword volatile to a field, it makes that variable "auto-locking" when it is accessed. So if you have two threads trying to access the same field, one thread will wait until the other thread has finished with accessing the field before it attempts to access the field, correct? volatile is essentially the same thing as locking the field for the duration of time that it is accessed, then unlocking it when the thread is done accessing it, am I right?

Nope, what it basically does is ensures that every call to that variable results in an actual read of the memory address. It doesn't affect thread safety as such. To give the behaviour you want, you'd need a lock (mutex or whatever).

For example, the CLR might optimise:

bool a = MyBool;
bool b = MyBool;

into

bool a = MyBool;
bool b = a;

However if MyBool was marked with volatile, this optimisation wouldn't happen. Thats the simplest example I can think of to demonstrate the point. The idea is that if the field is 'volatile', it can change *at any stage*, so you must always read from the actual memory address.

[Twey]

It's used, for example, for memory-mapped fields. Basically, it indicates a field that can change even if not assigned to, and ensures that the compiler won't apply any optimisations that rely upon that assumption.

[RaleTheBlade]

Huh, what I got from the convoluted MSDN documentation was that it allowed an implicit "lock" of the variable whenever it was in use. Of course the MSDN documentation also states that

NotifyIcon.ShowBalloonTip(int timout)

takes a timeout argument in milliseconds, but in the example it shows

notifyIcon1.ShowBalloonTip(20);

Seems kinda hokey to me...

[Mutant_Fruit]

Huh, what I got from the convoluted MSDN documentation was that it allowed an implicit "lock" of the variable whenever it was in use.

I can definitely see how you can make that mistake. MSDN states:

The volatile modifier is usually used for a field that is accessed by multiple threads without using the lock statement to serialize access. Using the volatile modifier ensures that one thread retrieves the most up-to-date value written by another thread.

Volatile performs a completely different task to a lock statement. A lock statement guarantees that only 1 thread can operate inside the lock at any one time. The volatile keyword guarantees that you will always read *directly* from memory every time you access a variable*. So even if you are using lock, you may still need 'volatile' and vice versa.

*I think it also gives guarantees that loads/stores will not be 'optimised' by changing the order in which they're executed.

[Twey]

Of course the MSDN documentation also states that

NotifyIcon.ShowBalloonTip(int timout)

takes a timeout argument in milliseconds, but in the example it shows

notifyIcon1.ShowBalloonTip(20);

Seems kinda hokey to me...

It's obviously because MSDN readers are incredibly smart and can read a tooltip in a fiftieth of a second.

[RaleTheBlade]

It's obviously because MSDN readers are incredibly smart and can read a tooltip in a fiftieth of a second.

hahahaha... kudos. I'm marking this thread resolved, thanks for clearing it up you guys