Hi, Like this:
adb shell setprop debug.mono.env "'MONO_ENV_OPTIONS=-O=-intrins'" (with all of the quotes) Yes, runtime/JIT section. Thanks! Regards, Alex On Thu, Jul 7, 2016 at 11:20 AM, Petros Douvantzis <petrak...@gmail.com> wrote: > I ran: > adb shell setprop debug.mono.env "-O=-intrins" > > Is this correct? > > There was no difference in the outcome: When volatile keyword is used, > errors occur. When Volatile class is used, no errors were spotted. > > Should I file a bug to the Runtime/JIT section? > > Where > > On Thu, Jul 7, 2016 at 11:32 AM, Alex Rønne Petersen <a...@alexrp.com> > wrote: >> >> Hi, >> >> By the way, I would suggest trying to run the app with something like: >> >> MONO_ENV_OPTIONS="-O=-intrins" >> >> For Android, see here how to set this: >> https://developer.xamarin.com/guides/android/advanced_topics/environment/ >> >> For iOS, you'd need to set this when invoking the AOT compiler. I'm >> not really familiar with where you'd need to do this, though. >> >> This would disable the JIT's intrinsics for the various atomics / >> memory model methods in the framework. It would be good to know if >> this makes the test case work or if the result is the same, as we >> could narrow the problem down to either the JIT's intrinsics or the >> fallback C code in the runtime. >> >> 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