c - 使用基于 futex 的锁来管理跟踪服务员的最有效方法是什么？

Question

我一直在对基于 futex 的锁使用服务员计数方法:与 futex int 相邻，有第二个 int，这是服务员竞争的服务员计数对于锁，在执行 futex 等待操作之前自动递增，并在从 futex 系统调用返回时自动递减。但是，我注意到当运行的线程数大于 cpus 数时，就无用唤醒系统调用的数量而言，这具有病态的不良特性，如下所示:

线程 A 挂起等待 futex，因此等待者计数增加，但它不会很快再次接收时间片，因为所有 cpu 都在使用中。同时，线程 B 正在快速执行临时获取和释放锁的操作。每次，它都会看到有一个服务员，因此会进行 futex 唤醒系统调用，尽管事实上线程 A 已经被发送了一个唤醒并且还没有机会运行并从服务员计数中减少自己。

有什么好的解决办法吗？我觉得发送唤醒事件的线程应该有一些安全的方法来做相当于减少服务员计数的事情(直接这样做似乎是不可能的，因为很难协商以便不会发生多次递减).如有必要，向锁定状态添加一个或多个额外的 int 字段是可以接受的。

我知道的另一种设计是放弃服务员计数，而是在原子锁定 int 本身上只有一个争用标志。按照这种方式，解锁操作会清除标志，并在发现锁定后尝试(成功或不成功)设置标志。解锁时，如果设置了标志，则执行唤醒操作。我相信这种设计避免了我遇到的问题，但它有一个不同的问题:在低竞争下，持有锁时到达的服务员将在释放锁时无条件地进行 futex 唤醒系统调用，即使没有其他服务员。也许这种设计可以与服务员计数相结合，以消除一些或所有虚假的唤醒系统调用？

Answer 1

我相信有可能让发送唤醒事件的线程执行递减，并且仍然保持准确的等待者计数。关键细节是:

• FUTEX_WAIT 返回它是否被 FUTEX_WAKE(零)或其他东西(非零)唤醒的指示。被 FUTEX_WAKE 唤醒的服务员不应该减少服务员计数(它应该假设唤醒者代表它这样做)；由于任何其他原因被唤醒的服务员应该减少计数(当然除非它立即再次等待)。

• FUTEX_WAKE 返回被唤醒的线程数:唤醒者应该将等待者计数减去这个数字。

重要的一点是双方都知道递减waiter计数的责任是否已经成功移交。

当然，细节决定成败，这个方案是否严格来说是管理服务员的最有效方式将取决于它与其他锁定方案的集成程度 - 但它确实值得考虑。