Question

I have a a set of database results that I am looping through that I want to write to XML. Essentially I have a List of vars where each var has a set of properties (i.e. List<image> with image having image.name, image.path, image.id, etc.)

I want to write each property for each image out to XML. I’m looping through the list of images in a parallel loop. This is how I have it set up:

    using(XMLWriter writer = XMLWriter.Create(outputfile)
    {
    Parallel.ForEach({
         writer.WriteStartElement("DOCUMENT");
         writer.WriteElementString("id", idvalue);
         writer.WriteElementString("name", namevalue);
         writer.WriteEndElement();

         writer.WriteStartElement("DOCUMENT");
         writer.WriteElementString("id", idvalue);
         writer.WriteElementString("path", pathvalue);
         writer.WriteEndElement();
});
    }

Nevermind the exact syntax…I’m going roughly from my head for illustration but I want to write a bunch of elements to a file. I’m wondering how the parallel threading is affecting the processing. It appears to be containing each loops iteration of writing the elements together; I half-expected there to be end elements interjected throughout the output file but that hasn’t been the case. MSDN says “Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.” but then also in reference to the WriteEndElement “closes one element and pops the corresponding namespace scope.”.

Am I just lucky so far that it appears to write everything out in order or is XmlWriter actually sort of thread-aware between WriteStartElement and WriteEndElement? I don’t really care what order the elements themselves are in as long as each element is correctly written. Is there any real documentation either way?

Answer 1

This is not thread-safe and will probably fail more clearly for larger datasets.

But you can’t expect any improvement from parallelism here. You’re writing to an I/O device and that is the bottleneck, not the CPU.

So just use a normal foreach(...)