饥饿与upgrade_lock

Question

我想使用Boost的upgrade_lock（使用this example，但我碰上一个饥饿的问题。其实我用从this post代码

，但我想一个跟上时代的讨论。我在WorkerKiller后运行400个线程。我遇到相同问题的anoneironaut，在mentionned帖子的作者。

我已经看到霍华德Hinnant（欣南特）的命题，但我真的不希望包括m矿石外部代码（此外，我无法让他编译到现在为止），并在6个月后发布的评论声明“Boost现在使用公平实现”（12年3月12日）。

的Boost 1.55 documentation指出：

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.". 

，并存入亚历山大捷列霍夫的算法是霍华德Hinnant（欣南特）会谈，所以我期望的1.55提升执行的行为像霍华德Hinnant（欣南特）的一答案，事实并非如此。它的行为与问题完全相同。

为什么我的WorkerKiller患有饥饿？

更新：将其用this code观察：

• 的Debian 64，升压1.55（二者Debian版和一个从来源汇编），与两个铛++和g ++
• Ubuntu的64位， Boost 1.54，同时有铿锵++（3.4-1ubuntu1）和g ++（4.8.1-10ubuntu9）

Answer 1

这是一个微妙的。差异涉及共享和可升级所有权的概念，以及它们在Boost中的实现。

让我们首先弄清楚共享所有权和可升级所有权的概念。 对于SharedLockable，线程必须事先决定是要更改对象（要求独占所有权）还是仅从中读取（共享所有权）。如果拥有共享所有权的线程决定要更改该对象，它首先必须释放其对该对象的共享锁，然后构造一个新的独占锁。在这两个步骤之间，线程根本不在对象上锁定任何锁。试图从已经拥有共享锁的线程构造排它锁将会死锁，因为独占锁构造函数会阻塞，直到所有共享锁被释放。

UpgradeLockable克服了这个限制，允许将共享锁升级到独占锁而不释放它。也就是说，线程始终保持对互斥锁的主动锁定，同时禁止其他线程获得排他锁。除此之外，UpgradeLockable仍允许来自SharedLockable的所有操作，前者的概念是后者的超集。 question you linked to只关心SharedLockable概念。

无论是概念，通过升压规定，需要实施是公平的。然而，是Boost对SharedLockable的最小实现，确实为您的问题引用了公平性保证。请注意，这是附加保证这个概念实际需要的内容。

不幸的是，最小的实施升级所有权，该upgrade_mutex，不给这个附加出示担保。它仍然实施共享所有权概念作为可升级所有权的要求，但由于合规实施不需要公平性，所以它们不提供。

由于pointed out by Howard in the comments，Terekhov的算法可以进行微调，以适应可升级的锁，这只是Boost实现目前不支持的。