我正在尝试使用Boost的upgrade_lock(使用
this example,但我遇到了饥饿问题.
我实际上使用的是this post的代码,但我想要一个最新的讨论.我在WorkerKiller之后运行400个线程.我遇到了与anoneironaut完全相同的问题,anoneironaut,提到的帖子的作者.
我已经看到了Howard Hinnant提出的建议,但我真的不想包含更多的外部代码(而且我现在无法让他编译),6个月之后发表的评论称“Boost现在使用公平的实现” (12年3月12日).
Note the the lack of reader-writer priority policies in shared_mutex. This is
due to an algorithm credited to Alexander Terekhov which lets the OS decide
which thread is the next to get the lock without caring whether a unique lock or
shared lock is being sought. This results in a complete lack of reader or writer
starvation. It is simply fair.".
归功于Alexander Terekhov的算法是Howard Hinnant谈到的算法,所以我认为1.55的加速实现就像Howard Hinnant的答案一样,事实并非如此.它的行为与问题完全相同.
为什么我的WorkerKiller遭受饥饿？
更新：在this code观察到：
> Debian x64,Boost 1.55(Debian版本和源代码编译),同时包含clang和g
> Ubuntu x64,Boost 1.54,同时具有clang(3.4-1ubuntu1)和g(4.8.1-10ubuntu9)
最佳答案 这是一个微妙的.差异涉及共享和可升级所有权的概念,以及它们在Boost中的实现.
让我们首先了解共享所有权和可升级所有权的概念.
对于SharedLockable,线程必须事先决定是要更改对象(需要独占所有权)还是仅从中读取(共享所有权足够).如果具有共享所有权的线程决定它想要更改对象,则它首先必须释放其对象上的共享锁,然后构造一个新的独占锁.在这两个步骤之间,线程在对象上根本没有锁.尝试从已经拥有共享锁的线程构造独占锁将会死锁,因为独占锁构造函数将阻塞,直到释放所有共享锁.
UpgradeLockable通过允许将共享锁升级到独占锁而不释放它来克服此限制.也就是说,线程始终在互斥锁上保持活动锁定,同时禁止其他线程获得排它锁.除此之外,UpgradeLockable仍然允许来自SharedLockable的所有操作,前者的概念是后者的超集. question you linked to仅关注SharedLockable概念.
Boost所规定的概念都不要求实施是公平的.但是,shared_mutex,这是Boost对SharedLockable的最小实现确实给出了问题中引用的公平性保证.请注意,这是对概念实际需要的额外保证.
不幸的是,可升级所有权的最小实施,upgrade_mutex,并没有给予这个额外的保证.它仍然将共享所有权概念作为可升级所有权的要求实现,但由于合规性实施不需要公平性,因此它们不提供它.
截至pointed out by Howard in the comments,Terekhov的算法可以通过简单的调整来处理可升级的锁,只是Boost实现目前不支持这种情况.
