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.
