08C++11多线程编程之unique_lock类模板
前述:
如果看懂了该篇文章,你对unique_lock可以说随便使用。并且可以只看第5点的总结即可。
1 unique_lock概念
当不加参数时,和lock_guard一样能自动上锁解锁,参数2比lock_guard更加灵活,效率比lock_guard低点,内存也占用大点。看个人喜欢用哪个。
并且和lock_guard都是独占型锁,一把锁只能绑定一个unique_lock,不能多个。类似unique_ptr独占型智能指针。
注:由于不加参数时unique_lock是和lock_guard一样,所以这里就不给出unique_lock无参数2的代码例子。
2 unique_lock的第二个参数
1)std::adopt_lock:表示在创建unique_lock之前已经上锁了。若没上锁,则程序报错崩溃。lock_guard也有唯一的参2->std::adopt_lock,用法完全相同。
这里需要严重的强调一点:adopt_lock不能手动解锁,否则崩溃,与lock_guard的参2->adopt_lock完全一样。与try_to_lock和defer_lock能提前解锁完全不一样。
#include<iostream>
#include<thread>
#include<string>
#include<vector>
#include<list>
#include<mutex>
using namespace std;
//准备用成员函数作为线程函数的方法写线程,成为消息处理类
class A {
public:
//把收到的消息入到一个队列的线程
void inMsgRecvQueue() {
for (int i = 0; i < 10000; i++) {
cout << "inMsgRecvQueue()执行,插入一个元素" << i << endl;
std::lock(my_mutex1, my_mutex2);//一次锁多个,顺序可以忽略
unique_lock<mutex> uLock1(my_mutex1, std::adopt_lock);//参数2表示锁已经上锁
unique_lock<mutex> uLock2(my_mutex2, std::adopt_lock);
msgRecvQueue.push_back(i);
//my_mutex1.unlock();//不能再手动解锁,否则崩溃,与lock_guard的参2adopt_lock完全一样
//my_mutex2.unlock();
}
}
//将共享的代码放到一个函数处理,方便上锁解锁
bool outMsgLULProc(int &command) {
std::lock(my_mutex2, my_mutex1);//一次锁多个,顺序可以忽略
unique_lock<mutex> uLock1(my_mutex1, std::adopt_lock);//参数2表示锁已经上锁
unique_lock<mutex> uLock2(my_mutex2, std::adopt_lock);
if (!msgRecvQueue.empty()) {
int command = msgRecvQueue.front();
msgRecvQueue.pop_front();
//my_mutex1.unlock();//不能再手动解锁,否则崩溃,与lock_guard的参2adopt_lock完全一样
//my_mutex2.unlock();
return true;
}
//my_mutex2.unlock();
//my_mutex1.unlock();
return false;
}
//把数据从消息队列取出的线程
void outMsgRecvQueue() {
int command = 0;
for (int i = 0; i < 10000; i++) {
bool result = outMsgLULProc(command);
if (result == true) {
cout << "outMsgRecvQueue()执行,取出一个元素" << endl;
//处理数据
//这里有可能也有需要共享的代码段
}
else {
//消息队列为空
cout << "outMsgRecvQueue()执行,但目前消息队列中为空!" << endl;
}
}
cout << "end!" << endl;
}
private:
std::list<int> msgRecvQueue;//容器(消息队列),代表玩家发送过来的命令。
std::mutex my_mutex1;
std::mutex my_mutex2;
};
int main()
{
A myobja;
std::thread myOutMsgObj(&A::outMsgRecvQueue, &myobja);//第二个参数,地址,才能保证线程里用的是同一个对象
std::thread myInMsgObj(&A::inMsgRecvQueue, &myobja);
myOutMsgObj.join();
myInMsgObj.join();
cout << "主线程执行!" << endl;
return 0;
}
该程序结果是稳定运行的,但是我多次运行发现这个类有bug,就是说当outMsg执行10000次后,可能list还会有元素,但是只是测试就不需要管它了。
下图是std::adopt_lock提前解锁崩溃的图:
我们知道,当一个线程拿到一把锁之后,另一个线程只能阻塞等待该锁的释放。如果拥有该锁的线程执行时间长,另一个线程等待的时间也长,那么我们能不能让它不等待呢?当然可以,这时候try_to_lock就出现了。
2)std::try_to_lock
std::try_to_lock:表示在创建unique_lock之前不能上锁,否则程序报错崩溃。并且会尝试去上锁,若上锁失败也会立即返回,不会阻塞等待。当std::try_to_lock拿到锁后,也可以提前释放锁,但是没拿到锁不能提前释放,会崩溃。
#include<iostream>
#include<thread>
#include<string>
#include<vector>
#include<list>
#include<mutex>
using namespace std;
//准备用成员函数作为线程函数的方法写线程,成为消息处理类
class A{
public:
//把收到的消息入到一个队列的线程
void inMsgRecvQueue(){
for (int i = 0; i < 10000; i++){
cout << "inMsgRecvQueue()执行,插入一个元素" << i << endl;
//my_mutex1.lock();//不能先上锁,否则程序崩溃
unique_lock<mutex> uLock1(my_mutex1, std::try_to_lock);
if (uLock1.owns_lock()) {
//拿到了锁
msgRecvQueue.push_back(i);
//uLock1.unlock();//ok,拿到锁可以提前释放,然后可以处理其它非共享代码
//处理其他非共享代码
}
else {
//没拿到锁
cout << "inMsgRecvQueue()执行,但没拿到锁头,只能干点别的事" << i << endl;
//uLock1.unlock();//error,没拿到锁不能释放
}
}
}
//将共享的代码放到一个函数处理,方便上锁解锁
bool outMsgLULProc(int &command){
unique_lock<mutex> uLock1(my_mutex1, std::try_to_lock);
if (uLock1.owns_lock()) {
if (!msgRecvQueue.empty()) {
int command = msgRecvQueue.front();
msgRecvQueue.pop_front();
//uLock1.unlock();//ok,拿到锁可以提前释放,然后可以处理其它非共享代码
return true;
}
}
else {
//没拿到锁
cout << "outMsgLULProc()执行,但没拿到锁头,只能干点别的事" << endl;
}
return false;
}
//把数据从消息队列取出的线程
void outMsgRecvQueue(){
int command = 0;
for (int i = 0; i < 10000; i++){
bool result = outMsgLULProc(command);
if (result == true){
cout << "outMsgRecvQueue()执行,取出一个元素" << endl;
//处理数据
//这里有可能也有需要共享的代码段
}
else{
//消息队列为空
cout << "outMsgRecvQueue()执行,但目前消息队列中为空!" << endl;
}
}
cout << "end!" << endl;
}
private:
std::list<int> msgRecvQueue;//容器(消息队列),代表玩家发送过来的命令。
std::mutex my_mutex1;
std::mutex my_mutex2;
};
int main()
{
A myobja;
std::thread myOutMsgObj(&A::outMsgRecvQueue, &myobja);//第二个参数,地址,才能保证线程里用的是同一个对象
std::thread myInMsgObj(&A::inMsgRecvQueue, &myobja);
myOutMsgObj.join();
myInMsgObj.join();
cout << "主线程执行!" << endl;
return 0;
}
可以看到结果,当一个程序拿到锁后,另一个程序也可以不阻塞,可以去干其它事情。
3)std::defer_lock
std::defer_lock:表示在创建unique_lock之前不能上锁,否则程序报错崩溃。
同样在拿到锁之后,可以提前释放锁,然后处理非共享代码,提高程序效率。这种也是本人推荐也用得最多的一种。
#include<iostream>
#include<thread>
#include<string>
#include<vector>
#include<list>
#include<mutex>
using namespace std;
//准备用成员函数作为线程函数的方法写线程,成为消息处理类
class A{
public:
//把收到的消息入到一个队列的线程
void inMsgRecvQueue(){
for (int i = 0; i < 10000; i++){
cout << "inMsgRecvQueue()执行,插入一个元素" << i << endl;
//my_mutex1.lock();//不能先上锁,否则程序崩溃
unique_lock<mutex> uLock1(my_mutex1, std::defer_lock);
uLock1.lock();//需要自己上锁
msgRecvQueue.push_back(i);
//uLock1.unlock();//ok,拿到锁可以提前释放,然后可以处理其它非共享代码
}
}
//将共享的代码放到一个函数处理,方便上锁解锁
bool outMsgLULProc(int &command){
unique_lock<mutex> uLock1(my_mutex1, std::defer_lock);
uLock1.lock();//需要自己上锁
if (!msgRecvQueue.empty()) {
int command = msgRecvQueue.front();
msgRecvQueue.pop_front();
return true;
}
//uLock1.unlock();//ok,拿到锁可以提前释放,然后可以处理其它非共享代码
return false;
}
//把数据从消息队列取出的线程
void outMsgRecvQueue(){
int command = 0;
for (int i = 0; i < 10000; i++){
bool result = outMsgLULProc(command);
if (result == true){
cout << "outMsgRecvQueue()执行,取出一个元素" << endl;
//处理数据
//这里有可能也有需要共享的代码段
}
else{
//消息队列为空
cout << "outMsgRecvQueue()执行,但目前消息队列中为空!" << endl;
}
}
cout << "end!" << endl;
}
private:
std::list<int> msgRecvQueue;//容器(消息队列),代表玩家发送过来的命令。
std::mutex my_mutex1;
std::mutex my_mutex2;
};
int main()
{
A myobja;
std::thread myOutMsgObj(&A::outMsgRecvQueue, &myobja);//第二个参数,地址,才能保证线程里用的是同一个对象
std::thread myInMsgObj(&A::inMsgRecvQueue, &myobja);
myOutMsgObj.join();
myInMsgObj.join();
cout << "主线程执行!" << endl;
return 0;
}
3 unique_lock的成员函数
实际上再讲unique_lock的参2的std::try_to_lock、std::defer_lock时已经用到了unique_lock的两个成员函数uLock1.owns_lock()与uLock1.lock()了。
1)lock(),加锁。例子看上面的std::defer_lock即可。
2)unlock(),解锁。例子同样可以看上面的std::defer_lock或者std::try_to_lock即可。
为什么unique_lock可以自动解锁还是提供手动解锁的方式呢,这是因为我们处理完某段共享代码后,可能会出现非共享代码,这时我们解锁后能提高效率。然后再出现共享代码的话我们再次上锁即可。
#include<iostream>
#include<thread>
#include<string>
#include<vector>
#include<list>
#include<mutex>
using namespace std;
//准备用成员函数作为线程函数的方法写线程,成为消息处理类
class A {
public:
//把收到的消息入到一个队列的线程
void inMsgRecvQueue() {
for (int i = 0; i < 10000; i++) {
cout << "inMsgRecvQueue()执行,插入一个元素" << i << endl;
unique_lock<mutex> uLock1(my_mutex1, std::defer_lock);
//处理共享代码
uLock1.lock();
msgRecvQueue.push_back(i);
uLock1.unlock();
//处理完上面的共享代码后,可能出现非共享代码
//非共享代码
//共享代码
uLock1.lock();
uLock1.unlock();//这句可以不要,让其自动解锁,注意不要写成my_mutex1.unlock()
}
}
//将共享的代码放到一个函数处理,方便上锁解锁
bool outMsgLULProc(int &command) {
unique_lock<mutex> uLock1(my_mutex1, std::defer_lock);
uLock1.lock();
if (!msgRecvQueue.empty()) {
int command = msgRecvQueue.front();
msgRecvQueue.pop_front();
//uLock1.unlock()//这句可以不要,让其自动解锁
return true;
}
//uLock1.unlock();//这句可以不要,让其自动解锁
return false;
}
//把数据从消息队列取出的线程
void outMsgRecvQueue() {
int command = 0;
for (int i = 0; i < 10000; i++) {
bool result = outMsgLULProc(command);
if (result == true) {
cout << "outMsgRecvQueue()执行,取出一个元素" << endl;
//处理数据
//这里有可能也有需要共享的代码段
}
else {
//消息队列为空
cout << "outMsgRecvQueue()执行,但目前消息队列中为空!" << endl;
}
}
cout << "end!" << endl;
}
private:
std::list<int> msgRecvQueue;//容器(消息队列),代表玩家发送过来的命令。
std::mutex my_mutex1;
std::mutex my_mutex2;
};
int main()
{
A myobja;
std::thread myOutMsgObj(&A::outMsgRecvQueue, &myobja);//第二个参数,地址,才能保证线程里用的是同一个对象
std::thread myInMsgObj(&A::inMsgRecvQueue, &myobja);
myOutMsgObj.join();
myInMsgObj.join();
cout << "主线程执行!" << endl;
return 0;
}
3)try_lock()
作用:成功上锁返回true,没拿到锁返回false。
该成员函数可以说与constexpr常量宏类型std::try_to_lock(实际为结构体)用法是一样的,同样可以不阻塞和提前解锁。所以我们可以看到,只要使用std::defer常量宏,就基本能使用C++11锁的所有功能了。
#include<iostream>
#include<thread>
#include<string>
#include<vector>
#include<list>
#include<mutex>
using namespace std;
//准备用成员函数作为线程函数的方法写线程,成为消息处理类
class A {
public:
//把收到的消息入到一个队列的线程
void inMsgRecvQueue() {
for (int i = 0; i < 10000; i++) {
cout << "inMsgRecvQueue()执行,插入一个元素" << i << endl;
unique_lock<mutex> uLock1(my_mutex1, std::defer_lock);
if (uLock1.try_lock()) {
msgRecvQueue.push_back(i);
uLock1.unlock();//ok,上锁成功可以提前解锁
}
else {
cout << "没上锁成功,干点别的事情" << endl;
//uLock1.unlock();//error,没上锁不能解锁
}
}
}
//将共享的代码放到一个函数处理,方便上锁解锁
bool outMsgLULProc(int &command) {
unique_lock<mutex> uLock1(my_mutex1, std::defer_lock);
uLock1.lock();
if (!msgRecvQueue.empty()) {
int command = msgRecvQueue.front();
msgRecvQueue.pop_front();
//uLock1.unlock()//这句可以不要,让其自动解锁
return true;
}
//uLock1.unlock();//这句可以不要,让其自动解锁
return false;
}
//把数据从消息队列取出的线程
void outMsgRecvQueue() {
int command = 0;
for (int i = 0; i < 10000; i++) {
bool result = outMsgLULProc(command);
if (result == true) {
cout << "outMsgRecvQueue()执行,取出一个元素" << endl;
//处理数据
//这里有可能也有需要共享的代码段
}
else {
//消息队列为空
cout << "outMsgRecvQueue()执行,但目前消息队列中为空!" << endl;
}
}
cout << "end!" << endl;
}
private:
std::list<int> msgRecvQueue;//容器(消息队列),代表玩家发送过来的命令。
std::mutex my_mutex1;
std::mutex my_mutex2;
};
int main(){
A myobja;
std::thread myOutMsgObj(&A::outMsgRecvQueue, &myobja);//第二个参数,地址,才能保证线程里用的是同一个对象
std::thread myInMsgObj(&A::inMsgRecvQueue, &myobja);
myOutMsgObj.join();
myInMsgObj.join();
cout << "主线程执行!" << endl;
return 0;
}
结果:可以看到,都是能稳定运行的,和std::try_to_lock常量宏一样,不会阻塞并且都是能提前解锁的,或者说,只要是std::defer常量宏,都能够提前解锁。
4)release()成员函数
release()的作用:
- 1)返回它所管理的mutex对象指针,并释放所有权;也就是说,这个unique_lock和mutex不再有关系。严格区分unlock()与release()的区别,不要混淆。
- 2)如果原来mutex对像处于加锁状态,你有责任接管过来并负责解锁。也就是说,类似移动语义将该对象交给你,原来什么状态的就处于什么状态。
代码案例讲解release成员函数。为了方便,我们将try_lock()成员函数的代码例子中,只修改inMsg。
//注:以下代码都是正确的。
/*
1 接管的是上锁状态的锁
*/
void inMsgRecvQueue() {
for (int i = 0; i < 10000; i++) {
cout << "inMsgRecvQueue()执行,插入一个元素" << i << endl;
unique_lock<mutex> uLock1(my_mutex1);//已经上锁
mutex *tmpMyx = uLock1.release();//接管已上锁的mutex,移动语义,可自行断点查看地址
msgRecvQueue.push_back(i);
tmpMyx->unlock();//需要自行解锁,否则程序出现崩溃
}
}
//或者可以写成这样
void inMsgRecvQueue() {
for (int i = 0; i < 10000; i++) {
cout << "inMsgRecvQueue()执行,插入一个元素" << i << endl;
my_mutex1.lock();
unique_lock<mutex> uLock1(my_mutex1, std::adopt_lock);//已经上锁
mutex *tmpMyx = uLock1.release();//接管已上锁的mutex,移动语义,可自行断点查看地址
msgRecvQueue.push_back(i);
tmpMyx->unlock();//需要自行解锁,否则程序出现崩溃
}
}
/*
2 接管的是未上锁状态的锁
*/
void inMsgRecvQueue() {
for (int i = 0; i < 10000; i++) {
cout << "inMsgRecvQueue()执行,插入一个元素" << i << endl;
unique_lock<mutex> uLock1(my_mutex1, std::defer_lock);
mutex *tmpMyx = uLock1.release();//接管未上锁的mutex,自行上锁
tmpMyx->lock();
msgRecvQueue.push_back(i);
tmpMyx->unlock();//需要自行解锁,否则程序出现崩溃
}
}
仍需注意一点:调用release必须手动上锁解锁,否则容易出现崩溃。
下图是上锁后忘记解锁的崩溃图。
下图是release接管未上锁的锁后,上锁后也没解锁的崩溃图。
4 unique_lock所有权的传递
因为unique_lock和lock_guard、unique_ptr都一样,为独占型,要想传递,必须使用移动语义或者返回匿名对象等操作(一般只有这两种就足够了)传递所有权。
std::unique_lock<std::mutex> uLock1(my_mutex);//uLock1拥有my_mutex的所有权;uLock1可以把自己对my_mutex的所有权转移给其他的unique_lock对象;所以unique_lock对象这个mutex的所有权是可以转移,但是不能复制。
//例如
std::unique_lock<std::mutex> uLock2(uLock1);//此句是非法的,复制所有权是非法的
//正确写法:
//1)利用移动语义
void inMsgRecvQueue() {
for (int i = 0; i < 10000; i++) {
cout << "inMsgRecvQueue()执行,插入一个元素" << i << endl;
unique_lock<mutex> uLock1(my_mutex1);
unique_lock<mutex> uLock2(std::move(uLock1));//移动语义,现在uLock1指向空,uLock2指向了my_mutex
msgRecvQueue.push_back(i);
//uLock2.unlock();//ok,当unique_lock不加参2也可以提前解锁
}
}
//2)利用返回的匿名对象
std::unique_lock<std::mutex> rtn_unique_lock() {
std::unique_lock<std::mutex> tmp(my_mutex1);
return tmp;//注意并非返回tmp,而是返回tmp的复制品,也叫匿名对象
}
//把收到的消息入到一个队列的线程
void inMsgRecvQueue() {
for (int i = 0; i < 10000; i++) {
cout << "inMsgRecvQueue()执行,插入一个元素" << i << endl;
//unique_lock<mutex> uLock1(my_mutex1);
//unique_lock<mutex> uLock2(std::move(uLock1));
unique_lock<mutex> uLock2(rtn_unique_lock());//这样就将tmp中的所有权返回给uLock2,即返回tmp的unique_lock类型的匿名对象,并调用unique_lock的移动构造函数给uLock2赋值
//unique_lock<mutex> uLock2 = rtn_unique_lock();//或者这样也是和上一句一样
msgRecvQueue.push_back(i);
//uLock2.unlock();//ok,当unique_lock不加参2也可以提前解锁
}
}
可以看到结果,代码都是稳定执行的。
5 总结unique_lock所有内容
- 1)当unique_lock不加任何参数时,与lock_guard不加参数一模一样,并且可以提前手动释放锁。
- 2)unique_lock第二个参数std::adopt_lock,表示在创建unique_lock之前已经上锁了。若没上锁,则程序报错崩溃。lock_guard也有唯一的参2->std::adopt_lock,用法完全相同。并且只有该常量宏是不能手动提前解锁,否则崩溃,与lock_guard的参2->adopt_lock完全一样。与try_to_lock和defer_lock能提前解锁完全不一样。
- 3)unique_lock第二个参数std::try_to_lock,表示在创建unique_lock之前不能上锁,否则程序报错崩溃。并且会尝试去上锁,若上锁失败也会立即返回,不会阻塞等待。当std::try_to_lock拿到锁后,也可以提前释放锁,但是没拿到锁不能提前释放,会崩溃。
- 4)unique_lock第二个参数std::defer_lock,表示在创建unique_lock之前不能上锁,否则程序报错崩溃。同样在拿到锁之后,可以提前释放锁,然后处理非共享代码,提高程序效率。这种也是本人推荐也用得最多的一种。它几乎可以使用C++11所有的锁功能。
- 5)unique_lock的成员函数:lock(),加锁。
- 6)unique_lock的成员函数:unlock(),解锁。为什么unique_lock可以自动解锁还是提供手动解锁的方式呢,这是因为我们处理完某段共享代码后,可能会出现非共享代码,这时我们解锁后能提高效率。然后再出现共享代码的话我们再次上锁即可。
- 7)unique_lock的成员函数:try_lock(),作用:成功上锁返回true,没拿到锁返回false。该成员函数可以说与constexpr常量宏类型std::try_to_lock(实际为结构体)用法是一样的,同样可以不阻塞和提前解锁。所以我们可以看到,只要使用std::defer常量宏,就基本能使用C++11锁的所有功能了。
- 8)unique_lock的成员函数:release(),作用:1)返回它所管理的mutex对象指针,并释放所有权;也就是说,这个unique_lock和mutex不再有关系。严格区分unlock()与release()的区别,不要混淆。2)如果原来mutex对像处于加锁状态,你有责任接管过来并负责解锁。也就是说,类似移动语义将该对象交给你,原来什么状态的就处于什么状态。仍需注意一点:调用release必须手动上锁解锁,凡是没上锁或者忘记解锁,都会出现代码不稳定甚至出现崩溃(大部分情况)。
- 9)unique_lock所有权的传递:1)利用移动语义。2)利用匿名对象将函数内的局部对象所有权调用移动语义传出外部。并且都可以提前释放锁。再强调一点:只有std::adopt_lock宏是无法提前释放锁的。
- 10)个人建议:开发时我们只需要用unique_lock的std::defer_lock宏即可,或者直接使用lock_guard,已经完全足够我们使用各个方面。