ReaderWriterLock和ReaderWriterLockSlim

最新推荐文章于 2025-10-24 21:00:34 发布

原创

最新推荐文章于 2025-10-24 21:00:34 发布 · 2k 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#c# #photon #using #ReaderWriterLock #ReaderWriterLockSlim

本文探讨了ReaderWriterLockSlim与ReaderWriterLock在多线程编程中的性能差异，指出在多读少写场景下ReaderWriterLockSlim的优越性。引用了MSDN博客上的性能比较文章，并解释了为何在性能不如Monitor的情况下仍然推荐使用ReaderWriterLockSlim。另外，文章提到了ReaderWriterLockSlim引入的原因，主要是为了提供高性能的并发控制，并对现有锁设计的不满。还引用了国内作者的相关文章，展示了使用ReaderWriterLockSlim改进的ReadLock.cs和WriteLock.cs示例。

在今天反编译photon又发现了和上一篇文章的相同手法，这次的主角是ReaderWriterLockSlim，谷歌找到这篇文章：

文章一：http://blogs.msdn.com/b/pedram/archive/2007/10/07/a-performance-comparison-of-readerwriterlockslim-with-readerwriterlock.aspx

文中说到，ReaderWriterLockSlim 是net3.5众多隐藏的宝石之一，性能上,Monitor > ReaderWriterLockSlim > ReaderWriterLock ，评论有人说，既然性能比不上Monitor，为什么作者还推荐这个东东？作者在回复中澄清ReaderWriterLockSlim 应用在多线程读和少线程写的情况下。

在文章一中推荐了以下这篇文章：

文章二：http://joeduffyblog.com/2007/02/07/introducing-the-new-readerwriterlockslim-in-orcas/

文章二说到提供新的读写锁 ReaderWriterLockSlim 的原因。主要原因是提供（people could actually rely on for performance-critical code）人们可以真正依靠的决定性能的代码；其次是对现有的锁设计感到极度不安。但为了现有的API和兼容性不得不重新创建一个新的锁，虽然作者比较倾向于去修复当前的锁。

还有找到一篇国人写的文