windows - 为什么 slim reader/writer 独占锁的性能优于共享锁？

Question

我已经使用 Windows Via C/C++ 的代码测试了 slim reader/writer lock 在 windows 7 下的性能。

结果让我感到惊讶的是，独占锁定性能优于共享锁定。这是代码和结果。

unsigned int __stdcall slim_reader_writer_exclusive(void *arg)
{
    //SRWLOCK srwLock;
    //InitializeSRWLock(&srwLock);

    for (int i = 0; i < 1000000; ++i) {
        AcquireSRWLockExclusive(&srwLock);
        g_value = 0;
        ReleaseSRWLockExclusive(&srwLock);
    }
    _endthreadex(0);
    return 0;
}

unsigned int __stdcall slim_reader_writer_shared(void *arg)
{

    int b;
    for (int i = 0; i < 1000000; ++i) {
        AcquireSRWLockShared(&srwLock);
        //b = g_value;
        g_value = 0;
        ReleaseSRWLockShared(&srwLock);
    }
    _endthreadex(0);
    return 0;
}

g_value 是一个全局 int volatile 变量。

您能否解释一下为什么会发生这种情况？

Answer 1

对于小型通用锁(如 SRWLocks，其大小只有一个指针)，这是一个非常常见的结果。

要点:如果您的代码 protected 部分非常小，以至于锁本身的开销可能占主导地位，则排他锁比共享锁更适合使用。 p>

此外，Raymond Chen 关于 g_Value 争论的论点也是正确的。如果在这两种情况下都读取而不是写入 g_Value，您可能会注意到共享锁的好处。

详细信息:

SRW 锁是使用单个指针大小的原子变量实现的，该变量可以呈现多种不同的状态，具体取决于低位的值。这些位的使用方式的描述超出了本评论的范围——状态转换的数量非常多——所以，我将仅提及您在测试中可能遇到的几个状态。

初始锁定状态: (0, ControlBits:0) -- SRW 锁定以所有位设置为 0 开始。

Shared state: (ShareCount: n, ControlBits: 1) -- 当没有冲突的独占获取并且锁被共享时，共享计数直接存储在锁变量中。

独占状态: (ShareCount: 0, ControlBits: 1) -- 当没有冲突的共享获取或独占获取时，锁设置了一个低位，没有其他。

竞争状态示例: (WaitPtr:ptr, ControlBits: 3) -- 当发生冲突时，等待锁的线程使用在等待线程上分配的数据形成一个队列堆栈。锁变量存储指向队列尾部的指针而不是共享计数。

在这个方案中，当您不知道初始状态是单次写入锁定字时尝试获取独占锁，以设置低位并检索旧值(这可以在 x86 上使用LOCK BTS 指令)。如果您成功了(在 1 线程情况下您总是会这样做)，您可以继续进入锁定区域而无需进一步操作。

尝试获取共享锁是一个更复杂的操作:您需要首先读取锁变量的初始值以确定旧的共享计数，增加您读取的共享计数，然后有条件地将更新后的值写回LOCK CMPXCHG 指令。这是一条明显更长的串行相关指令链，因此速度较慢。此外，CMPXCGH 在许多处理器上比无条件原子指令(如 LOCK BTS)慢一点。

理论上可以通过假设锁在开始时处于初始状态并首先执行 LOCK CMPXCHG 来加速锁的第一次共享获取。这将加速锁的初始共享获取(所有这些都在您的单线程情况下)，但它会显着减慢锁已经共享并且发生第二次共享获取的情况。

释放锁时会发生一组类似的发散操作，因此管理共享状态的额外成本也在 ReleaseSRWLockShared 端支付。