2

我在追求一个纤细的单读多写锁，类似于 TOmniMREW，但在争用的情况下这会减少 CPU 密集度。

TOmniREW 仅使用自旋锁，因此线程将飙升至 100% 的 CPU 使用率，直到它们能够获得锁。

目前我正在使用一个关键部分，虽然它的行为效率较低（我的读者比作者多），但在争用线程的情况下会放弃它们的 CPU 时间。

在我的情况下，争用非常偶尔发生，通常是在编写器触发更复杂（冗长）的操作时，但是当它触发时，自旋锁的 CPU 使用率会飙升。

Windows SRW 实现使用类似的策略并且没有帮助（编辑：实际上在某些高争用的情况下它大约快 2-3 倍，但仍然显示问题 编辑 2： TOmniMREW 将在未来版本中使用 SRW，所以速度将是相同的）。

4

2 回答 2

1

实际上，经过更多的测试，Windows SRW 似乎确实放弃了 CPU，它这样做的时间比我在关键部分测试中看到的要多一些。

因此，Windows SRW 就是答案。

于 2013-12-09T13:05:23.980 回答
0

你读过这篇文章：Slim Reader/Writer Locks Rocks吗？它还包含对几个备选方案的简单基准项目的引用

于 2013-12-19T12:48:15.557 回答