Thread.VolatileWrite Method (Object%, Object)
Updated: May 2011
Writes a value to a field immediately, so that the value is visible to all processors in the computer.
Assembly: mscorlib (in mscorlib.dll)
Parameters
- address
- Type: System.Object%
The field to which the value is to be written.
- value
- Type: System.Object
The value to be written.
VolatileRead and VolatileWrite are for special cases of synchronization. Under normal circumstances, the C# lock statement, the Visual Basic SyncLock statement, and the Monitor class provide easier alternatives.
On a multiprocessor system, VolatileWrite ensures that a value written to a memory location is immediately visible to all processors. This might require flushing processor caches.
Even on a uniprocessor system, VolatileRead and VolatileWrite ensure that a value is read or written to memory, and not cached (for example, in a processor register). Thus, you can use them to synchronize access to a field that can be updated by another thread, or by hardware.
Calling this method affects only a single memory access. To provide effective synchronization for a field, all access to the field must use VolatileRead or VolatileWrite.
Windows 7, Windows Vista SP1 or later, Windows XP SP3, Windows XP SP2 x64 Edition, Windows Server 2008 (Server Core not supported), Windows Server 2008 R2 (Server Core supported with SP1 or later), Windows Server 2003 SP2
The .NET Framework does not support all versions of every platform. For a list of the supported versions, see .NET Framework System Requirements.
You really don't often need this; you can declare most fields 'volatile' which will make all write to them volatile writes. You can't do that to events, but the default add and remove handler are thread-safe and lock free anyway.
You might want this if you are trying to write some specific delegate into an event, replacing whatever was there before. But you still don't need this method if you are writing null (the write is atomic, and that's all you need for a null). And if you are willing to assume the CLR 2 memory model, you still don't need this: it makes all writes volatile writes anyway.
Still, if you want to molest your events in very strange (but standards-compliant!) ways, you'll want to write your own generic VolatileWrite() equivalent. It's actually quite simple:
static void VolatileWrite<T>(ref T obj, T value) where T : class { Thread.MemoryBarrier(); obj=value; }
The constraint "where T : class" is only there to ensure that the assignment will be atomic. The memory barrier ensures that any writes need to initialize the object will execute before the field is updated to point to it. It really must go before 'obj' is updated, not after, though this seems counter-intuitive.
You may notice that there's nothing here about making anything visible to all processors "immediately", actual SMP hardware doesn't really work that way, but as long as everything appears to happen in the right order, you can't tell.
The method certainly does affect more than "a single memory access", or it would be entirely useless. I expect the documentation is trying to say that it affects only a single thread; any other thread reading the value will need a volatile read to ensure it reads everything the right order too, or the volatile write may be in vain.
- 12/8/2011
- Daniel Normal Johnson
