问题标签 [scoped-lock]

C++17 引入了std::shared_mutex和std::scoped_lock. scoped_lock我现在的问题是，当它作为参数传递时，它似乎总是将共享互斥锁锁定在独占（写入器）模式，而不是在共享（读取器）模式下。在我的应用程序中，我需要dst使用来自 object 的数据更新 object src。我想锁定src共享和dst独占。src不幸的是，如果同时使用和dst切换调用另一个更新方法，这有可能导致死锁。所以我想使用std::scoped_lock.

我可以scoped_lock同时锁定src和dst独占模式，但是这种不必要的严格锁定会在其他地方产生性能回退。但是，似乎可以将src's包装shared_mutex成 astd::shared_lock并将其与 : 一起使用scoped_lock：当scoped_lock在其锁定操作期间调用try_lock()时shared_lock，后者实际上会调用try_shared_lock()' srcs shared_mutex，这就是我所需要的。

所以我的代码看起来很简单：

在另一个（避免死锁）锁卫中使用这样的（共享）锁卫是否安全？

在使用 scoped_lock 锁定两个互斥锁后，我需要从队列中执行提取的任务，问题是将任务从队列交换到另一个，然后执行它。到目前为止，这是我的起点

但我无法将任务保存到变量中以便以后执行。

当锁定在新范围内完成时，编译器是否可以重新排序锁定之前和之后的操作？

例如：

或者：

完整示例代码：

到目前为止输出稳定：

但是有没有保证它会保持稳定？

是否可以获得以下输出：

这样在两个线程中，锁下的操作都会与非同步操作重新排序。

刚刚发现这2个utils至少需要2个参数，例如2个互斥锁。

需要是这样的（来自 cppreference.com）：

至少需要 2 个参数是否有意义？设计考虑是什么，想知道更多细节。

非常感谢。

语境：

我知道std::lock_guard自从c++17与std::scoped_lock.

我也知道这std::scoped_lock是首选，因为它可以处理多个互斥体并使用与死锁避免算法相同的方式std::lock。

我对我们只有一个互斥锁的情况感兴趣，因此我们不需要关心避免死锁。

我从这个答案中读到：

你可以考虑std::lock_guard弃用。的单参数案例std::scoped_lock可以作为一种特化来实现，这样您就不必担心可能出现的性能问题。

问题：

我想知道这句话有多少是真的。

我的意思是，是否保证（按标准）使用单个互斥锁std::scoped_lock将被专门化，以便消除由于避免死锁处理而导致的任何不必要的开销？

我的想法：

在对该问题进行了一些调查后，我从cppreference中发现了以下句子：

如果给定了多个互斥锁，则使用死锁避免算法，就像 by 一样std::lock。

这可以让我们推断出这样的事情不会发生（即如果只给出一个互斥锁）。
但再一次，这只是一个假设。

从这个c++ 草案中，我没有看到任何关于这种专业化的明确提及。
我得到的唯一一句话是：

当sizeof...(MutexTypes)为1时，提供的Mutex类型应满足Cpp17BasicLockable要求。否则，每个互斥锁类型都应满足Cpp17Lockable要求。

^{（强调我的）}

我知道BasicLockable要求要求存在满足此处定义的条件lock()的功能。 另一方面，Lockable要求假定BasicLockable要求，并添加了满足其中定义的条件的功能。unlock()
try_lock()

我知道该try_lock()函数是运行std::lock.

从上面的c++草稿摘录中所述，try_lock()如果我们只给std::scoped_lock.
这是否足以推断/考虑始终定义上述专业化（并且可能表现得std::lock_guard如此）。
我会说是的，但由于我从未看到任何明确提及它，我想知道我是对的还是我错过了什么？

编辑：

我刚刚注意到我错过了这里最重要的部分：

效果pm：用初始化tie(m...)。那么如果sizeof...(MutexTypes)是0，则没有影响。否则，如果sizeof...(MutexTypes)是1，那么m.lock()。否则，lock(m...)。

^{（强调我的）}

std::lock只有当有多个给定的互斥体时才会调用它回答我的询问。我应该在问问题之前看到它...

我试图了解 scoped_lock 如何与互斥锁一起使用。我期待下面的程序会挂起，因为我_incVar通过持有互斥锁来调用，fooIncVar因为变量的范围直到函数结束。但情况似乎并非如此。我得到以下输出

怎么理解[](auto&... __m) { (__m.unlock(), ...);？我不了解...in lambda，也不知道如何以相反的顺序实现释放互斥锁。

正如@HolyBlackCat 所说，
(__m.unlock(), ...)意思是(__m1.unlock(),(__m2.unlock(), (__m3.unlock(), (...))))，但它不以相反的顺序实现解锁。

在 cppreference.com 中：

当控制离开创建 scoped_lock 对象的作用域时，scoped_lock 被破坏并以相反的顺序释放互斥锁。

我做了一个实验来确认这一点，如下所示：

那么cppreference会出错吗？

我有兴趣了解更多关于如何std::scoped_lock运作的信息。

我正在通过在关键部分周围添加互斥锁来对一些线程不安全的代码进行一些修改。

我正在使用 astd::scoped_lock来执行此操作。

到达代码行时，可能会发生两种情况std::scoped_lock lock(mutex)：

1. 互斥锁已成功锁定。这里没什么好担心的。

2. 互斥锁由另一个线程 (A) 持有。互斥锁无法锁定，可能是当前线程（B）阻塞。

关于第2点，当能够锁定互斥锁的线程再次解锁它时会发生什么？即：当线程 A 解锁互斥锁（scoped_lock超出范围）时，线程 B 会做什么？它会自动唤醒并再次尝试锁定互斥锁吗？（当线程 B 无法锁定互斥锁时，它会休眠吗？大概它不会while(1)像占用 CPU 一样处于无限循环中。）

如您所见，我对 a 的scoped_lock工作原理没有完全了解。有人能启发我吗？