让复用变得容易，拒绝重复。
上一节说到，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();
}
}
上述两种可能导致加锁失效的竞态条件场景，需要我们在组织代码或设计接口时精雕细琢，在很多场景下，提供线程安全的代码是很有必要的。
下一节，我们会死锁问题，即使没有加锁，也是有可能出现死锁，必须要按照一定的规范来涉及代码，才能有效的避免死锁问题。
