实现 unique_unlock，与 std::unique_lock 相反答案

【问题标题】：Implementing unique_unlock, the opposite of std::unique_lock实现 unique_unlock，与 std::unique_lock 相反
【发布时间】：2021-08-20 09:24:59
【问题描述】：

我有一种情况，大部分时间都需要锁定 std::mutex，除非在特定范围内。我在想应该有一个与std::unique_lock相反的情况，即在构造时解锁（）和在破坏时锁定（）。
应该很简单

template<typename M>
class unique_unlock
{
public:
    unique_unlock(M& m) : m_(m) {
        m_.unlock();
    }
    ~unique_unlock() {
        m_.lock();
    }
private:
    M& m_;
};

这种方法有什么问题吗？

【问题讨论】：

我看不到直接的问题，除非可能存在很大的死锁可能性。但这应该“通过设计”解决。我会让构造函数“显式”并删除所有其他构造函数（默认、复制、移动）并删除 operator=

标签： c++ synchronization mutex

【解决方案1】：

std::mutex::lock 被记录为抛出 std::system_error，这将导致您的 析构函数 抛出。你需要一个显式的noexcept(false) 来覆盖隐式的noexcept(true)。

这太不寻常了，您可能还应该警告您班级的用户。这似乎是一个 RAII 范围保护类，但如果此 dtor 在堆栈展开期间运行（正如 RAII 的意图），那么第二个异常将 std::terminate 程序。

【讨论】：

我想知道 std::mutex::lock() 有哪些实际的现实世界场景可以引入通用实现和通用操作系统。也许在某些极端形式的资源匮乏中。