Which can be made moot by declaring appropriate members "volatile".
I doubt the hyper-volatility Microsoft JITs would not add the memory
barrier at the exit of the constructor. But, it would be nice to know
what's it IS doing...
On Mon, 9 Jul 2007 10:57:27 -0700, Greg Young <[EMAIL PROTECTED]>
wrote:
>"It is explicitly not a requirement that a conforming implementation
>of the CLI guarantee that all state updates
>performed within a constructor be uniformly visible before the
>constructor completes. CIL generators can
>ensure this requirement themselves by inserting appropriate calls to
>the memory barrier or volatile write
>instructions."
>
>On 7/9/07, Greg Young <[EMAIL PROTECTED]> wrote:
>> > It seems the controversial point is whether such out-of-order writes
>> > can occur with the .NET 2.0 memory model. Vance Morrison has written
>> > an article [1] where he seems to say no (in this case), so volatile
>> > (or explicit memory barrier) are not needed. Other sources (such as
>> > the MSDN articles cited) suggest to use volatile. Joe Duffy says
>> > volatile is needed on some variants.
>>
>> In conversations I have been made aware of only one place where
>> optimizations can occur and it is extremely obscure. In general the
>> x86 JIT assumes every non-local to be volatile.
>>
>>
>>
>> the code in question ...
>>
>> public static object SharedVariable
>> {
>> get
>> {
>> if (_sharedVariable == null)
>> {
>> lock (_syncRoot)
>> {
>> if (_sharedVariable == null)
>> {
>> _sharedVariable = new object();
>> }
>> }
>> }
>> return _sharedVariable;
>> }
>> }
>>
>> _sharedVariable = new object(); should only ever execute once
>> providing the monitor does what it says that it does in the spec and
>> performs a volatile write (and there is only a single write and not
>> intermediary writes) as it also includes a reorderring gaurentee. I
>> think this code is ok in any conforming memory model (the other
>> dependency is stated in 12.6.6 that a reference size write is atomic).
>>
>> Cheers,
>>
>> Greg
>>
>> On 7/9/07, Fabian Schmied <[EMAIL PROTECTED]> wrote:
>> > > This brings us to the interesting point, why is there disagreement?
>> > > This is a very clear statement that monitor is indeed a superset of
>> > > volatile.
>> >
>> > Yes, it is. But AFAIK, the problem is that the non-volatile read at
>> > the beginning of Ron's code might see the assigned _provider member
>> > before the constructor execution (or Activator.CreateInstance) has
>> > finished execution (due to reordered writes). Yes, at the end of the
>> > lock, it is as if the write had been volatile, but the non-volatile
>> > read can see the assignment before the lock is released.
>> >
>> > This is also why volatile solves the problem - I understand that if
>> > _provider is volatile, all out-of-order writes occur befor the
>> > assignment is made.
>> >
>> > It is also why the explicit memory barrier suggested by Stoyan solves
>> > the problem. Note that he does the following:
>> >
>> > I instance = Activator....
>> > Thread.MemoryBarrier(); // so that any out-of-order writes
>> > complete[1]
>> > provider_ = instance;
>> >
>> > So he ensures that all out-of-order writes finish before the
>> > non-volatile read can see the result.
>> >
>> > It seems the controversial point is whether such out-of-order writes
>> > can occur with the .NET 2.0 memory model. Vance Morrison has written
>> > an article [1] where he seems to say no (in this case), so volatile
>> > (or explicit memory barrier) are not needed. Other sources (such as
>> > the MSDN articles cited) suggest to use volatile. Joe Duffy says
>> > volatile is needed on some variants.
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
