我想用默认的Microsoft XmlTraceListener替换为基于文件大小限制或当前日期切换文件的监听器。我想保留默认的XmlTraceListener文件格式，以便我可以使用ServiceTraceViewer工具打开文件。基于XmlWriterTraceListener的线程安全跟踪监听器

我发现了一篇文章http://www.codeproject.com/Articles/30956/A-Rolling-XmlWriterTraceListener，但是从评论看来，即使在应用了建议的修补程序之后，此侦听器仍然存在一些不稳定性。

后来我发现微软自己实现CircularListener http://msdn.microsoft.com/en-us/library/aa395205.aspx

我想扩展它的，但发现它有

static CircularStream m_stream = null;

，无锁被访问后这个变量。在阅读http://msdn.microsoft.com/en-us/library/ms733025.aspx时，我发现即使XmlWriterTraceListener本身也不是线程安全的。 MSDN说：

因为System.Diagnostics.XmlWriterTraceListener是不是线程安全的，跟踪源可完全锁定资源输出痕迹时。当许多线程向配置为的跟踪源输出跟踪以使用此侦听器时，可能会发生资源争用，导致是一个重大性能问题。若要解决此问题，您应该实现线程安全的自定义侦听器。

所以基本上这意味着TraceListener.IsThreadSafe财产留给false为XmlWriterTraceListener，所以后来每次上级跟踪系统锁定时TRACEDATA/TraceEvent叫，是吗？

从围绕该static CircularStream m_stream和返回true形成覆盖IsThreadSafe属性增加一个锁会有任何好处吗？或者也许它会和XmlTraceListener中已经完成的事情一样？

我能做些什么来使CircularTraceListener线程安全和高效？

来源

2013-03-15 JustAMartin

您是否在多线程的默认配置中尝试过它，并确定锁定行为会导致问题？如果你想添加同步，你必须做更多的事情，而不仅仅是锁定那个变量声明。您必须锁定每次访问流。 – 2013-03-15 17:12:59

我认为CircularTraceListener基本上是有缺陷的。你已经注意到有一个staticm_stream。但更糟糕的是，当您构建一个CircularTraceListener时，它会将新流传递到基础（XmlWriterTraceListener）。这意味着虽然CircularTraceListener仅知道上一个创建的流，但该基类有可能使用多个流中的一个。当然，如果CircularTraceListener得到处理，基类将处理共享的m_stream对象。

我建议你不要基于CircularTraceListener任何东西，并从头开始。

更新：

我已经受够了的东西像log4net的和NLOG对于像循环记录更好的运气。

来源

2013-03-15 19:13:29

基于XmlWriterTraceListener的线程安全跟踪监听器

回答

更新：

相关问题