std::scoped_lock，std::unique_lock还是std::lock_guard？

Question

从this问题中，我了解到std::scoped_lock是“std::lock_guard的一个严格的高级版本”。

从this问题中，我了解到"std::lock_guard和std::unique_lock是相同的“，除了std::unique_lock有一些额外的特性(例如。( try_lock)，以额外的开销为代价。

std::scoped_lock 与 std::unique_lock**?**相比如何？

一些相关的问题，我希望得到这个问题的答案。

std::unique_lock

• In和std::scoped_lock的区别是什么情况应该使用std::scoped_lock而不是std::unique_lock

• In什么情况应该使用std::unique_lock而不是std::scoped_lock

• Why没有实现std::unique_lock

的一些附加特性

Answer 1

这两个对象是为了不同的目的。scoped_lock用于简单的情况，即希望以无死锁的方式锁定一定数量的互斥对象。锁定单个互斥体只是锁定多个互斥锁的特例。物体是完全不动的，而且非常简单。

unique_lock提供了许多特性，其中很少有在同时锁定多个互斥时特别适用。

• 延迟锁定。延迟必须是全部或没有；要么推迟锁定所有互斥对象，要么不锁定它们。不清楚为什么要延迟锁定一系列互斥锁，因为如果其中任何一个是failed.
• Timeout锁，则必须放弃任何成功的锁。如果您希望超时100 no，这是否意味着锁定所有互斥对象的时间不应超过100 no？也就是说，如果第一个3锁立即锁定，但下一个锁需要75 is，那么如果第五个锁占用30 is？
• 采用互斥锁，是否应该将其视为超时。在一次操作中锁定多个互斥锁的全部目的是避免死锁。这是通过以全局一致的顺序锁定互斥锁来实现的。也就是说，使用std::lock等效调用锁定这些互斥对象的任何地方都将以相同的顺序锁定它们，无论发生什么。

如果其中一个互斥锁已经被锁定(因此应该采用锁)，那么它就被锁定在std::lock之外，因此您无法保证它是按照全局一致的顺序锁定的。这忽略了在指定要采用哪些互斥变量以及将哪些互斥对象指定为所有权的lock.

• Transfer (可移动的)方面存在的困难。基于类似于采用锁的原因，这对于多个互斥是一个值得怀疑的前景。防止死锁的保证只有在对std::lock的单个调用或等效的对所有感兴趣的互斥锁进行锁定时才有效。如果要移动这些scoped_lock的所有权，就很容易在代码中的某个点上有多个scoped_lock在同一个作用域中，而此时您可以一次锁定所有这些scoped_lock。这正是创建std::lock所要避免的那种死锁。

请注意，std::lock (scoped_lock功能的基础)甚至没有尝试提供任何这些特性。

是否有scoped_lock的专门化，它只使用一种提供unique_lock行为的互斥类型？好的。但这将违反scoped_lock的宗旨，即为多个互斥锁提供一个死锁安全锁。它只是意外地淘汰了lock_guard，因为它在单个互斥体的情况下具有相同的接口。

此外，具有非常不同的接口和功能的模板专门化通常效果并不好。以vector<bool>为例。