在新作用域中使用 unique_lock 是否相当于在共享资源工作结束时解锁调用？

我见过很多开发人员使用时的代码示例std::unique_lock在自动解锁互斥体的新范围中：

...
// do some staff
{
  std::unique_lock<std::mutex> lock(shared_resource_mutex);
  // do some actions with shared resource
}
// do some staff
...

在我看来，使用方法来实现这种行为会更好unlock from std::unique_lockAPI 是这样的：

...
// do some actions
std::unique_lock<std::mutex> lock(shared_resource_mutex);
// do some actions with shared resource
lock.unlock();
// do some actions
...

这两个代码片段等价吗？开发人员使用第一个变体的目的是什么？也许是为了强调（使用括号）无法并行执行的代码？

我想说前一种方法更安全、更一致、更容易阅读。

首先考虑安全：

void function()
{
    std::unique_lock<std::shared_mutex> lock(mtx);

    // exclusive lock stuff

    lock.unlock();

//  std::shared_lock<std::shared_mutex> lock(mtx); // whoops name in use
    std::shared_lock<std::shared_mutex> lock2(mtx);

    // read only shared lock stuff here

    lock2.unlock(); // what if I forget to do this?

    lock.lock(); // if I forgot to call lock2.unlock() undefined behavior

    // back to the exclusive stuff

    lock.unlock();  
}

如果您有不同的锁需要获取/释放并且您忘记调用unlock()那么你最终可能会尝试锁定相同的mutex twice来自同一个线程。

That is 未定义的行为因此它可能会被忽视但会引起麻烦。

如果你打电话怎么办lock() or unlock()在错误的锁变量上......（说lock2而不是lock1？）的可能性是可怕的。

一致性：

此外，并非所有锁类型都有.unlock()功能 （std::scoped_lock https://en.cppreference.com/w/cpp/thread/scoped_lock, std::lock_guard https://en.cppreference.com/w/cpp/thread/lock_guard）所以最好与您的编码风格保持一致。

更容易阅读：

还可以更轻松地查看哪些代码部分使用了锁，这使得代码推理变得更简单：

void function()
{
    {
        std::unique_lock<std::shared_mutex> lock(mtx);

        // exclusive lock stuff
    }

    {
        std::shared_lock<std::shared_mutex> lock(mtx);

        // read only shared lock stuff here
    }

    {
        std::unique_lock<std::shared_mutex> lock(mtx);

        // back to the exclusive stuff
    }
}