ReaderWriterLock和ReaderWriterLockSlim

在今天反编译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和兼容性不得不重新创建一个新的锁，虽然作者比较倾向于去修复当前的锁。