我在Linux上使用读/写锁，发现尝试将一个已经被读锁定的对象升级为写锁定会导致死锁。
即：
// acquire the read lock in thread 1.
pthread_rwlock_rdlock( &lock );
// make a decision to upgrade the lock in threads 1.
pthread_rwlock_wrlock( &lock ); // this deadlocks as already hold read lock.
我已阅读了man页，它非常具体。
如果调用线程在调用时持有读写锁（无论是读锁还是写锁），则可能会发生死锁。
在这种情况下，最佳的方式是如何将读锁升级为写锁。 我不想在保护变量时引入竞态条件。
我可以创建另一个互斥锁来包含释放读锁和获取写锁的过程，但是这样做似乎没有使用读写锁的意义。 我可能还不如只使用一个普通的互斥锁。
谢谢。
在以下场景中，你还需要什么比死锁更糟糕的情况？
因此，我会释放读锁，获取写锁，并再次检查是否需要进行更新。
pthread库不直接支持此操作。
作为解决方法，您可以定义一个互斥锁来保护锁定：
这样，当您尝试升级锁时，其他线程无法夺取写锁。但是，如果其他线程在您尝试升级时持有读锁，则您的线程将被阻塞。
另外，如上所述，如果两个线程同时尝试升级同一锁，则会遇到死锁：
我的CS讲座中得出的结论：无法可靠地避免死锁。针对提出的每种策略，至少有一种使用情况是不切实际的。您唯一能做的就是检测死锁条件（即如果调用失败，则会出现“EDEADLK”），并确保您的代码准备处理该情况。（如何恢复严重依赖于您的代码。）
以此方式降级不容易发生死锁¹，但降级和并发升级可能会死锁。如果只有一个线程以此方式升级该锁（并且其他线程立即需要写入锁定），那么也没有死锁的风险¹。
正如其他人所说，当您可能需要它时立即获取写锁将是另一种不容易发生死锁¹的替代方法，但可能会不必要地阻止其他读操作同时进行。
结论：取决于您的代码。
如果只读阶段很短（即足够短，以至于您可以承受在此期间阻止其他读操作），则我会选择过度的写锁方法。
如果只读阶段可能很长，并且在此期间阻止其他读取是不可接受的，请选择受互斥锁保护的锁升级，但要么将其限制为每个锁一个线程（“只有T1可以升级锁L42，但不能升级其他线程”），要么提供一种检测和恢复死锁的方法。
¹除非涉及除此锁及其互斥锁之外的资源
我认为，与其使用pthread读/写锁，不如使用Posix fcntl()。在这里，您可以轻松地从读取升级到写入，而无需任何麻烦。我们正在将其用于B树插入。一旦我们知道插入发生的节点，我们将将其升级为写锁。此外，当我们需要拆分节点时，我们将将节点、其父节点和子节点的锁从读取升级到写入。由于B树是基于文件的数据结构，因此它有助于对文件区域进行锁定。