[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.