Outside the lock block is a different story, yes. In which case you may
need something like:
Thread.MemoryBarrier(); // flush processor-cached writes.
if (provider_ == null)
{
lock (syncLock_)
{
if (provider_ == null)
{
I instance = Activator....
provider_ = instance;
}
}
}
...not with MemoryBarrier within the synchronized block...
I think it would be more clear using Thread.VolatileRead, rather than
Thread.MemoryBarrier:
if (Thread.VolatileRead(ref provider_) == null)
{
lock (syncLock_)
{
if (provider_ == null)
{
I instance = Activator....
provider_ = instance;
}
}
}
...which was suggested in one of the referenced links, I believe.
Or, simply declare provider_ volatile.
On Mon, 9 Jul 2007 15:59:59 +0200, Fabian Schmied <[EMAIL PROTECTED]>
wrote:
>But isn't the point (and also the issue the barrier tries to solve)
>that code from outside the lock actually does access _provider in the
>double-checked locking pattern? So "nothing else can access provider
>while in the lock" seems not to be true, or is it?
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
