情况是:
一个线程获得了 boost::shared_mutex 的可升级所有权并正在调用 unlock_upgrade_and_lock(),这会阻塞,因为此时其他线程拥有相同 shared_mutex 的共享所有权。
第一个线程的可升级所有权是否会阻止(阻止)其他线程在尝试“锁定共享”shared_mutex 以便所有已经共享所有权的线程最终解锁共享并保证第一个线程的独占所有权?
或者只要有另一个线程共享互斥锁,第一个线程就有可能保持阻塞?
情况是:
一个线程获得了 boost::shared_mutex 的可升级所有权并正在调用 unlock_upgrade_and_lock(),这会阻塞,因为此时其他线程拥有相同 shared_mutex 的共享所有权。
第一个线程的可升级所有权是否会阻止(阻止)其他线程在尝试“锁定共享”shared_mutex 以便所有已经共享所有权的线程最终解锁共享并保证第一个线程的独占所有权?
或者只要有另一个线程共享互斥锁,第一个线程就有可能保持阻塞?
(假设 Boost 实现模糊地模拟了 Howard Hinnant 的 WG21 提案......)
从共享所有权转换为升级所有权可防止任何新线程获取锁,因此最终所有共享所有者将释放它,并且具有升级所有权的线程可以将其转换为独占所有权。这是“升级锁”的重点,而不仅仅是共享锁和排他锁,请参阅N3427中的解释:
请注意,尝试从共享转换为独占的替代设计,而不是如图所示从共享转换为升级,将容易受到更新(写入器)饥饿的影响。这是因为只要有多个搜索器(共享锁),没有一个搜索器可以成功尝试转换为更新器。只有成功将自己注册为具有升级所有权的单线程,然后阻塞从升级到独占的转换,您才能使实现开始阻止新搜索者获得共享锁,以便最终获得独占锁现有的搜索者被清除。