views:

126

answers:

3

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 not guaranteed to be thread safe. If SelectNodes() and SelectSingleNode() do present problems running from multiple threads, could i use proper locking to avoid any issues? I have a WCF service set up that needs to grab a chunk of xml from a database and select some info out of this xml. I'd like to cache the xml to avoid hitting the database so often, but i'm concerned about thread safety and performance. Is there a better way to go about doing this? Thanks

A: 

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

Nestor
+2  A: 

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.

Darin Dimitrov
I won't need to modify the actual xml so i'm not concerned about writing to it, just reading from it. I'll need to lock when i create the XmlDocument and assign it to my static variable though. I'll look in to ReaderWriterLockSlim though, i'm not familiar with it.
Tallek
You should be concerned about writing because the XML document won't fill magically by itself and if by the time you are filling it someone tries to read from it ..., well he will run into a race condition.
Darin Dimitrov
+1  A: 

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.

Brian Gideon