boost::unique_lock/upgrade_to_unique_lock && boost::shared_lock 可以同时存在吗？它让我担心

Posted 2023-02-21

【中文标题】boost::unique_lock/upgrade_to_unique_lock && boost::shared_lock 可以同时存在吗？它让我担心

【英文标题】：boost::unique_lock/upgrade_to_unique_lock && boost::shared_lock can exist at the same time ? it worries me

【发布时间】：2011-04-12 00:53:01

【问题描述】：

我用 boost::upgrade_to_unique_lock/unique_lock && boost::shared_lock 做了实验，场景是：

1 个写线程，它有 boost::unique_lock 存在于 boost::shared_mutex，在线程中，我 写入全局 AClass

3个读线程，每个都有 boost::shared_lock 同理 boost:;shred_mutex，他们有一个 循环读取全局 AClass

我观察到所有线程都同时持有锁（1 个唯一的，3 个共享的），它们都 运行数据访问循环。

我担心 AClass 不是线程安全的，如果我可以在不同的线程中同时进行读/写，读取可能会崩溃。即使不是AClass，我们使用原始类型，读取它们肯定不会崩溃，但数据可能是脏的，不是吗？

【问题讨论】：

你能提供一个例子来展示你观察到的行为吗？

在我的经验中，AClass 是 std::string，在读取线程中，我打印出字符串，在写入线程中，我将字符串更改为循环计数器（i），我可以看到屏幕上，字符串在不断变化。我确定“他们持有锁”是锁对象与循环在同一范围内，仅在循环上方一行。

我想我找到了问题，我自己的错，在读取线程中，我使用了无名锁，像这样： boost::shared_lock( gmutex );现在我改为 boost::shared_lock xx( gmutex );成功了！

我在这里有一个使用 shared_lock 的教程：home.roadrunner.com/~hinnant/mutexes/locking.html#Shared。此链接包含与升级区域中的 boost 不同的实现。我认为升级设计的 boost 实现较差（在链接中记录）。我还不知道您是否遇到了我的设计可以解决的问题。我发帖希望能帮助您并找出困惑所在。

这将是在编译时捕获的一个很好的错误，但我不知道如何。

【参考方案1】：

boost::shared_lock<boost::shared_mutex>(gmutex);

这不是“未命名的锁”。这将创建一个临时的shared_lock 对象，该对象锁定gmutex，然后该临时的shared_lock 对象被销毁，解锁gmutex。您需要为对象命名，使其成为变量，例如：

boost::shared_lock<boost::shared_mutex> my_awesome_lock(gmutex);

my_awesome_lock 将在声明它的块的末尾被销毁，这是您想要的行为。