Geek Answers Handbook

How “relevant” is non-XmlWriterTraceListener thread safety?

According to http://msdn.microsoft.com/en-us/library/ms733025.aspx the XmlWriterTraceListener is not thread safe. (I know that Microsoft.VisualBasic.Logging.FileLogTraceListener is there, but I think the XmlWriterTraceListener format is much readable using the Microsoft Service Trace Viewer).

However, I only use it for a desktop application with a UI thread and a maximum of 2 BackgroundWorkers using XmlWriterTraceListener as the Source Listener at the same time. How “relevant” is non-thread safety in this case, given the impact of performance? Message tracking is written relatively intimidating, i.e. Not every second.

edit: The user interface stream and background worker (s) use different TraceSources (each of them creates its own). TraceListener (FileLogTraceListener at the moment, as I was not sure about thread safety) is a static public property in the App class. I add it to TraceSources in the constructors of the classes that own TraceSource.

+4
source share
1 answer

The class Tracehas a UseGlobalLock property , which should be trueif the underlying listener (s) reports that they are not thread safe.

In other words, if you use a trace listener that is not thread safe with the class Debugor Trace, then these classes ( Trace/ Debug) the listener is handled in a thread safe way.

, , , . , , - , , -, .

, true, , , Trace.UseGlobalLock :

<configuration>
  <system.diagnostics>
    <trace useGlobalLock="false" />
  </system.diagnostics>
</configuration>

: - Trace, .

, Debug , Trace, .

Debug Trace , , , , , . , Trace.UseGlobalLock Debug.WriteXYZ.

+2

More articles:


All Articles