如何防止作者在pthreads读写locking中的饥饿

我有一些关于* nix系统上的POSIX Pthreads读写锁的问题,比如Linux。

我想知道什么是读写锁的默认偏见,即它喜欢读取写入,反之亦然? 它是否提供了一些API来改变这种默认行为。

posix pthread是否提供了一些API,以便我们可以更改pthread_rwlock_t以防止作者饿死? 从我读过的(请纠正我,如果我错了),默认实现偏向读者线程,所以写作线程可能面临饥饿。

我已经阅读了由David Butenhof编写的使用Posix线程编程的书中rw锁的示例实现。

我想知道posix pthreads如何处理作家线程的饥饿? 是否有一些使用我们可以设置读写锁的属性,以防止写挨饿(我从来没有听说过)? 或者用户不得不处理这个问题?

如果你认为答案是实现定义的,那么请举例说明在Linux中是如何完成的,因为那就是我正在寻找的。

请注意,我只想要一个* nix系统的解决scheme。 不要以为我很粗鲁,但发布一些特定于Windows的代码对我来说是无用的。

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

Solutions Collecting From Web of "如何防止作者在pthreads读写locking中的饥饿"

这确实取决于实现 – 所以既然你已经问了关于Linux的具体问题,我的意见是指当前的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 ,但它似乎没有正确的效果 – 很可能是一个错误( 或者可能不是 – 见下面的jilles的评论 )。