Acquire and release semantics
Hi!
Can anybody explain the meaning of "acquire semantics" and "release semantics"?
A read of a volatile field is called avolatile read. A volatile read has“acquire semantics”; that is, it is guaranteed to occur prior to any references to memory that occur after it in the instruction sequence.
A write of a volatile field is called avolatile write. A volatile write has “release semantics”; that is, it is guaranteed to happen after any memory references prior to the write instruction in the instruction sequence.
I don't understand it
Thanks in advance.
Regards.
Some processors have a "weak" memory model. This means that an write instruction may not write the value directly to RAM, but may write it to a cache to provide performance improvements. The problem with these caches is they are processor-specific, meaning on multi-processor computers on processor doesn't know what the other's have cached and reading RAM may not have the most up to date value. To avoid this problem some processor instructions have "acquire semantics" or/and "release semantics". Essentially acquire semantics means that read instruction is guaranteed to see any writes cached by any processors and release semantics means the write instruction is guaranteed to flush that write to RAM (i.e. not just to the cache).
The only architecture I know with this weak memory model is the IA-64 (Itanium), and is only an issue if you have multiple processors (never heard of an Itanium computer with one processor though); but, I haven't done much research into other architectures besides x86, x64 and IA-64.
Good explanation, really.
Then, can i use volatile instead lock or interlocked? For reference types too or also for value types?
Regards.
There are some types that you can't use "volatile" with that you can use with Interlocked. Double and Int64 are good examples, you can't declare members of those types with "volatile" but there are some Interlocked methods that work with them.
Otherwise, if all you're looking for is "acquire semantics" or "release semantics" with read and write (respectively) then yes, you can use "volatile" instead of an Interlocked method.
Interlocked methods also give you a memory barrier.
...also, "lock" gives you a memory barrier too, but does not give reads/writes within its block acquire/release semantics. If you always use "lock" with the same object around reads/writes of value members that might be used by multiple threads, you don't need "volatile" or Interlocked methods. "lock" should be your first choice, anything else is a low-lock technique and is very difficult to make thread-safe. See http://msdn.microsoft.com/msdnmag/issues/05/10/MemoryModels/ for details on that difficulty.
A lot of thanks Peter.
Low lock techniques improves performance?
Why so many techniques of the synchronization? Is confused. I know, that 'lock' is the best way, but i would like avoid declare a synchronization Object for each global value type in my code.
Regards.
