有没有更快的那种TMultiReadExclusiveWriteSynchronizer
?也许是 FastCode?
从 Windows Vista 开始,Microsoft 添加了Slim Reader/Writer lock。它的性能比 Delphi 的TMultiReadExclusiveWriteSynchronizer
. 不幸的是,它只存在于 Windows Vista 及更高版本中,实际上很少有客户拥有。
大概 a 中使用的概念Slim Reader/Writer lock
可以在本机 Delphi 代码中重做 - 但有人做过吗?
我有一种情况,在 a 上获取和释放锁TMultiReadExclusiveWriteSynchronizer
(即使没有争用 - 单个线程)会导致 100% 的开销(操作时间加倍)。我可以在没有锁定的情况下运行,但是我的类不再是线程安全的。
有更快的TMultiReadExclusiveWriteSynchronizer
吗?
注意:如果我使用 aTCriticalSection
我只会遭受 2% 的性能损失(尽管已知关键部分在获取成功时会很快,即当它是单线程并且没有争用时)。CS 的缺点是我失去了“多个阅读器”的能力。
测量结果
使用TMultiReadExclusiveWriteSynchronizer
相当多的时间花在里面BeginRead
and EndRead
:
然后,我将代码移植到使用 Window 自己的SlimReaderWriter 锁(一些代码重写,因为它不支持递归锁获取),并分析了结果:
TMultiReadExclusiveWriteSynchronizer
: 10,698 ns 每次迭代
10,697,772,613 ns 迭代 1,000,000 次SRWLock
: 8,802 ns 每次迭代
8,801,678,339 ns 迭代 1,000,000 次Omni Reader-Writer lock
: 8,941 ns 每次迭代
8,940,552,487 ns 迭代 1,000,000 次
使用 SRWLocks(又名 Omni 的旋转锁)时提高了 17%。
现在,我无法永久切换代码以使用Windows Vista SRWLocks,因为有一些完整的客户企业仍在使用 Windows XP。
Slim 锁只是对InterlockedCompareExchange
功能的谨慎使用;但比我能成功使用的要小心。我离窃取所涉及的 140 条机器指令还差得很远,并且已经完成了。