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