上一篇文章我们讲到如何启动一些线程去并发地执行某些操作，虽然那些在线程里执行的代码都是独立的，但通常情况下，你都会在这些线程之间使用到共享数据。一旦你这么做了，就面临着一个新的问题 —— 同步。
下面让我们用示例来阐释“同步”是个什么问题。
同步问题
我们就拿一个简单的计数器作为示例吧。这个计数器是一个结构体，他拥有一个计数变量，以及增加或减少计数的函数，看起来像这个样子：
[译注：原文 Counter 的 value 并未初始化，其初始值随机，读者可自行初始化为 0 ]
|
1
2
3
4
5
6
|
struct
Counter {
int
value;
void
increment(){
++value;
}
};
|
这并没什么稀奇的，下面让我们来启动一些线程来增加计数器的计数吧。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
int
main(){
Counter counter;
std::vector<std::thread> threads;
for(int
i = 0; i < 5; ++i){
threads.push_back(std::thread([&counter](){
for(int
i = 0; i < 100; ++i){
counter.increment();
}
}));
}
for(auto&
thread
: threads){
thread.join();
}
std::cout << counter.value << std::endl;
return
0;
}
|
[译注：bill的测试环境下，上述代码始终输出 500，读者可将外层 for 循环条件改为 i < 100，内层for 循环条件改为 i < 99999 以观察实验结果]
同样的，也没什么新花样，我们只是启动了 5 个线程，每个线程都让计数器增加 100 次而已。等这一工作结束，我们就打印计数器最后的数值。
如果运行这一程序，我们理所当然的期望运行结果是 500，但事与愿违，没人能保证这个程序最终输出什么。下面是在我的机器上得到的一些结果：
|
1
2
3
4
5
6
|
442
500
477
400
422
487
|
问题的根源在于计数器的 increment() 并非原子操作，而是由 3 个独立的操作组成的：
1. 读取 value 变量的当前值。
2. 将读取的当前值加 1。
3. 将加 1 后的值写回 value 变量。
当你以单线程运行上述代码时，就不会出现任何问题，上述三个步骤会按照顺序依次执行。但是一旦你身处多线程环境，情况就会变得糟糕起来，考虑如下执行顺序：
1. 线程a：读取 value 的当前值，得到值为 0。加1。因此 value = 1。[译注：此时 1 并没有写回value 内存，原文“value = 1”仅作逻辑意义，下同]
2. 线程b：读取 value 的当前值，得到值为 0。加1。因此 value = 1。
3. 线程a：将 1 写回 value 内存并返回 1。
4. 线程b：将 1 写回 value 内存并返回 1。
这种情况源于线程间的 interleaving。Interleaving 描述了多线程同时执行几句代码的各种情况。就算仅仅只有两个线程同时执行这三个操作，也会存在很多可能的 interleaving。当你有许多线程同时执行多个操作时，要想枚举出所有 interleaving，几乎是不可能的。而且如果线程在执行单个操作的不同指令之间被抢占，也会导致 interleaving 的发生。
目前有许多可以解决这一问题的方案：
-
Semaphores
-
Atomic references
-
Monitors
-
Condition codes
-
Compare and swap
-
etc.
就本文而言，我们将学习如何使用 Semaphores 去解决这一问题。事实上，我们仅仅使用了Semaphores 中比较特殊的一种 —— 互斥量。互斥量是一个特殊的对象，在同一时刻只有一个线程能够得到该对象上的锁。借助互斥量这种简而有力的性质，我们便可以解决线程同步问题。
使用互斥量保证 Counter 的线程安全
在 C++11 的线程库中，互斥量被放置于头文件 <mutex>，并以 std::mutex 类加以实现。互斥量有两个重要的函数：lock() 和 unlock()。顾名思义，前者使当前线程尝试获取互斥量的锁，后者则释放已经获取的锁。lock() 函数是阻塞式的，线程一旦调用 lock()，就会一直阻塞直到该线程获得对应的锁。
为了使我们的计数器具备线程安全性，我们需要对其添加 std::mutex 成员，并在成员函数中对互斥量进行 lock()/unlock() 调用。
|
1
2
3
4
5
6
7
8
9
10
|
struct
Counter {
std::mutex mutex;
int
value;
Counter() : value(0) {}
void
increment(){
mutex.lock();
++value;
mutex.unlock();
}
};
|
如果我们现在再次运行之前的测试程序，我们将始终得到正确的输出：500。
异常与锁
现在让我们来看看另外一种情况会发生什么。假设现在我们的计数器拥有一个 derement() 操作，当 value 被减为 0 时抛出一个异常：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
struct
Counter {
int
value;
Counter() : value(0) {}
void
increment(){
++value;
}
void
decrement(){
if(value == 0){
throw
"Value cannot be less than 0";
}
--value;
}
};
|
假设你想在不更改上述代码的前提下为其提供线程安全性，那么你需要为其创建一个 Wrapper 类：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
struct
ConcurrentCounter {
std::mutex mutex;
Counter counter;
void
increment(){
mutex.lock();
counter.increment();
mutex.unlock();
}
void
decrement(){
mutex.lock();
counter.decrement();
mutex.unlock();
}
};
|
这个 Wrapper 将在大多数情况下正常工作，然而一旦 decrement() 抛出异常，你就遇到大麻烦了，当异常被抛出时，unlock() 函数将不会被调用，这将导致本线程获得的锁不被释放，你的程序也就顺理成章的被永久阻塞了。为了修复这一问题，你需要使用 try/catch 块以保证在抛出任何异常之前释放获得的锁。
|
1
2
3
4
5
6
7
8
9
10
|
void
decrement(){
mutex.lock();
try
{
counter.decrement();
}
catch
(std::string e){
mutex.unlock();
throw
e;
}
mutex.unlock();
}
|
代码并不复杂，但是看起来却很丑陋。试想一下，你现在的函数拥有 10 个返回点，那么你就需要在每个返回点前调用 unlock() 函数，而忘掉其中的某一个的可能性是非常大的。更大的风险在于你又添加了新的函数返回点，却没有对应地添加 unlock()。下一节将给出解决此问题的好办法。
锁的自动管理
当你想保护整个代码段（就本文而言是一个函数，但也可以是某个循环体或其他控制结构[译注：即一个作用域]）免受多线程的侵害时，有一个办法将有助于防止忘记释放锁：std::lock_guard。
这个类是一个简单、智能的锁管理器。当 std::lock_guard 实例被创建时，它自动地调用互斥量的lock() 函数，当该实例被销毁时，它也顺带释放掉获得的锁。你可以像这样使用它：
|
1
2
3
4
5
6
7
8
9
10
11
12
|
struct
ConcurrentSafeCounter {
std::mutex mutex;
Counter counter;
void
increment(){
std::lock_guard<std::mutex> guard(mutex);
counter.increment();
}
void
decrement(){
std::lock_guard<std::mutex> guard(mutex);
counter.decrement();
}
};
|
代码变得更整洁了不是吗？
使用这种方法，你无须绷紧神经关注每一个函数返回点是否释放了锁，因为这个操作已经被std::lock_guard 实例的析构函数接管了。
总结
现在我们结束了短暂的 Semaphores 之旅。在本章中你学习了如何使用 C++ 线程库中的互斥量来保护你的共享数据。
但有一点请牢记：锁机制会带来效率的降低。的确，一旦使用锁，你的部分代码就变得有序[译注：非并发]了。如果你想要设计一个高度并发的应用程序，你将会用到其他一些比锁更好的机制，但他们已不属于本文的讨论范畴。
下篇
在本系列的下一篇文章中，我将谈及关于互斥量的一些进阶概念，并介绍如何使用条件变量去解决一些并发编程问题。
来源：oschina
链接：https://my.oschina.net/u/593529/blog/188700