当有很多读卡器时，使用pthread_rwlock的效率

The efficiency of using a pthread_rwlock when there are a lot of readers

本文关键字：pthread rwlock 效率 使用 读卡器      更新时间：2023-10-16

当我查看pthread_rwlock_unlock函数的手册页时，我注意到如果调用线程没有rwlock的所有权，那么函数将返回EPERM。

由于rdlock允许多个线程获取锁，因此必须有一个数据结构（如链接或数组）来存储一个特定rwlock的ownerid。

问题来了：

rwlock的设计目的是在读操作远比写操作频繁时提高效率，但如果有大量不同的线程获得读锁，每次我调用pthread_rwlock_unlock（）时，都需要时间来确定调用线程是否是有效的所有者。这个场景的时间复杂度是多少。。

非常感谢各位：）

n.m提供了一个很好的答案。在您标记的linux实现中，您对持有锁所有权的结构的假设是错误的，与n.m所涉及的计数方法类似。

以下是/usr/include/bits/phreadtypes.h 中pthread_rwlock_t类型的编辑版本

  struct
  {
    int __lock;
    unsigned int __nr_readers;
    unsigned int __readers_wakeup;
    unsigned int __writer_wakeup;
    unsigned int __nr_readers_queued;
    unsigned int __nr_writers_queued;
    int __writer;
    int __shared;
    unsigned int __flags;
  } __data;

您可以看到计数字段。此外，pthread_rwlock_unlock.c不返回EPERM，大部分工作都围绕着检查pthread_rwlock_wrlock.c和pthread-rwlock_rdlock.c中的写入程序所有权展开。

你可以用一个小程序来测试这一点，声明并初始化一个锁，然后解锁它

因此，在这个实现中，时间复杂性似乎足够恒定，但这是通过利用您可能想过或想要使用的一些功能来获得的。

请注意，返回EPERM不需要实现。根据标准的规定，解锁他人锁的结果是未定义的。

如果锁只存储使用计数而不是拥有线程的列表，那么很容易实现O（1）。如果实现坚持检查锁的所有权，它可以让线程记住它拥有的锁。这种锁的数量通常应该很少。即使不是，通常也会按照LIFO顺序获取多个锁，因此常见的情况是由线程中的一堆拥有的锁覆盖的。

相关文章：