我对* nix系统上的POSIX Pthreads中的读写锁定有一些疑问，例如Linux。
我想知道读写锁定的默认偏差是什么，即，它优先于读取而不是写入，反之亦然？它是否提供一些api来更改此默认行为。
posix pthread是否提供一些api，以便我们可以更改pthread_rwlock_t来防止作者饥饿？从我所阅读的内容（如果我错了，请纠正我），默认实现偏向于读者线程，因此作家线程可能会面临饥饿。
我已经阅读了David Butenhof撰写的《用Posix线程编程》一书中的rw lock示例实现。
我想知道posix pthreads如何处理作家线程的饥饿？是否有一些api可以用来设置读写锁定的属性，从而防止出现饥饿现象（我从未听说过）？还是用户必须处理这个问题？
如果您认为答案是实现定义的，那么请举个例子说明如何在Linux中完成它，因为这就是我想要的。
请注意，我只想要* nix系统的解决方案。 不要以为我很粗鲁，但是发布一些Windows特定的代码对我来说毫无用处。
谢谢大家的帮助和耐心:)
这确实取决于实现-因此，由于您是专门询问Linux的，所以我的评论是针对当前pgTL的NPTL实现的，该实现在现代glibc中使用。
这里有两个相关但独立的问题。首先，有这种情况：
此处的默认操作是允许阅读器继续进行- 有效地在编写器上“跳过队列”。但是，您可以覆盖它。如果您使用该pthread_rwlockattr_setkind_np()函数PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP在attr传递给的上设置标志pthread_rwlock_init()，则在上述情况下，您的rwlock将阻止阅读器。
pthread_rwlockattr_setkind_np()
PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP
attr
pthread_rwlock_init()
第二种情况是：
在这种情况下，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，但它似乎 没有 起到正确的作用-很有可能是一个错误（ _或可能没有-
PTHREAD_RWLOCK_PREFER_WRITER_NP
1. …或者至少是在我2010年撰写此答案时。NPTL的最新版本要复杂得多，而且我还没有做过分析。
