Kylix中的TMREWS
Kylix 1和Kylix 2中的TMultiReadExclusiveWriteSynchronizer内部是用Critical Section实现的,并且不会比使用Critical Section有任何优势。然而,它被包括进来是为了代码能够同时用于Linux和Windows。在Kylix的未来版本中,TMultiReadExclusiveWriteSynchronizer可能升级为如它在Windows下的表现一样。
在Critical Section和TMREWS之间选择
因为TMREWS已经被问题缠上了,我的建议很简单,就是避免使用它。如果你决定使用它,你应当确信它确实是更好的选择而且你已经获得了一个不再产生死锁行为的打过补丁的版本。
在大部分情况下,对TCriticalSection的恰当应用可以产生几乎一样快的效果,而且在某些情况下是更快。学会在必要的地方优化你的TCriticalSection,因为对TCriticalSection的不恰当使用将对性能产生严重的负面影响。
任何资源保护问题的关键都是使用多个资源Controller,并且让加锁区域尽可能的小。当能做到这些时,总是应当使用Critical Section,因为它是轻量的而且比TMREWS更快。总的来说,除非你能够明显的判断TMREWS的用处,总是使用Critical Section。
TMREWS类在以下条件都满足时性能更好:
1、访问包括读和写
2、读是主要的
3、加锁的时间必须被扩展开来维护,不能被分解为更小的块。
4、TMREWS类被合适地打上了补丁,并且已知工作正常了。
性能比较
如前面提到过地,Critical Section更加轻量因而速度更快。Critical Section是由操作系统实现的。操作系统是使用非常快速和精简的汇编代码来实现它们的。
TMREWS类更加复杂因而会带来更多的额外负担。它必须管理请求者的列表来合理地管理双状态的加锁机制。
为了展示这些区别,创建了一个名为ConcurrencySpeed.dpr的示例项目。它执行了三个如下的简单的肚量:
1、TCriticalSection – Enter 和 Leave
2、TMREWS – BeginRead 和 EndRead
3、TMREWS – BeginWrite 和 EndWrite
测试是在一个计数的循环中运行它们一定次数。为了测试的目的,缺省是100,000次。在我的测试中,产生了如下的结果(毫秒计):
TCriticalSection:20
TMREWS(Read Lock):150
TMREWS(Write Lock):401
自然这些测量是和机器有关的。然而,这儿它们之间的差别才是重要的,而不是确切的数字。可以明显的看出TMREWS的read lock比Critical Section慢7.5倍,而write lock要慢20倍。
还应该注意此时Critical Section只有一种结果,而TMREWS的性能在并发使用时还会下降。这儿执行的测试只是简单的在一个循环之中,没有其他的请求者在进行请求或者有已经存在锁需要TMREWS来对付。在实际的情况之中,TMREWS可能比这儿显示的数字还要慢。
上一页12345下一页