Question for code snipped that I don't understand

Question

Hello,

I am trying to implement my own provider for xml site map files. Because of this I have started investigating the default Microsoft XmlSiteMapProvider via reflector and I have found a snippet that is confusing me, here it goes:

    SiteMapNode node = this._siteMapNode;
if (node != null)
{
    return node;
}
XmlDocument configDocument = this.GetConfigDocument();
lock (base._lock)
{
    **if (this._siteMapNode == null)**
    {...// more code

Okay, first we check whether the node is not null and then, when the check has passed we look it up once again. Isn't this If statement redundant? Or perhaps it has something to do with the lock ?

Answer 1

Yes, it is related to the lock. It could be that between the time of the first null check and the lock, another thread executed the same code and created the node, so that is is not null anylonger when the first thread has acquired the lock. This is important to keep in mind when you have lazy-loading static resources:

private static List<string> _someStringList;
private static object _lock = new object();
public static List<string> SomeStringList
{
    get
    {
        if (_someStringList == null)
        {
            // if more than one thread try to do this at the same time
            // it may be that the other thread has already gotten the lock
            // and is creating the object at this point
            lock (_lock)
            {
                // now we have the lock, so we check again to make
                // sure that another thread did not get here first
                if (_someStringList == null)
                {                
                    // now we know for sure that the object is not yet created, and
                    // also cannot have been created since we have the lock
                    _someStringList = new List<string>();
                }
            }
        }
        return _someStringList;
    }
}

When doing this, it is recommended that the object that you use for locking is not used for anything else, but that it is created for this single purpose.

Answer 2

Imagine what would happen if multiple threads were running through this piece of code at nearly the same time.

Both threads might reach the first null check and decide to create a new node. The lock is to make sure that only one thread gets into the second null block and gets to create the new node.

You might ask: why not lock before the first null check? The reason is that in the case where node is not null you want the code to be as fast as possible especially with multiple threads running, so you only lock the object if you expect that it is still null, and then you confirm inside the lock.

Answer 3

Yes, checking for null twice is called Double-Checked Locking. You check for null, acquire the lock and then check for null again. The idea is to reduce locking overhead because if the first null check passes, the object has already been initialized and there is no reason to go through lock/initialize steps again. You need the second null check because the object could have been initialized by a different thread in-between the first null check and the acquisition of the lock.