注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

白鸟无言

Welcome to theWraith's space

 
 
 

日志

 
 

Slim Read/Write Lock  

2009-01-06 23:15:09|  分类: 技术 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

             这些日子研究了不少关于多线程同步的实现操作,甚至恐龙书也被拿出来考了考古。关于轻量级锁,大致的结论如下:

  •         短的临界区都应该用spin的,说通俗点就是不要轻言放弃,做点无用功再回来看看能不能拿到吧
  •         上一条对于单CPU是白搭,因为你占着唯一的CPU,拿着临界区的那家伙还在等你让位呢,你怎么做无用功也是无用功啊(汗..)。这时候的正确做法就是yield去吧,放弃你剩余的CPU时间片。
  •         纯算法的同步是可行的(计算机史上巨牛Dijkstra的那篇经典论文我没完全看懂,反倒是根据他那篇文章写出的bakery算法我看的很惬意,但那东西真的能行吗....到了这个层次的东西我觉得光是理论证明不够的啊,鬼知道计算机的实现过程是真正怎么样的),但性能不行,所以还是用硬件指令去干这个活吧。

             好了,基本的spin lock实现之后,另一种很经典的资源就是读/写资源了。明显地这种情况要复杂的多,因为对于它的访问不是完全互斥的,读可以和读同时进行,但写和读、写和写是必须冲突的。看了下postgres和mysql的实现,那是完全的不一样啊....当然,一个最简单的想法也是利用硬件指令lock cmpxchg,对于read lock,检查值是否相同,若成功则加1。对于write lock,检查值是否与0相同,成功则改成-1。但是,在80X86的平台上read lock和write lock的代价相差不小的。在偶的本本上测出来,read lock指令大约需要46个ns,而write lock指令只需要29个ns。

            由于read/write lock适用于读多写少的临界区,因此可以认为read的性能就是整个lock的性能。也就是说,即使用直接的硬件指令来做,一条read/write lock的代价也是简单互斥lock的1.5倍吧。然而今天找啊找的找到了Windows Vista新搞出来的一个东东:Slim Reader/Writer (SRW) Locks

           看看它是怎么说的吧:

Slim reader/writer (SRW) locks enable the threads of a single process to access shared resources; they are optimized for speed and occupy very little memory.

Reader threads read data from a shared resource whereas writer threads write data to a shared resource. When multiple threads are reading and writing using a shared resource, exclusive locks such as a critical section or mutex can become a bottleneck if the reader threads run continuously but write operations are rare.

SRW locks provide two modes in which threads can access a shared resource:

  • Shared mode grants shared read-only access to multiple reader threads, which enables them to read data from the shared resource concurrently. If read operations exceed write operations, this concurrency increases performance and throughput compared to critical sections.
  • Exclusive mode grants read/write access to one writer thread at a time. When the lock has been acquired in exclusive mode, no other thread can access the shared resource until the writer releases the lock.

A single SRW lock can be acquired in either mode; reader threads can acquire it in shared mode whereas writer threads can acquire it in exclusive mode. There is no guarantee about the order in which threads that request ownership will be granted ownership; SRW locks are neither fair nor FIFO.

An SRW lock is the size of a pointer. The advantage is that it is fast to update the lock state. The disadvantage is that very little state information can be stored, so SRW locks cannot be acquired recursively. In addition, a thread that owns an SRW lock in shared mode cannot upgrade its ownership of the lock to exclusive mode.

  也就是说,它只占一个机器字长的空间,同时能以较高的效率来实现Read和Write。我机器是XP,所以没法测试这个东东的性能,但找了下某个微软牛人的博客,嗯,解脱了,这个SRW的性能开销仅仅是monitor的1.7倍!

Monitor

ReaderWriterLock

ReaderWriterLockSlim (No recursion support)

ReaderWriterLockSlim (recursion support)

Read

1

5

1.67

1.74

Write

1

4.71

1.71

1.77

         可以看出,原来的RW Lock相比Monitor确实性能较差,而现在的SRW也太强了点吧,只增加了这么点开销就能实现读/写的并发管理并且只占那么点空间,相比之下,mysql和pg都是把空间拿来随意挥霍的败家子啊。当然它也提到了功能有限,不能实现升级之类的(不过能支持Recursion?)。不过这也足够牛了啊,这东西出来以后,除了少数最基础的软件,还有人需要考虑并发的实现么(主要是它省不掉系统调用的开销,否则那少数基础软件也可以直接用这个玩意了,当然,仇视WINDOWS的程序员可以无视它)。微软啊微软,真是让人又爱又恨哪....
  评论这张
 
阅读(1206)| 评论(3)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017