如何防止pthread中的读写锁定中的写入者饥饿
我对* nix系统上的POSIX Pthreads中的读写锁定有一些疑问，例如Linux。
我想知道读写锁定的默认偏差是什么，即，它优先于读取而不是写入，反之亦然？它是否提供一些api来更改此默认行为。
posix
pthread是否提供一些api，以便我们可以更改pthread_rwlock_t来防止作者饥饿？从我所阅读的内容（如果我错了，请纠正我），默认实现偏向于读者线程，因此作家线程可能会面临饥饿。
我已经阅读了David Butenhof撰写的《用Posix线程编程》一书中的rw lock示例实现。
我想知道posix
pthreads如何处理作家线程的饥饿？是否有一些api可以用来设置读写锁定的属性，从而防止出现饥饿现象（我从未听说过）？还是用户必须处理这个问题？
谢谢大家的帮助和耐心:)
回答：
这确实取决于实现-因此，由于您是专门询问Linux的，所以我的评论是针对当前pgTL的NPTL实现的，该实现在现代glibc中使用。
这里有两个相关但独立的问题。首先，有这种情况：
- 当前持有读取锁，正在等待写程序。新线程尝试获取读锁。
此处的默认操作是允许阅读器继续进行-
有效地在编写器上“跳过队列”。但是，您可以覆盖它。如果您使用该pthread_rwlockattr_setkind_np()函数PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP在attr传递给的上设置标志pthread_rwlock_init()，则在上述情况下，您的rwlock将阻止阅读器。
第二种情况是：
- 最后一个持有者释放了锁，同时有读者和作家在等待。
在这种情况下，NPTL总是会优先于读者唤醒作家。
综上所述，上面的意思是如果您使用该PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP标志，那么您的作家不应该挨饿（当然，现在连续不断的作家流可以使读者挨饿
。C’est la vie
）。您可以通过检查pthread_rwlock_rdlock.c和pthread_rwlock_unlock.c中的源（都非常可读1）来确认所有这些内容。
请注意，还有一个PTHREAD_RWLOCK_PREFER_WRITER_NP，但它似乎 没有 起到正确的作用-很有可能是一个错误（ _或可能没有-
1. …或者至少是在我2010年撰写此答案时。NPTL的最新版本要复杂得多，而且我还没有做过分析。
以上是 如何防止pthread中的读写锁定中的写入者饥饿 的全部内容， 来源链接： utcz.com/qa/417079.html
