Hi, I will file a bug.
I think that I should file one bug int the iOS BCL <https://bugzilla.xamarin.com/buglist.cgi?component=BCL%20Class%20Libraries&list_id=218333&product=iOS&resolution=---> libraries and one for the Android BCL <https://bugzilla.xamarin.com/buglist.cgi?component=BCL%20Class%20Libraries&list_id=218332&product=Android&resolution=--->, right? I guess the solution will be related to one another though. Best, On Thu, Jul 7, 2016 at 11:20 AM, Alex Rønne Petersen <a...@alexrp.com> wrote: > Hi, > > It is correct that the volatile keyword should result in > acquire/release barriers as a result of compiling down to > Thread.VolatileRead () / VolatileWrite () calls. In theory, the only > difference between the Thread and Volatile methods is that the > Volatile methods will actually be atomic for 64-bit quantities on a > 32-bit machine, where the Thread methods will not (incidentally, this > is why the volatile keyword is not allowed on 64-bit types). But since > you're using a 32-bit value, this shouldn't matter. So the fact that > switching the code to the Volatile methods makes it work is very > strange indeed. > > Could you file a bug with the test case you provided? > > Regards, > Alex > > On Wed, Jul 6, 2016 at 5:13 PM, petrakeas <petrak...@gmail.com> wrote: > > According to C# specification > > <https://msdn.microsoft.com/en-us/library/ms228593.aspx> : > > > > • 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 > > sequence. > > > > The spec presents an example > > <https://msdn.microsoft.com/en-us/library/aa645755(v=vs.71).aspx> > where > > 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 > > does not. > > > > 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. > > _______________________________________________ > > Mono-devel-list mailing list > > Mono-devel-list@lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > -- Petros Douvantzis Co-founder Horizon Video Technologies horizon.camera
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
