互斥锁和锁答案

【问题标题】：mutexes and locks互斥锁和锁
【发布时间】：2010-12-17 14:53:44
【问题描述】：

下面的两个代码示例是否等效？

Poco::ProcessHandle::PID ProcessRunner::processId() const
{
    Poco::ProcessHandle::PID pid = 0;
    mMutex.lock();
    pid = mPID;
    mMutex.unlock();
    return pid;
}

Poco::ProcessHandle::PID ProcessRunner::processId() const
{
    Poco::ScopedLock<Poco::Mutex> lock(mMutex);
    return mPID;
}

在第二个示例中：创建返回值副本后，锁是否会超出范围？如果返回的对象包含许多复制指令，这将很重要。
如果您只打算返回一个 int 值，是否需要锁？还是 int 的复制是原子操作？

【问题讨论】：

标签： c++ multithreading mutex poco-libraries

【解决方案1】：

它们是等价的。直到执行完他们的块的最后一行之后，本地人才会超出范围。所以在这种情况下，返回值副本是在锁的保护下进行的。

【讨论】：

【解决方案2】：

如果 Poco 的 ScopedLock 像 Boost 的 lock_guard 一样工作，并且 PID 分配不能抛出异常，那么第一个问题的答案是肯定的。此 ScopedLock 的目的是防止死锁。即使抛出异常，您也不能忘记解锁互斥锁。即使您“只读取一些数据”，您是否需要锁定？好吧，在这种情况下（仅访问一个 int）是一种灰色地带（最好不要这样做），但一般来说，如果您只是读取数据，您也会锁定互斥锁。

【讨论】：

我更关心操作的原子性。代码示例 2 中首先发生的是：返回值的副本还是锁的破坏？如果这不是第一个，那么它就是错误代码。
据我所知，首先返回值是“构造的”，然后所有自动对象都被破坏。
我刚刚意识到，如果一个函数返回一个局部变量，它必须在销毁它之前复制它。呵呵。
+1 表示“并且 PID 分配不能引发异常”。如果 PID 分配可以引发异常，则第二个示例仍将正确解锁互斥锁，而第一个示例将使互斥锁保持锁定状态。