C++11线程中的几种锁
C++11线程中的几种锁
- 互斥锁（Mutex）
- 条件锁
- 自旋锁
- 读写锁
- 递归锁
线程之间的锁有： 互斥锁、条件锁、自旋锁、读写锁、递归锁。一般而言，锁的功能与性能成反比。不过我们一般不使用递归锁（C++标准库提供了std::recursive_mutex），所以这里就不推荐了。
互斥锁（Mutex）
互斥锁用于控制多个线程对他们之间共享资源互斥访问的一个信号量。也就是说是为了避免多个线程在某一时刻同时操作一个共享资源。例如线程池中的有多个空闲线程和一个任务队列。任何是一个线程都要使用互斥锁互斥访问任务队列，以避免多个线程同时访问任务队列以发生错乱。
在某一时刻，只有一个线程可以获取互斥锁，在释放互斥锁之前其他线程都不能获取该互斥锁。如果其他线程想要获取这个互斥锁，那么这个线程只能以阻塞方式进行等待。
头文件：< mutex >
类型： std::mutex
用法：在C++中，通过构造std::mutex的实例创建互斥元，调用成员函数lock()来锁定它，调用unlock()来解锁，不过一般不推荐这种做法，标准C++库提供了std::lock_guard和unique_lock类模板，都是RAII风格，它们是在定义时获得锁，在析构时释放锁。它们的主要区别在于unique_lock锁机制更加灵活，可以再需要的时候进行lock或者unlock调用，不非得是析构或者构造时。std::mutex和std::lock _ guard。都声明在< mutex >头文件中。
//用互斥元保护列表
#include
#include 以下情况会出现死锁：
mutex m0,m1;
int i = 0;
void fun0()
{
while (i < 100)
{
lock_guard<mutex> g0(m0); //线程0加锁0
lock_guard<mutex> g1(m1); //线程0加锁1
cout << "thread 0 running..." << endl;
}
return;
}
void fun1()
{
while (i < 100)
{
lock_guard<mutex> g1(m1); //线程1加锁1
lock_guard<mutex> g0(m0); //线程1加锁0
cout << "thread 1 running... "<< i << endl;
}
return;
}
int main()
{
thread p0(fun0);
thread p1(fun1);
p0.join();
p1.join();
return 0;
}
死锁：死锁是指两个或两个以上的进程（线程）在运行过程中因争夺资源而造成的一种僵局，若无外力作用，这些进程（线程）都将无法向前推进。
解决死锁的方法：
1、顺序加锁
mutex m0,m1;
int i = 0;
void fun0()
{
while (i < 100)
{
lock_guard<mutex> g0(m0); //线程0加锁0
lock_guard<mutex> g1(m1); //线程0加锁1
cout << "thread 0 running..." << endl;
}
return;
}
void fun1()
{
while (i < 100)
{
lock_guard<mutex> g0(m0); //线程1加锁0
lock_guard<mutex> g1(m1); //线程1加锁1
cout << "thread 1 running... "<< i << endl;
}
return;
}
int main()
{
thread p0(fun0);
thread p1(fun1);
p0.join();
p1.join();
return 0;
}
2、同时上锁（需要用到lock函数）
mutex m0,m1;
int i = 0;
void fun0()
{
while (i < 100)
{
lock(m0,m1);
lock_guard<mutex> g0(m0, adopt_lock);
lock_guard<mutex> g1(m1, adopt_lock);
cout << "thread 0 running..." << endl;
}
return;
}
void fun1()
{
while (i < 100)
{
lock(m0,m1);
lock_guard<mutex> g0(m0, adopt_lock);
lock_guard<mutex> g1(m1, adopt_lock);
cout << "thread 1 running... "<< i << endl;
}
return;
}
int main()
{
thread p0(fun0);
thread p1(fun1);
p0.join();
p1.join();
return 0;
}
注意到这里的lock_guard中多了第二个参数adopt_lock，这个参数表示在调用lock_guard时，已经加锁了，防止lock_guard在对象生成时构造函数再次lock()。
条件锁
当需要死循环判断某个条件成立与否时【true or false】，我们往往需要开一个线程死循环来判断，这样非常消耗CPU。使用条件变量，可以让当前线程wait，释放CPU，如果条件改变时，我们再notify退出线程，再次进行判断。
条件锁就是所谓的条件变量，某一个线程因为某个条件未满足时可以使用条件变量使该程序处于阻塞状态。一旦条件满足以“信号量”的方式唤醒一个因为该条件而被阻塞的线程(常和互斥锁配合使用)，唤醒后，需要检查变量，避免虚假唤醒。最为常见就是在线程池中，起初没有任务时任务队列为空，此时线程池中的线程因为“任务队列为空”这个条件处于阻塞状态。一旦有任务进来，就会以信号量的方式唤醒一个线程来处理这个任务。
头文件：< condition_variable >
类型：std::condition_variable（只和std::mutex一起工作） 和 std::condition_variable_any（符合类似互斥元的最低标准的任何东西一起工作）。
C++标准库在< condition_variable >中提供了条件变量，借由它，一个线程可以唤醒一个或多个其他等待中的线程。
想要修改共享变量（即“条件”）的线程必须：
- 获得一个std::mutex
- 当持有锁的时候，执行修改动作
- 对std::condition_variable执行notify_one或notify_all(当做notify动作时，不必持有锁)
即使共享变量是原子性的，它也必须在mutex的保护下被修改，这是为了能够将改动正确发布到正在等待的线程。
任意要等待std::condition_variable的线程必须：
- 获取
std::unique_lock，这个mutex正是用来保护共享变量（即“条件”）的 - 执行wait, wait_for或者wait_until. 这些等待动作原子性地释放mutex，并使得线程的执行暂停
- 当获得条件变量的通知，或者超时，或者一个虚假的唤醒，那么线程就会被唤醒，并且获得mutex. 然后线程应该检查条件是否成立，如果是虚假唤醒，就继续等待。
【注： 所谓虚假唤醒，就是因为某种未知的罕见的原因，线程被从等待状态唤醒了，但其实共享变量（即条件）并未变为true。因此此时应继续等待】
std::deque<int> q;
std::mutex mu;
std::condition_variable cond;
void function_1() //生产者
{
int count = 10;
while (count > 0)
{
std::unique_lock<std::mutex> locker(mu);
q.push_front(count);
locker.unlock();
cond.notify_one(); // Notify one waiting thread, if there is one.
std::this_thread::sleep_for(std::chrono::seconds(1));
count--;
}
}
void function_2() //消费者
{
int data = 0;
while (data != 1)
{
std::unique_lock<std::mutex> locker(mu);
while (q.empty())
cond.wait(locker); // Unlock mu and wait to be notified
data = q.back();
q.pop_back();
locker.unlock();
std::cout << "t2 got a value from t1: " << data << std::endl;
}
}
int main()
{
std::thread t1(function_1);
std::thread t2(function_2);
t1.join();
t2.join();
return 0;
}
上面的代码有三个注意事项：
- 在function_2中，在判断队列是否为空的时候，使用的是while(q.empty())，而不是if(q.empty())，这是因为wait()从阻塞到返回，不一定就是由于notify_one()函数造成的，还有可能由于系统的不确定原因唤醒（可能和条件变量的实现机制有关），这个的时机和频率都是不确定的，被称作伪唤醒。如果在错误的时候被唤醒了，执行后面的语句就会错误，所以需要再次判断队列是否为空，如果还是为空，就继续wait()阻塞；
- 在管理互斥锁的时候，使用的是
std::unique_lock而不是std::lock_guard， 而且事实上也不能使用std::lock_guard。这需要先解释下wait()函数所做的事情，可以看到，在wait()函数之前，使用互斥锁保护了，如果wait的时候什么都没做，岂不是一直持有互斥锁？那生产者也会一直卡住，不能够将数据放入队列中了。所以，wait()函数会先调用互斥锁的unlock()函数，然后再将自己睡眠，在被唤醒后，又会继续持有锁，保护后面的队列操作。lock_guard没有lock和unlock接口，而unique_lock提供了，这就是必须使用unique_lock的原因； - 使用细粒度锁，尽量减小锁的范围，在notify_one()的时候，不需要处于互斥锁的保护范围内，所以在唤醒条件变量之前可以将锁unlock()。
自旋锁
假设我们有一个两个处理器core1和core2计算机，现在在这台计算机上运行的程序中有两个线程：T1和T2分别在处理器core1和core2上运行，两个线程之间共享着一个资源。
首先我们说明互斥锁的工作原理，互斥锁是是一种sleep-waiting的锁。假设线程T1获取互斥锁并且正在core1上运行时，此时线程T2也想要获取互斥锁（pthread_mutex_lock），但是由于T1正在使用互斥锁使得T2被阻塞。当T2处于阻塞状态时，T2被放入到等待队列中去，处理器core2会去处理其他任务而不必一直等待（忙等）。也就是说处理器不会因为线程阻塞而空闲着，它去处理其他事务去了。
而自旋锁就不同了，自旋锁是一种busy-waiting的锁。也就是说，如果T1正在使用自旋锁，而T2也去申请这个自旋锁，此时T2肯定得不到这个自旋锁。与互斥锁相反的是，此时运行T2的处理器core2会一直不断地循环检查锁是否可用（自旋锁请求），直到获取到这个自旋锁为止。
从“自旋锁”的名字也可以看出来，如果一个线程想要获取一个被使用的自旋锁，那么它会一致占用CPU请求这个自旋锁使得CPU不能去做其他的事情，直到获取这个锁为止，这就是“自旋”的含义。
当发生阻塞时，互斥锁可以让CPU去处理其他的任务；而自旋锁让CPU一直不断循环请求获取这个锁。 通过两个含义的对比可以我们知道“自旋锁”是比较耗费CPU的。
// 用户空间用 atomic_flag 实现自旋互斥
#include 说明：atomic是C++标准程序库中的一个头文件，定义了C++11标准中的一些表示线程、并发控制时原子操作的类与方法等。此头文件主要声明了两大类原子对象：std::atomic和std::atomic_flag。
atomic_flag类：是一种简单的原子布尔类型，只支持两种操作：test_and_set(flag=true)和clear(flag=false)。- std::atomic类模板：std::atomic既不可复制亦不可移动。atomic对int、char、bool等数据结构进行了原子性封装，在多线程环境中，对std::atomic对象的访问不会造成竞争-冒险。利用std::atomic可实现数据结构的无锁设计。
所谓的原子操作，取的就是“原子是最小的、不可分割的最小个体”的意义，它表示在多个线程访问同一个全局资源的时候，能够确保所有其他的线程都不在同一时间内访问相同的资源。也就是他确保了在同一时刻只有唯一的线程对这个资源进行访问。这有点类似互斥对象对共享资源的访问的保护，但是原子操作更加接近底层，因而效率更高。使用原子操作能大大的提高程序的运行效率。
#include 读写锁
先看看互斥锁，它只有两个状态，要么是加锁状态，要么是不加锁状态。假如现在一个线程a只是想读一个共享变量 i，因为不确定是否会有线程去写它，所以我们还是要对它进行加锁。但是这时又有一个线程b试图去读共享变量 i，发现被锁定了，那么b不得不等到a释放了锁后才能获得锁并读取 i 的值，但是两个读取操作即使是同时发生的，也并不会像写操作那样造成竞争，因为它们不修改变量的值。所以我们期望在多个线程试图读取共享变量的时候，它们可以立刻获取因为读而加的锁，而不是需要等待前一个线程释放。
读写锁可以解决上面的问题。它提供了比互斥锁更好的并行性。因为以读模式加锁后，当有多个线程试图再以读模式加锁时，并不会造成这些线程阻塞在等待锁的释放上。
读写锁是多线程同步的另外一个机制。在一些程序中存在读操作和写操作问题，对某些资源的访问会存在两种可能情况，一种情况是访问必须是排他的，就是独占的意思，这种操作称作写操作，另外一种情况是访问方式是可以共享的，就是可以有多个线程同时去访问某个资源，这种操作称为读操作。这个问题模型是从对文件的读写操作中引申出来的。把对资源的访问细分为读和写两种操作模式，这样可以大大增加并发效率。读写锁比互斥锁适用性更高，并行性也更高。
需要注意的是，这里只是说并行效率比互斥高，并不是速度一定比互斥锁快，读写锁更复杂，系统开销更大。并发性好对于用户体验非常重要，假设互斥锁需要0.5秒，使用读写锁需要0.8秒，在类似学生管理系统的软件中，可能90%的操作都是查询操作。如果突然有20个查询请求，使用的是互斥锁，则最后的查询请求被满足需要10秒，估计没人接收。使用读写锁时，因为读锁能多次获得，所以20个请求中，每个请求都能在1秒左右被满足，用户体验好的多。
读写锁特点
1 如果一个线程用读锁锁定了临界区，那么其他线程也可以用读锁来进入临界区，这样可以有多个线程并行操作。这个时候如果再用写锁加锁就会发生阻塞。写锁请求阻塞后，后面继续有读锁来请求时，这些后来的读锁都将会被阻塞。这样避免读锁长期占有资源，防止写锁饥饿。
2 如果一个线程用写锁锁住了临界区，那么其他线程无论是读锁还是写锁都会发生阻塞。
头文件：boost/thread/shared_mutex.cpp
类型：boost::shared_lock
用法：你可以使用boost::shared_ mutex的实例来实现同步，而不是使用std::mutex的实例。对于更新操作，std::lock_guard< boost::shared _mutex>和 std::unique _lock< boost::shared _mutex>可用于锁定，以取代相应的std::mutex特化。这确保了独占访问，就像std::mutex那样。那些不需要更新数据结构的线程能够转而使用 boost::shared _lock< boost::shared _mutex>来获得共享访问。这与std::unique _lock用起来正是相同的，除了多个线程在同一时间，同一boost::shared _mutex上可能会具有共享锁。唯一的限制是，如果任意一个线程拥有一个共享锁，试图获取独占锁的线程会被阻塞，知道其他线程全都撤回它们的锁。同样的，如果一个线程具有独占锁，其他线程都不能获取共享锁或独占锁，直到第一个线程撤回它的锁。
简单的说：
shared_lock是read lock。被锁后仍允许其他线程执行同样被shared_lock的代码。这是一般做读操作时的需要。
unique_lock是write lock。被锁后不允许其他线程执行被shared_lock或unique_lock的代码。在写操作时，一般用这个，可以同时限制unique_lock的写和share_lock的读。
递归锁
std::recursive_mutex 与 std::mutex 一样，也是一种可以被上锁的对象，但是和 std::mutex 不同的是，std::recursive_mutex 允许同一个线程对互斥量多次上锁（即递归上锁），来获得对互斥量对象的多层所有权，std::recursive_mutex 释放互斥量时需要调用与该锁层次深度相同次数的 unlock()，可理解为 lock() 次数和 unlock() 次数相同，除此之外，std::recursive_mutex 的特性和 std::mutex 大致相同。
例如函数a需要获取锁mutex，函数b也需要获取锁mutex，同时函数a中还会调用函数b。如果使用std::mutex必然会造成死锁。但是使用std::recursive_mutex就可以解决这个问题。