Yesterday, during yet another interview, we didn't deliver quite  the finest explanation of what an XML Namespace is. Today, we're using them to parse a Stack Overflow feed so clearly we understand them, however, if part of the question's purpose is to assess our ability to express this simple idea simply then shitehawks! #fail

Take this feed, for example, which is the RSS for a useful post on Volatile vs. Interlocked vs. lock. In order to to be able to use XPath with XDocument to retrieve the question we rely on XmlNamespaceManager.

    var xDoc = XDocument.Load("http://stackoverflow.com/feeds/question/154551");

    var xmlNamespaceManager = new XmlNamespaceManager(new NameTable());
        xmlNamespaceManager.AddNamespace("atom", "http://www.w3.org/2005/Atom");

    var postedQuestion 

        = xDoc.XPathSelectElement("/atom:feed/atom:entry/atom:summary", xmlNamespaceManager);

This is another example of Stack Overflow brilliance. The feeds are in chronological order so that we can guarantee that the first item (or entry) is the original post. Following the Volatile trail leads to a Joe Duffy post on Volatile Reads and Writes, and Timeliness. For example, he writes the C# documentation for volatile is highly misleading with reference to the following MSDN documentation:

The volatile modifier is usually used for a field that is accessed by multiple threads without using the lock statement to serialize access. Using the volatile modifier ensures that one thread retrieves the most up-to-date value written by another thread.

Unfortunately, I can't find this specific RSS item within the Technology feed and the same is true for the RSS feed for this blog. Although it's possible to score a reference to the item if it appears within the list of entries as they each have a unique ID, should the category contain too many entries then the older posts don't show up. Soon I'll show why this might matter but I digress.

One fact I forget with consistent regularity is that locks in C# and .NET for that matter are implemented using the System.Threading.Monitor class.

        static object moveCountLock = new Object();
        private int moveCount;

        private void IncrementMoveCount()
        {
            Monitor.Enter(moveCountLock);
            moveCount++;
            Monitor.Exit(moveCountLock);
        }

And if we were to place the Monitor.Exit in a Finally part of the Try/Catch then effectively it becomes the following:

        private void IncrementMoveCount()
        {
            lock (moveCountLock)
            {
                moveCount++;
            }
        }

To put this all in some context, the code above is designed to address race conditions though the MSDN article on Concurrency from which I take this summary elaborates on locks. And whilst we're discussing locks it's worth considering the volatile keyword.

For non-volatile fields, optimization techniques that reorder instructions can lead to unexpected and unpredictable results in multi-threaded programs that access fields without synchronization such as that provided by the lock-statement.

Two things worth pointing out here. It turns out the famous Double-Check Locking flaw previously requiring the volatile keyword no longer needs one. At least not if you're using C# but might as well leave it in for Mono and friends, suggests Phil Haack in: Double Check Locking and Other Premature Optimizations Can Shoot You In The Foot.

A few hours worth of reading ahead I think...