C++并发编程2——为共享数据加锁（二）

让复用变得容易，拒绝重复。

上一节说到，std::mutex并不能完全解决保护数据的问题。存在好几种情况，即使我们已经使用了互斥量，数据还是被破坏了。

• 将被保护数据暴露到互斥量作用域之外
• 被保护数据的访问接口本身就存在竞态条件（条件竞争）

不要暴露你的数据

来看下面例子：

struct protected_data
{
    char data[100];
}
class MutexTest
{
public:
    template<typename Function>
    void process(Function func)
    {
        std::lock_guard<std::mutex> guard<m_dataMutex>;        
        func(m_data); 
    }
private:
    std::mutex            m_dataMutex;
    struct protected_data m_data;    
}
struct protected_data *pData; 
void inject(Data &data)
{
    pData = &data;
}
// 即使process没有显式传出，但是还是被inject传出
// process执行完后，pData能在无锁的情况下访问数据
void Test()
{
    process(inject);
    for(int i = 0; i < 100; ++i)
    {
        pData.data[i] = i;
    }
}
std::thread mutexTestThread1(Test);
std::thread mutexTestThread2(Test);

我想不到比较好的例子来说明这个问题，上面的例子是基于C++并发编程上面改编的例子，其也能说明问题：在上锁后执行了用户定义的函数，将被保护数据传递到互斥锁作用域之外。

这个场景，mutexTestThread1解锁，mutexTestThread2上锁后，mutexTestThread2仍然无法独占被保护数据。pData总是获取到了被保护的数据，并在mutexTestThread2访问数据时修改该数据。

这种代码看起来很正常，也很不容易被发现，但是背后的错误逻辑是致命的，数据常常被莫名修改，奔溃也有可能随之而来。

切勿将受保护数据的指针或引用传递到互斥锁作用域之外，无论是函数返回值，还是存储在外部可见内存，亦或是以参数的形式传递到用户提供的函数中去。

谨慎的设计你的数据接口

来看下面例子：

std::deque<int> intDeque(1, 10);
std::stack<int> intStack(intDeque);
void Process()
{
    if(!intStack.empty())
    {
        const int value = intStack.top();
        intStack.pop();
    }
}
std::thread t1(Process);
std::thread t2(Process);

即使top()操作和pop()操作都已经上锁，也无法解决条件竞争的问题。

假设栈的实现中对数据的访问已加锁，在单线程情况下，上面程序可以无误执行，但是在多线程情况下，就有可能出现异常。调用空stack的top()是未定义行为。在多线程情况下，intStack.empty()操作获取的结果是不可靠的。

上述例子中intStack栈只有一个元素，如果线程t1和t2的执行顺序如下，就会出现未定义行为：

// example 1
t1: intStack.empty() // one element in intStack
t1: intStack.top()   // one element in intStack
t2: intStack.empty() // one element in intStack 
t1: intStack.pop()   // no element in intStack
t2: intStack.top()   // undefined behavior, intStack is empty()

即使不出现未定义行为，也有可能出现非预期行为——处理同一份数据多次：

// example 2
t1: intStack.empty() // one element in intStack
t2: intStack.empty() // one element in intStack 
t1: intStack.top()   // handle this data
t2: intStack.top()   // handle this data again

要解决上述问题，就需要接口设计上有较大的改动，最好的操作是重新设计接口

• 1、重新设计接口实现：top()接口内提供异常机制，当栈大小为零时，抛出异常
• 2、重新设计接口功能：将pop()和top()操作合并

第1种方案并不能解决example 2，所以推荐重新设计接口功能。一个线程安全的栈类定义如下：

template<typename T>
class Stack
{
private:
    std::stack<T>      m_data;
    mutable std::mutex m_mutex;
public:
    Stack(): m_data(std::stack<int>()){}
    Stack(const Stack& other)
    {
        std::lock_guard<std::mutex> lock(other.m);
        data = other.data;
    }
    Stack& operator=(const 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()) nullptr;
        const std::shared_ptr<T> 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()) return nullptr;
        value=data.top();
        data.pop();
    }
    bool empty() const
    {
        std::lock_guard<std::mutex> lock(m);
        return data.empty();
    }
};

栈操作为什么需要先top()后pop()，而不直接pop()时返回数据？这是为了防止pop()时的拷贝操作失败，导致数据丢失。

如果不重新设计接口，在使用的时候加锁也能解决这个问题：

std::mutex stackMutex;
void Process()
{
    std::lock_gurad<std::mutex> guard(statckMutex);
    if(!intStack.empty())
    {
        const int value = intStack.top();
        intStack.pop();
    }
}

上述两种可能导致加锁失效的竞态条件场景，需要我们在组织代码或设计接口时精雕细琢，在很多场景下，提供线程安全的代码是很有必要的。

下一节，我们会死锁问题，即使没有加锁，也是有可能出现死锁，必须要按照一定的规范来涉及代码，才能有效的避免死锁问题。

关注微信公众号