尝试std :: lock [_unique] std :: shared_mutex的线程是否可以被调用std :: lock_shared的线程饿死？

Question

关于std::shared_mutex和获得unique_lock 。

假设有3个线程：

• 2个读取器（尝试对std::shared_mutex进行lock_shared() ），以及
• 1个lock[_unique]() （试图lock[_unique]() std::shared_mutex ）

试图lock[_unique]()是否可能会饿死？ 例如：始终至少有一个读者拥有std::shared_lock ，而lock[_unique]()永远不会成功。

或多或少：将std::shared_mutex上的lock[_unique]()阻塞会进一步lock_shared()吗？

---

（肯定boost::upgrade_lock可以在这里工作，但是我想知道是否有任何对std::shared_mutex上裸std::unique_lock保证）

Answer 1

或多或少：将std::shared_mutex上的lock[_unique]()阻塞会进一步lock_shared()吗？

该标准未指定是否应该执行此操作，它仅说明：

效果：阻塞调用线程，直到可以为调用线程获得互斥体的共享所有权为止。

因此，是否使以后的读者在等待未决的作者后面等待，取决于实现。

如果实现要防止写程序饥饿，则可能需要在线程尝试获得唯一锁时设置“写程序等待”标志，以便以后获得共享锁的尝试将阻塞，并在唯一锁后面。 在N2406参考实现中，这是state成员中的write_entered_位。