[Mono-dev] Volatile fields don't enforce acquire - release semantics like Volatile.Read() and Volatile.Write()

[Alex Rønne Petersen]

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 <petrakeas at 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 <alex at 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 <petrakeas at 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 at lists.ximian.com
>> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>
>
> --
>
> Petros Douvantzis
>
> Co-founder
>
> Horizon Video Technologies
>
> horizon.camera
>
>