ReaderWriterLockSlim是正确的选择吗？我正在为在WindowsAzure中运行的应用程序编写全局错误处理程序/记录器。当应用程序发生错误时，执行许多需要以原语方式执行的操作。我需要防止在前一个错误完成之前记录错误。同时，我想根据需要阅读日志。我最初的想法是使用Monitor/lock并且只锁定错误的写入。这样就完全不会抑制读取。不知道是不是ReaderWriterLockSlim更合适。我不能说我真的了解一种方法相对于另一种方法的价值。我应该创建一个ReaderWriterLockSlim并执行以下操作（将读取包装在EnterReadLock中）...publicstaticvoidLogError(Exceptionexception){_lock.EnterWriteLock();..._lock.ExitWriteLock();或者我应该只执行以下操作，只锁定写入部分：publicstaticvoidLogError(Exceptionexception){lock(someStaticLock){...}}任何想法/建议将不胜感激。好的，这完全取决于预期的资源争用。以下是我根据锁定的内容和数量做出的简单决定。ReaderWriterLockSlim是使用自旋锁实现的，所以如果你有一个长锁资源（在这种情况下写入文本），由于等待线程的自旋，性能会变差。也就是说，它在以下情况下是一个非常有用的工具。当您的争用是粗粒度的并且您知道争用或锁的数量很低时，锁或监视器最适合。ReaderWriterLockSlim至少比ReaderWriterLock快3-5倍。为什么不使用队列来存储异常，并在后台工作线程中吐出它们呢？然后你可以锁定每一方的入队/出队。冲突窗口可以保持相当小，如果您的日志数据的实际写入稍后出现，那也很好，因为顺序被保留了。如果需要，您可以将Exception包装在某个集合中，该集合包含项目入队时的时间戳，以便您可以适当地为它们添加时间戳。好吧，我认为你不应该在没有锁的情况下读取，因为你可以在primefaces操作的中间读取。ReaderWriterLock似乎更好，因为它保证在写入过程中没有读者可以进入。以上就是C#学习教程：ReaderWriterLockSlim是正确的选择吗？如果所有分享的内容对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
