[Mono-list] Class library developers: locking issues to keepin mind
Rhys Weatherley
rweather@zip.com.au
Wed, 31 Oct 2001 21:23:14 +1000
Miguel de Icaza wrote:
> The problem was the double check, and the fact that a thread in a
> different CPU might have assigned a value to the variable on a separate
> thread, but the change is living in the other cpu's cache.
Yep. DCL's are a pain. If I may make a small suggestion,
how about doing the following in the C# library:
#if DCLSAFE
if(foo != null)
return foo;
#endif
lock(typeof(Foo))
{
if(foo != null)
return foo;
foo = new Foo();
return foo;
}
Then on systems that are known to have predictable
behaviour with respect to flushing cached values,
"DCLSAFE" can be defined and the library will have
better performance.
If someone forgets to define "DCLSAFE" when building
the library, it will fall back to the most-heavily locked
version and run correctly, albeit slowly.
Cheers,
Rhys.