c++ - 具有单个互斥体的 std::scoped_lock 行为

Question

上下文:

我知道自从 std::scoped_lock 出现 c++17 以来，std::lock_guard 已经被弃用了。

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

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

我从 this answer 中读到:

You can consider std::lock_guard deprecated. The single argument case of std::scoped_lock can be implemented as a specialization and such you don't have to fear about possible performance issues.

问题:

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

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

<小时/>

我的想法:

经过对这个问题的一些调查，我从cppreference中发现了以下句子:

If several mutexes are given, deadlock avoidance algorithm is used as if by std::lock.

这可以让我们推断出这样的事情不会发生，否则(即，如果只给出一个互斥体)。
但再次强调，这只是一个假设。

从这个 c++ draft 中我没有看到任何关于这种特化的明确提及。
我得到的唯一一句话是:

When sizeof...(MutexTypes) is 1, the supplied Mutex type shall meet the Cpp17BasicLockable requirements. Otherwise, each of the mutex types shall meet the Cpp17Lockable requirements.

^{(强调我的)}

我知道BasicLockable要求要求存在满足诸如定义的here等条件的lock()和unlock()函数.
另一方面，Lockable 要求假定 BasicLockable 要求，并添加满足诸如定义的 there 等条件的 try_lock() 函数.

我知道需要 try_lock() 函数才能运行 std::lock 使用的死锁避免算法。

从上述 c++ 草稿摘录中所述，如果我们仅向 std::scoped_lock 提供一个互斥锁，则不需要 try_lock() 函数。
这是否足以推断/认为上述专门化始终已定义(并且大概表现为 std::lock_guard 的行为)。
我会说是的，但由于我从未见过任何明确提及的内容，我想知道我是否是对的，或者我是否错过了什么？

<小时/>

编辑:

我刚刚注意到我错过了最重要的部分 here，其中指出:

Effects: Initializes pm with tie(m...). Then if sizeof...(MutexTypes) is 0, no effects. Otherwise if sizeof...(MutexTypes) is 1, then m.lock(). Otherwise, lock(m...).

^{(强调我的)}

这回答了我的疑问，仅当存在多个给定互斥体时才会调用 std::lock 。我应该在问问题之前就看到它......

Answer 1

当仅提供一个互斥锁时，

std::scoped_lock 需要与 std::lock_guard 表现相同。因此，对于单个互斥锁的情况有不同的要求。

这可以通过专门化来完成，也可以通过不同的内部机制来完成，只要行为相同即可。