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. Fabian [1] http://msdn.microsoft.com/msdnmag/issues/05/10/MemoryModels/ (Technique 4) =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
