Last post Oct 18, 2006 11:25 PM by bitmask
Oct 17, 2006 12:11 PM|vladi|LINK
Can somebody explain to me what would be the difference if I have:
1.) one struct with int declared WITHOUT volotile keyword
2.) another struct with int declared WITH volotile keyword
Then if different threads access that int. What would be the different behavior in case 1.) and 2.) ?
Oct 17, 2006 04:57 PM|Caddre|LINK
Try the thread below for all you need to know about Singleton. Hope this helps.
Oct 17, 2006 11:58 PM|vladi|LINK
Thanks, This also seems as a good description:
Oct 18, 2006 12:09 AM|Caddre|LINK
No it is not because it did not address the text below which is the core of a Singleton
(The Double-Check Locking idiom described earlier in "Multithreaded Singleton" is implemented correctly in the common language runtime.)
Try the link below for more from Microsoft because without the above C# will not be compliant. Hope this helps.
Oct 18, 2006 04:10 PM|vladi|LINK
But I think that double locking is not required for a volatile variable. It is required for a Singleton implementation I think the key sentance describing the problem was:
The variable is declared to be volatile to ensure that assignment to the instance variable completes before the instance variable can be accessed.
Oct 18, 2006 04:26 PM|Caddre|LINK
That is correct but only technically, that is the reason I gave you that thread to read with code, there are issues with just using Volatile without the CLR protection. The links below one is very long but explains the subject in detail and the second
link is by a C# MVP.
Oct 18, 2006 04:38 PM|vladi|LINK
It seems that this is the issue of just using volitile (quatation from the second article you gave):
"Note, however, that for a reference type, only the access to the variable itself is volatile - if you write to something within the instance the reference refers to, that write won't be volatile."
That's why you need a lock, but for int's it should be ok.
Oct 18, 2006 05:07 PM|Caddre|LINK
Oct 18, 2006 05:41 PM|bitmask|LINK
It's illegal to declare a struct field as volatile, so these theoretical cases wouldn't compile. :)
If you had asked the same question about a volatile / non-volatile int field, then yes the behavior could be different. Volatile is primarily used when trying to write lock-free code. It prevents the compiler and hardware from reordering reads and writes
to memory. In multi-threaded code these reorderings can give other threads a different view of memory than what we expected.
Oct 18, 2006 05:46 PM|bitmask|LINK
Reads and writes to an integer field are already atomic. You don't need volatile to change that behavior. You need volatile to prevent compiler and hardware optimizations in special cases.
Oct 18, 2006 10:28 PM|vladi|LINK
Thank you for your comments bitmask,
However you are wrong about this "It's illegal to declare a struct field as volatile, so these theoretical cases wouldn't compile. :)"
if you look in .NET 2.0 assembly (decompile it) System.Web, Version=22.214.171.124
You'll see type System.Web.Util.SafeBitVector32 - I had no problems compiling it. It loks like this:
internal struct SafeBitVector32
private volatile int _data;
internal SafeBitVector32(int data)
this._data = (int) data;
internal bool this[int bit]
return ((this._data & bit) == bit);
num1 = this._data;
num2 = num1 | bit;
num2 = num1 & ~bit;
num3 = Interlocked.CompareExchange(ref this._data, num2, num1);
while (num3 != num1);
internal bool ChangeValue(int bit, bool value)
int num1 = this._data;
num2 = num1 | bit;
num2 = num1 & ~bit;
if (num1 == num2)
int num3 = Interlocked.CompareExchange(ref this._data, num2, num1);
if (num3 == num1)
Oct 18, 2006 11:08 PM|vladi|LINK
Oct 18, 2006 11:25 PM|bitmask|LINK
You are right - I misread the question.
I thought you wanted a volatile struct, i.e:
Which gives a compiler error.
Sorry for the misunderstanding.