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

[Rodrigo Kumpera]

A better test case? Awesome! Thanks for looking into this.

We're aware of the issue so it's up to you on filing a bug.



On Thu, Jul 7, 2016 at 12:53 PM, Petros Douvantzis 
wrote:

> Hello Rodrigo,
>
> Sure you can. However this specific test does not reproduce the error in
> iOS most of the time. I will send another one that has more repetitions
> (and wraps-around the array).
>
> I should file the bug, right?
>
> Best,
>
> On Thu, Jul 7, 2016 at 6:38 PM, Rodrigo Kumpera  wrote:
>
>> Hi Petros,
>>
>> It does look like a bug in our end. We do enforce ECMA's load-acquire,
>> store-release semantics for volatiles.
>>
>> Can we integrate your test case into mono?
>>
>>
>> --
>> Rodrigo
>>
>> On Thu, Jul 7, 2016 at 11:05 AM, Petros Douvantzis 
>> wrote:
>>
>>> ​Hello Miguel,
>>>
>>> The initial code does *not *have the field marked as volatile. However,
>>> it may work in Net 2.0 because it has stronger memory guarantees than the
>>> ECMA.
>>>
>>> So, the articles continues saying "*Making the instance variable
>>> volatile can make it work*". So, *if* the field were volatile, it would
>>> work in every ECMA implementation.
>>>
>>> Also, I tried using:
>>> adb shell setprop debug.mono.env "'MONO_ENV_OPTIONS=-O=-intrins'"
>>> with no difference in the outcome.
>>>
>>> Best,
>>>
>>> On Thu, Jul 7, 2016 at 5:59 PM, Miguel de Icaza 
>>> wrote:
>>>
 Hello Petros,



 That blog post on double-check-locking explicitly states that without
 extra steps the pattern would not work.   Maybe I missed something?



 From that post:

 · Without any memory barriers, it's broken in the ECMA CLI
 specification too. It's possible that under the .NET 2.0 memory model
 (which is stronger than the ECMA spec) it's safe, but I'd rather not rely
 on those stronger semantics, especially if there's any doubt as to the
 safety. Making the instance variable volatile can make it work, as
 would explicit memory barrier calls, although in the latter case even
 experts can't agree exactly which barriers are required. I tend to try to
 avoid situations where experts don't agree what's right and what's wrong!







 *From: *Petros Douvantzis 
 *Date: *Thursday, July 7, 2016 at 3:54 AM
 *To: *"mono-devel-list@lists.ximian.com" <
 mono-devel-list@lists.ximian.com>, Miguel de Icaza <
 mig...@microsoft.com>
 *Cc: *Rodrigo Kumpera 

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



 Hello Miguel,



 I see your point. Even worse, it's a bit ambiguous of what guarantees
 does the volatile field make. For example in MSDN
 
  nothing is mentioned about fences or memory re-orders. In that sense, Mono
 is correct. However, in ECMA 335 they mention acquire-release semantics
 such as the ones in the Volatile class you mentioned.



 One this to consider is that if the Volatile field does not have these
 semantics, then* lazy initialization* that relies on a volatile field
 and a lock ( double-check locking
 
  )
 is *broken *in Mono for iOS and Android, because there is a chance
 that a half created object is viewed by another thread. The way the
 volatile field is supposed to help, is explained in this post
 
 .



 The only way to make this work right now is using the Volatile class,
 but most probably someone would expect the volatile field to work.



 Best,



 On Wed, Jul 6, 2016 at 9:24 PM, Miguel de Icaza 
 wrote:

 Hello,



 I am not convinced that this is a bug worth fixing.



 I think this requires some thinking.  While this might have been the
 intended visible behavior from C#, this predates the extensive use of C#
 beyond the x86 platform.   I believe 

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

[Petros Douvantzis]

Hello Rodrigo,

Sure you can. However this specific test does not reproduce the error in
iOS most of the time. I will send another one that has more repetitions
(and wraps-around the array).

I should file the bug, right?

Best,

On Thu, Jul 7, 2016 at 6:38 PM, Rodrigo Kumpera  wrote:

> Hi Petros,
>
> It does look like a bug in our end. We do enforce ECMA's load-acquire,
> store-release semantics for volatiles.
>
> Can we integrate your test case into mono?
>
>
> --
> Rodrigo
>
> On Thu, Jul 7, 2016 at 11:05 AM, Petros Douvantzis 
> wrote:
>
>> ​Hello Miguel,
>>
>> The initial code does *not *have the field marked as volatile. However,
>> it may work in Net 2.0 because it has stronger memory guarantees than the
>> ECMA.
>>
>> So, the articles continues saying "*Making the instance variable
>> volatile can make it work*". So, *if* the field were volatile, it would
>> work in every ECMA implementation.
>>
>> Also, I tried using:
>> adb shell setprop debug.mono.env "'MONO_ENV_OPTIONS=-O=-intrins'"
>> with no difference in the outcome.
>>
>> Best,
>>
>> On Thu, Jul 7, 2016 at 5:59 PM, Miguel de Icaza 
>> wrote:
>>
>>> Hello Petros,
>>>
>>>
>>>
>>> That blog post on double-check-locking explicitly states that without
>>> extra steps the pattern would not work.   Maybe I missed something?
>>>
>>>
>>>
>>> From that post:
>>>
>>> · Without any memory barriers, it's broken in the ECMA CLI
>>> specification too. It's possible that under the .NET 2.0 memory model
>>> (which is stronger than the ECMA spec) it's safe, but I'd rather not rely
>>> on those stronger semantics, especially if there's any doubt as to the
>>> safety. Making the instance variable volatile can make it work, as
>>> would explicit memory barrier calls, although in the latter case even
>>> experts can't agree exactly which barriers are required. I tend to try to
>>> avoid situations where experts don't agree what's right and what's wrong!
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From: *Petros Douvantzis 
>>> *Date: *Thursday, July 7, 2016 at 3:54 AM
>>> *To: *"mono-devel-list@lists.ximian.com" <
>>> mono-devel-list@lists.ximian.com>, Miguel de Icaza >> >
>>> *Cc: *Rodrigo Kumpera 
>>>
>>> *Subject: *Re: [Mono-dev] Volatile fields don't enforce acquire -
>>> release semantics like Volatile.Read() and Volatile.Write()
>>>
>>>
>>>
>>> Hello Miguel,
>>>
>>>
>>>
>>> I see your point. Even worse, it's a bit ambiguous of what guarantees
>>> does the volatile field make. For example in MSDN
>>> 
>>>  nothing is mentioned about fences or memory re-orders. In that sense, Mono
>>> is correct. However, in ECMA 335 they mention acquire-release semantics
>>> such as the ones in the Volatile class you mentioned.
>>>
>>>
>>>
>>> One this to consider is that if the Volatile field does not have these
>>> semantics, then* lazy initialization* that relies on a volatile field
>>> and a lock ( double-check locking
>>> 
>>>  )
>>> is *broken *in Mono for iOS and Android, because there is a chance that
>>> a half created object is viewed by another thread. The way the volatile
>>> field is supposed to help, is explained in this post
>>> 
>>> .
>>>
>>>
>>>
>>> The only way to make this work right now is using the Volatile class,
>>> but most probably someone would expect the volatile field to work.
>>>
>>>
>>>
>>> Best,
>>>
>>>
>>>
>>> On Wed, Jul 6, 2016 at 9:24 PM, Miguel de Icaza 
>>> wrote:
>>>
>>> Hello,
>>>
>>>
>>>
>>> I am not convinced that this is a bug worth fixing.
>>>
>>>
>>>
>>> I think this requires some thinking.  While this might have been the
>>> intended visible behavior from C#, this predates the extensive use of C#
>>> beyond the x86 platform.   I believe this is why the Volatile APIs were
>>> introduced.
>>>
>>>
>>>
>>> Consder the documentation for it:
>>>
>>>
>>>
>>> https://msdn.microsoft.com/en-us/library/gg712971(v=vs.110).aspx
>>> 

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

[Rodrigo Kumpera]

Hi Petros,

It does look like a bug in our end. We do enforce ECMA's load-acquire,
store-release semantics for volatiles.

Can we integrate your test case into mono?


--
Rodrigo

On Thu, Jul 7, 2016 at 11:05 AM, Petros Douvantzis 
wrote:

> ​Hello Miguel,
>
> The initial code does *not *have the field marked as volatile. However,
> it may work in Net 2.0 because it has stronger memory guarantees than the
> ECMA.
>
> So, the articles continues saying "*Making the instance variable volatile
> can make it work*". So, *if* the field were volatile, it would work in
> every ECMA implementation.
>
> Also, I tried using:
> adb shell setprop debug.mono.env "'MONO_ENV_OPTIONS=-O=-intrins'"
> with no difference in the outcome.
>
> Best,
>
> On Thu, Jul 7, 2016 at 5:59 PM, Miguel de Icaza 
> wrote:
>
>> Hello Petros,
>>
>>
>>
>> That blog post on double-check-locking explicitly states that without
>> extra steps the pattern would not work.   Maybe I missed something?
>>
>>
>>
>> From that post:
>>
>> · Without any memory barriers, it's broken in the ECMA CLI
>> specification too. It's possible that under the .NET 2.0 memory model
>> (which is stronger than the ECMA spec) it's safe, but I'd rather not rely
>> on those stronger semantics, especially if there's any doubt as to the
>> safety. Making the instance variable volatile can make it work, as would
>> explicit memory barrier calls, although in the latter case even experts
>> can't agree exactly which barriers are required. I tend to try to avoid
>> situations where experts don't agree what's right and what's wrong!
>>
>>
>>
>>
>>
>>
>>
>> *From: *Petros Douvantzis 
>> *Date: *Thursday, July 7, 2016 at 3:54 AM
>> *To: *"mono-devel-list@lists.ximian.com" <
>> mono-devel-list@lists.ximian.com>, Miguel de Icaza 
>> *Cc: *Rodrigo Kumpera 
>>
>> *Subject: *Re: [Mono-dev] Volatile fields don't enforce acquire -
>> release semantics like Volatile.Read() and Volatile.Write()
>>
>>
>>
>> Hello Miguel,
>>
>>
>>
>> I see your point. Even worse, it's a bit ambiguous of what guarantees
>> does the volatile field make. For example in MSDN
>> 
>>  nothing is mentioned about fences or memory re-orders. In that sense, Mono
>> is correct. However, in ECMA 335 they mention acquire-release semantics
>> such as the ones in the Volatile class you mentioned.
>>
>>
>>
>> One this to consider is that if the Volatile field does not have these
>> semantics, then* lazy initialization* that relies on a volatile field
>> and a lock ( double-check locking
>> 
>>  )
>> is *broken *in Mono for iOS and Android, because there is a chance that
>> a half created object is viewed by another thread. The way the volatile
>> field is supposed to help, is explained in this post
>> 
>> .
>>
>>
>>
>> The only way to make this work right now is using the Volatile class, but
>> most probably someone would expect the volatile field to work.
>>
>>
>>
>> Best,
>>
>>
>>
>> On Wed, Jul 6, 2016 at 9:24 PM, Miguel de Icaza 
>> wrote:
>>
>> Hello,
>>
>>
>>
>> I am not convinced that this is a bug worth fixing.
>>
>>
>>
>> I think this requires some thinking.  While this might have been the
>> intended visible behavior from C#, this predates the extensive use of C#
>> beyond the x86 platform.   I believe this is why the Volatile APIs were
>> introduced.
>>
>>
>>
>> Consder the documentation for it:
>>
>>
>>
>> https://msdn.microsoft.com/en-us/library/gg712971(v=vs.110).aspx
>> 
>>
>>
>>
>> If the language/runtime already provided this support, there would be no
>> need for these volatile methods in the first place.
>>
>>
>>
>> Miguel.
>>
>>
>>
>> *From: * on behalf of Rodrigo
>> Kumpera 
>> *Date: *Wednesday, July 6, 2016 at 1:27 PM

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

[Petros Douvantzis]

​Hello Miguel,

The initial code does *not *have the field marked as volatile. However, it
may work in Net 2.0 because it has stronger memory guarantees than the
ECMA.

So, the articles continues saying "*Making the instance variable volatile
can make it work*". So, *if* the field were volatile, it would work in
every ECMA implementation.

Also, I tried using:
adb shell setprop debug.mono.env "'MONO_ENV_OPTIONS=-O=-intrins'"
with no difference in the outcome.

Best,

On Thu, Jul 7, 2016 at 5:59 PM, Miguel de Icaza 
wrote:

> Hello Petros,
>
>
>
> That blog post on double-check-locking explicitly states that without
> extra steps the pattern would not work.   Maybe I missed something?
>
>
>
> From that post:
>
> · Without any memory barriers, it's broken in the ECMA CLI
> specification too. It's possible that under the .NET 2.0 memory model
> (which is stronger than the ECMA spec) it's safe, but I'd rather not rely
> on those stronger semantics, especially if there's any doubt as to the
> safety. Making the instance variable volatile can make it work, as would
> explicit memory barrier calls, although in the latter case even experts
> can't agree exactly which barriers are required. I tend to try to avoid
> situations where experts don't agree what's right and what's wrong!
>
>
>
>
>
>
>
> *From: *Petros Douvantzis 
> *Date: *Thursday, July 7, 2016 at 3:54 AM
> *To: *"mono-devel-list@lists.ximian.com" ,
> Miguel de Icaza 
> *Cc: *Rodrigo Kumpera 
>
> *Subject: *Re: [Mono-dev] Volatile fields don't enforce acquire - release
> semantics like Volatile.Read() and Volatile.Write()
>
>
>
> Hello Miguel,
>
>
>
> I see your point. Even worse, it's a bit ambiguous of what guarantees does
> the volatile field make. For example in MSDN
> 
>  nothing is mentioned about fences or memory re-orders. In that sense, Mono
> is correct. However, in ECMA 335 they mention acquire-release semantics
> such as the ones in the Volatile class you mentioned.
>
>
>
> One this to consider is that if the Volatile field does not have these
> semantics, then* lazy initialization* that relies on a volatile field and
> a lock ( double-check locking
> 
>  )
> is *broken *in Mono for iOS and Android, because there is a chance that a
> half created object is viewed by another thread. The way the volatile field
> is supposed to help, is explained in this post
> 
> .
>
>
>
> The only way to make this work right now is using the Volatile class, but
> most probably someone would expect the volatile field to work.
>
>
>
> Best,
>
>
>
> On Wed, Jul 6, 2016 at 9:24 PM, Miguel de Icaza 
> wrote:
>
> Hello,
>
>
>
> I am not convinced that this is a bug worth fixing.
>
>
>
> I think this requires some thinking.  While this might have been the
> intended visible behavior from C#, this predates the extensive use of C#
> beyond the x86 platform.   I believe this is why the Volatile APIs were
> introduced.
>
>
>
> Consder the documentation for it:
>
>
>
> https://msdn.microsoft.com/en-us/library/gg712971(v=vs.110).aspx
> 
>
>
>
> If the language/runtime already provided this support, there would be no
> need for these volatile methods in the first place.
>
>
>
> Miguel.
>
>
>
> *From: * on behalf of Rodrigo
> Kumpera 
> *Date: *Wednesday, July 6, 2016 at 1:27 PM
> *To: *petrakeas 
> *Cc: *"mono-devel-list@lists.ximian.com"  >
> *Subject: *Re: [Mono-dev] Volatile fields don't enforce acquire - release
> semantics like Volatile.Read() and Volatile.Write()
>
>
>
> Yes, it looks like a bug.
>
>
>
> On Wed, Jul 6, 2016 at 11:13 AM, petrakeas  wrote:
>
> According to C#  specification
> 

Re: [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  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 
> 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  wrote:
>> > 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
>> > sequence.
>> >
>> > The spec presents  an example
>> > 
>> > 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 
>> > .
>> >
>> > 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

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

[Petros Douvantzis]

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 
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  wrote:
> > 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
> > sequence.
> >
> > The spec presents  an example
> > 
>  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 
> .
> >
> > 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

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

[Alex Rønne Petersen]

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  wrote:
> 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
> sequence.
>
> The spec presents  an example
>    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   .
>
> 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
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

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

[Alex Rønne Petersen]

Hi,

Please file it for the Mono runtime, rather, as the vast majority of
our memory model related code lives in the runtime/JIT.

Regards,
Alex

On Thu, Jul 7, 2016 at 10:27 AM, Petros Douvantzis  wrote:
> Hi,
>
> I will file a bug.
>
> I think that I should file one bug int the iOS BCL libraries and one for the
> Android BCL, 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 
> 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  wrote:
>> > 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
>> > sequence.
>> >
>> > The spec presents  an example
>> > 
>> > 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 
>> > .
>> >
>> > 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

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

[Petros Douvantzis]

Hi,

I will file a bug.

I think that I should file one bug int the iOS BCL

libraries
and one for the Android BCL
,
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 
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  wrote:
> > 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
> > sequence.
> >
> > The spec presents  an example
> > 
>  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 
> .
> >
> > 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

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

[Alex Rønne Petersen]

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  wrote:
> 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
> sequence.
>
> The spec presents  an example
>    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   .
>
> 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
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

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

[Petros Douvantzis]

Hello Miguel,

I see your point. Even worse, it's a bit ambiguous of what guarantees does
the volatile field make. For example in MSDN
  nothing is
mentioned about fences or memory re-orders. In that sense, Mono is correct.
However, in ECMA 335 they mention acquire-release semantics such as the
ones in the Volatile class you mentioned.

One this to consider is that if the Volatile field does not have these
semantics, then* lazy initialization* that relies on a volatile field and a
lock ( double-check locking
 ) is *broken *in
Mono for iOS and Android, because there is a chance that a half created
object is viewed by another thread. The way the volatile field is supposed
to help, is explained in this post
.

The only way to make this work right now is using the Volatile class, but
most probably someone would expect the volatile field to work.

Best,

On Wed, Jul 6, 2016 at 9:24 PM, Miguel de Icaza 
wrote:

> Hello,
>
>
>
> I am not convinced that this is a bug worth fixing.
>
>
>
> I think this requires some thinking.  While this might have been the
> intended visible behavior from C#, this predates the extensive use of C#
> beyond the x86 platform.   I believe this is why the Volatile APIs were
> introduced.
>
>
>
> Consder the documentation for it:
>
>
>
> https://msdn.microsoft.com/en-us/library/gg712971(v=vs.110).aspx
>
>
>
> If the language/runtime already provided this support, there would be no
> need for these volatile methods in the first place.
>
>
>
> Miguel.
>
>
>
> *From: * on behalf of Rodrigo
> Kumpera 
> *Date: *Wednesday, July 6, 2016 at 1:27 PM
> *To: *petrakeas 
> *Cc: *"mono-devel-list@lists.ximian.com"  >
> *Subject: *Re: [Mono-dev] Volatile fields don't enforce acquire - release
> semantics like Volatile.Read() and Volatile.Write()
>
>
>
> Yes, it looks like a bug.
>
>
>
> On Wed, Jul 6, 2016 at 11:13 AM, petrakeas  wrote:
>
> 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
> sequence.
>
> The spec presents  an example
>  >
>  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  >
> .
>
> 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
>