[Mono-dev] Volatile fields don't enforce acquire - release semantics like Volatile.Read() and Volatile.Write()
petrakeas at gmail.com
Wed Jul 6 15:13:25 UTC 2016
According to C# specification
• A read of a volatile field is called a volatile 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 a volatile 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
The spec presents an example
one thread writes "data" on a non volatile variable and "publishes" the
result by writing on a volatile variable that acts as a flag. The other
thread checks the volatile flag and if set, it accesses the non-volatile
variable that is now *guaranteed* to contain the data.
It seems that Mono 4.4 (the one used in Xamarin) does not enforce these
semantics or in other words does not prevent memory re-ordering in Android
and iOS that have relaxed memory models due to their CPU.
I have created an a test that reproduces the problem in iOS and Android
Program.cs <http://mono.1490590.n4.nabble.com/file/n4668111/Program.cs> .
If the access to the volatile field is replaced by Volatile.Read() and
Volatile.Write(), then no-problems occur. It seems that Volatile.Read() and
Volatile.Write() implement half fences in Mono, but the volatile keyword
Is this a bug?
View this message in context: http://mono.1490590.n4.nabble.com/Volatile-fields-don-t-enforce-acquire-release-semantics-like-Volatile-Read-and-Volatile-Write-tp4668111.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
More information about the Mono-devel-list