Is reading from an XmlDocument object thread safe?

Question

I was wondering if i could safely read from an XmlDocument object using SelectNodes() and SelectSingleNode() from multiple threads with no problems. MSDN says that they are

Answer 1

SelectNodes / SelectSingleNode should be safe (they only read data). Of course you need to synchronize those with any method that actually modifies the xml.

Answer 2

As you are going to write/read to/from the XML document you need to synchronize those two operations if you don't want to run into race conditions. And if you care about performance (who doesn't?) a ReaderWriterLockSlim might perform better than locking.

Answer 3

Here's the deal. If the documentation says that instance methods are not guarenteed to be threadsafe then you better take note. And if you do decide to use the class in a multithreaded scenario without the proper synchronization mechanisms then you need to be 1) aware the consequences of ignoring the documentation and 2) prepared for all of your assumptions to be invalidated on future versions of the class. This advice is valid even for methods that seem to only be reading internal state.

How do you know that SelectNodes and SelectSingleNodes do not modify an internal variable? Because if they do then they are definitely not threadsafe! Now, I happen to use Reflector to look inside and I can see that they do not modify any internal variables. But, how do you know that would not change in a future version?

Now, since we know in reality that SelectNodes and SelectSingleNodes do not modify the internal state of the class they may be safe for multithreaded operations despite the warning if and only if the following conditions apply.

• After the XmlDocument is initialized no other method besides SelectNodes or SelectSingleNode is called...ever. Because I have not examined all methods on the XmlDocument class I cannot say what ones modify the internal state of the class and which ones do not and as a result I would consider all but the 2 methods I just mentioned a possible risk to breaking down your lock free approach to using the class.
• An explicit or implicit memory barrier is created after the XmlDocument is initialized on one thread and before SelectNodes or SelectSingleNodes is called on another thread. I should note that a memory barrier will most likely be created implicitly for you as a result of getting the multithreaded environment setup. But, I can think of some subtle scenarios where this breaks down.

My advice...take the warning in the documentation literally and use the appropriate synchronization mechanisms.

Answer 4

you could also use MsXml FreeThreadedDOMDocument model instead of the classical DomDocument when you call createInstance.

Beware that according this article, FreeThreadedDOMDocument is 7x or 10x slower than classical DomDocument.