如何防止pthreads中的读写锁定中的写入器匮乏 [英] How to prevent writer starvation in a read write lock in pthreads
问题描述
我对* nix系统上的POSIX Pthreads中的读写锁定有一些疑问，例如Linux.
我想知道读写锁定的默认偏差是什么，即，它优先于读取而不是写入，反之亦然?它是否提供一些API来更改此默认行为.
posix pthread是否提供一些api，以便我们可以更改pthread_rwlock_t来防止作家饥饿?从我已阅读的内容(如果我做错了，请纠正我)，默认实现偏向于读者线程，因此作家线程可能会面临饥饿.
我已经阅读了David Butenhof撰写的《用Posix线程编程》一书中的rw锁的示例实现.
我想知道posix pthreads如何处理作家线程的饥饿?是否有一些api可以用来设置读写锁定的属性，从而防止写入不足(我从未听说过)?还是用户必须处理这个问题?
如果您认为答案是实现定义的，那么请举个例子说明如何在Linux中完成此操作，因为这就是我想要的.
请注意，我只想要* nix系统的解决方案.不要以为我很粗鲁，但是发布一些Windows特定的代码对我来说毫无用处.
感谢大家的帮助和耐心:)
这确实取决于实现-因此，由于您是专门询问Linux的，所以我的评论是指pthreads的当前NPTL实现，该实现用于现代的glibc.
这里有两个相关但独立的问题.首先，有这种情况:
- 当前持有读取锁，正在等待写程序.一个新线程尝试获取读锁.
此处的默认操作是允许阅读器继续进行-有效地在编写器上跳过队列".但是，您可以覆盖它.如果使用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 ).您可以通过检查以下jilles发表的评论 ).
1. ……或者至少是在我2010年撰写此答案时.NPTL的最新版本要复杂得多，而且我还没有完成分析.
I have some questions regarding read-write locks in POSIX Pthreads on a *nix system, say Linux for example.
I wish to know what is the default bias for read write lock i.e does it prefer reads over writes or vice versa ? Does it provide some api to change this default behaviour.
Does posix pthread provide some api so that we could change the pthread_rwlock_t to prevent writer starvation ? From what i have read(please correct me if i am wrong), the default implementation is biased towards reader threads and so writer threads can face starvation.
I have read the sample implementation of rw lock from the book Programming with Posix threads by David Butenhof.
I wish to know how posix pthreads handle starvation of writer threads ? Is there some api using which we could set the attributes of the read write lock that would prevent write starvation (i have never heard about that) ? Or does the user have to handle this problem ?
If you think that the answer is implementation-defined then please give me example of how it's done in Linux, because thats what i am looking for.
Please note that i just want solutions for a *nix system. Don't think that i am rude, but posting some windows-specific code is useless for me.
Thank you all for your help and patience :)
This does indeed depend on the implementation - so since you have asked about Linux specifically, my comments are refer to the current NPTL implementation of pthreads, which is used in modern glibc.
There are two related, but separate, issues here. Firstly, there is this situation:
- There are read locks currently held, and writers waiting. A new thread tries to take a read lock.
The default action here is to allow the reader to proceed - effectively "jumping the queue" over the writer. You can, however, override this. If you use the pthread_rwlockattr_setkind_np() function to set the PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP flag on the attr that you pass to pthread_rwlock_init(), then your rwlock will block the reader in the above situation.
The second situation is:
- The last holder releases the lock, and there are both readers and writers waiting.
In this situation, NPTL will always wake up a writer in preference to a reader.
Taken together, the above means that if you use the PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP flag, your writers shouldn't be starved (of course, now a continuous stream of writers can starve the readers. C'est la vie). You can confirm all this by checking the sources (it's all very readable1) in pthread_rwlock_rdlock.c and pthread_rwlock_unlock.c.
Note that there is also a PTHREAD_RWLOCK_PREFER_WRITER_NP, but it appears not to have the right effect - quite possibly a bug (or possibly not - see comment by jilles below).
1. ...or at least it was, back when I wrote this answer in 2010. The latest versions of NPTL are considerably more complex and I haven't re-done the analysis.
这篇关于如何防止pthreads中的读写锁定中的写入器匮乏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
