The Monitor.Exit generated by the lock statement has an implicit memory barrier that will flush the CPU write cache at the end of the lock block. Adding a MemoryBarrier after the assignment to "instance" only guarantees that cached writes up to that point are flushed to RAM. The only thing visible by any other threads is "provider_"; exiting the lock block flushes remaining writes to RAM, in the correct order (i.e. if the write to "instance" was cached AND the write to "provider_" was cached it would flush the "instance" write first.
Right, but my concern was whether another thread could see "provider_" being assigned _before_ the lock block was left. I.e. the cached value of "provider_" being flushed to RAM before Monitor.Exit is reached. Because I was of the understanding this would make the memory barrier/volatile flag necessary. I understand this is no problem with the x86 model, and I presume it is with the "weak" ECMA/IA64 memory models. What about the "strong" 2.0 model, is it guaranteed that "provider_" won't be visible until Monitor.Exit? Or is it guaranteed that provider_ will only be flushed to RAM together with all the writes up to the assignment? Fabian =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
