c++ - 使用 std::mutex 避免竞争条件

Question

我正在用 C++ 处理多线程项目，我对 std::mutex 有疑问

假设我有一个堆栈。

#include <exception>
#include <memory>
#include <mutex>
#include <stack>
struct empty_stack: std::exception
{
    const char* what() const throw();
};
template<typename T>
class threadsafe_stack
{
private:
    std::stack<T> data;
    mutable std::mutex m;
public:
    threadsafe_stack(){}
    threadsafe_stack(const threadsafe_stack& other)
    {
        std::lock_guard<std::mutex> lock(other.m);
        data=other.data;
    }
    threadsafe_stack& operator=(const threadsafe_stack&) = delete;
    void push(T new_value)
    {
        std::lock_guard<std::mutex> lock(m);
        data.push(new_value);
    }
    std::shared_ptr<T> pop()
    {
        std::lock_guard<std::mutex> lock(m);
        if(data.empty()) throw empty_stack();
        std::shared_ptr<T> const res(std::make_shared<T>(data.top()));
        data.pop();
        return res;
    }
    void pop(T& value)
    {
        std::lock_guard<std::mutex> lock(m);
        if(data.empty()) throw empty_stack();
        value=data.top();
        data.pop();
    }
    bool empty() const
    {
        std::lock_guard<std::mutex> lock(m);
        return data.empty();
    }
};

有人说使用这个栈可以避免race condition。但是我认为这里的问题是这里的互斥锁又名互斥只能确保单独的功能不在一起。例如，我可以让线程调用 push 和 pop。这些函数仍然存在竞争条件问题。

例如:

threadsafe_stack st; //global varibale for simple

void fun1(threadsafe_stack st)
{

    std::lock_guard<std::mutex> lock(m);
    st.push(t);
    t = st.pop();
    //
}

void fun2(threadsafe_stack st)
{
    std::lock_guard<std::mutex> lock(m);
    T t,t2;
    t = st.pop();
    // Do big things
    st.push(t2);

    //
}

如果一个线程fun1和fun2调用同一个栈(简单来说是全局变量)。所以它可能是一个竞争条件(？)

我认为唯一的解决方案是使用某种原子事务方式而不是直接调用 push()、pop()、empty()，我通过一个带有指向这些函数的“函数指针”的函数来调用它们，并且只有一个互斥体。

例如:

#define PUSH    0
#define POP     1
#define EMPTY   2

changeStack(int kindOfFunction, T* input, bool* isEmpty)
{
    std::lock_guard<std::mutex> lock(m);
    switch(kindOfFunction){
        case PUSH:
            push(input);
            break;
        case POP:
            input = pop();
            break;
        case EMPTY:
            isEmpty = empty();
            break;          
    }
}

我的解决方案好吗？或者我只是想得太多了，而我 friend 告诉我的第一个解决方案就足够了？还有其他解决方案吗？该解决方案可以避免像我建议的那样的“原子事务”。

Answer 1

给定的互斥锁是一个锁，可以在任何时候由一个线程持有。

如果线程 (T1) 持有 push() 中给定对象的锁另一个线程 (T2) 无法在 pop() 中获取它并且会被阻塞直到 T1 释放它。在释放 T2 的那一刻(或另一个线程也被同一个互斥锁阻塞)将被解除阻塞并允许继续。

您不需要在一个成员中完成所有的锁定和解锁。

如果它们出现在消费者代码中，您可能仍在引入竞争条件的地方是这样的结构:

if(!stack.empty()){
    auto item=stack.pop();//Guaranteed?
}

如果另一个线程T2进入pop()在线程 T1 进入 empty() 之后(上图)并在等待互斥锁时被阻塞，然后是 pop()在 T1 中可能会失败，因为 T2 “先到达那里”。 empty() 结束之间可能会发生任意数量的操作和pop()的开始在该片段中，除非其他同步正在处理它。

在这种情况下，您应该想象 T1 和 T2 字面上赛车到pop()尽管他们当然可能正在与不同的成员竞争并且仍然使彼此无效......

如果你想构建这样的代码，你通常必须添加更多的atomic 成员函数，如try_pop()它返回(比如说)一个空的 std::shared_ptr<>如果堆栈为空。

我希望这句话不会造成混淆:

Locking the object mutex inside member functions avoids race conditions between calls to those member functions but not in between calls to those member functions.

解决这个问题的最佳方法是添加“复合”函数，这些函数执行多个“逻辑”操作。这往往与良好的类设计背道而驰，在这种设计中，您设计了一组逻辑上的最少操作，而使用代码将它们组合在一起。

另一种方法是允许使用代码访问互斥体。例如公开 void lock() const;和 void unlock() cont;成员。这通常不是首选，因为 (a) 消费者代码很容易产生死锁，并且 (b) 您要么使用递归锁(及其开销)，要么再次加倍成员函数:

void pop(); //Self locking version...
void pop_prelocked(); //Caller must hold object mutex or program invalidated.

是否将它们公开为 public或 protected或不是这将使try_pop()看起来像这样:

std::shared_ptr<T> try_pop(){
    std::lock_guard<std::mutex> guard(m);
    if(empty_prelocked()){
        return std::shared_ptr<T>();
    }
    return pop_prelocked();
}

在每个成员的开头添加互斥锁并获取它只是故事的开始......

脚注:希望这能解释相互相互exlusion (mut****ex)。这里隐藏着一个关于内存障碍的完整其他主题，但如果您以这种方式使用互斥体，您现在可以将其视为实现细节...