如何在 pthreads 的读写锁中防止写入器饥饿

Question

我对 *nix 系统上的 POSIX Pthreads 中的读写锁有一些疑问，例如 Linux。

我想知道读写锁的默认偏差是什么，即它更喜欢读而不是写，反之亦然？它是否提供了一些 api 来更改此默认行为。

posix pthread 是否提供了一些 api 以便我们可以更改 pthread_rwlock_t 以防止写入器饥饿？根据我的阅读（如果我错了，请纠正我），默认实现偏向于读取器线程，因此写入器线程可能面临饥饿。

我已经阅读了 David Butenhof 的 Programming with Posix threads 一书中的 rw lock 示例实现。

我想知道 posix pthreads 如何处理编写器线程的饥饿？是否有一些 api 可以用来设置读写锁的属性，以防止写饥饿（我从未听说过）？还是用户必须处理这个问题？

如果您认为答案是由实现定义的，那么请举例说明它是如何在 Linux 中完成的，因为这就是我要寻找的。​​strong>

请注意，我只需要 *nix 系统的解决方案。不要认为我很粗鲁，但是发布一些特定于 windows 的代码对我来说毫无用处。

感谢大家的帮助和耐心:)

Answer 1

这确实取决于实现——所以既然您专门询问了 Linux，我的 cmets 指的是当前 glibc 中使用的 pthreads 的 NPTL 实现。

这里有两个相关但独立的问题。首先，有这种情况：

• 当前持有读锁，写入器正在等待。一个新线程尝试获取读锁。

这里的默认操作是允许阅读器继续 - 有效地“跳过队列”超过编写器。但是，您可以覆盖它。如果您使用pthread_rwlockattr_setkind_np() 函数在您传递给pthread_rwlock_init() 的attr 上设置PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP 标志，那么您的rwlock 将在上述情况下阻塞阅读器。

第二种情况是：

• 最后一个持有者释放锁，同时有读写器等待。

在这种情况下，NPTL 总是会优先唤醒作者而不是读者。

综上所述，以上意味着如果你使用PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP 标志，你的作者不应该被饿死（当然，现在连续不断的作者可以饿死读者。C'est la vie)。您可以通过检查pthread_rwlock_rdlock.c 和pthread_rwlock_unlock.c 中的来源（都非常易读¹）来确认这一切。

请注意，还有一个PTHREAD_RWLOCK_PREFER_WRITER_NP，但它似乎没有具有正确的效果 - 很可能是一个错误（也可能不是 - 请参阅comment by jilles below )。

---

^{1。 ...或者至少是，当我在 2010 年写这个答案时。最新版本的 NPTL 要复杂得多，我还没有重新进行分析。}