您的位置:首页 > 产品设计 > UI/UE

多线程05:unique_lock详解

2022-05-12 12:26 281 查看 https://www.cnblogs.com/d-book

📕unique_lock详解

一、unique_lock取代lock_guard

  • unique_lock是个类模板**,实际应用中,一般lock_guard(推荐使用)**;lock_guard取代了mutex和的lock()和nulock(), 而unique_lock也取代mutex和的lock()和nulock();
  • unique_lock比lock_guard灵活很多(多出来很多用法),效率差一点,内存占用多一点;
  • 使用:
    unique_lock<mutex> myUniLock(myMutex)

二、unique_lock的第二个参数

2.1 std:: adopt_lock

  • lock_guard中也可以用这个参数

  • 表示这个互斥量已经被lock(),即不需要在构造函数中lock这个互斥量了,前提:必须提前lock;

  • adopt_lock就是起一种标记作用,标志效果:“假设调用方线程已经拥有了互斥的所有权(即已经lock()成功了的);

2.2 std::try_to_lock

  • 意思:我们会尝试用mutex的lock()去锁定这个mutex,但是不同的是,如果没有锁定成功,也会立即返回,不会阻塞继续尝试锁定;
  • 搭配owns_lock()方法判断是否拿到锁,如拿到返回true,没有拿到返回false;
  • 前提:当下线程再使用该参数前,不要使用lock,不然没有意义,因为肯定拿不到;
  • 使用try_to_lock的原因:是防止其他的线程锁定mutex太长时间,导致本线程一直阻塞在lock这个地方。

例子:

//写入数据函数;
void inMsgPro() {

for (int i = 0; i < 100; ++i) {
cout << "inMsgPro()执行,插入元素" << i << endl;

unique_lock<mutex> myUniLock(mutex1, try_to_lock);
if (myUniLock.owns_lock() == true) {
msgRecvQueue.push(i);
}
else {
cout << "拿不到锁" << endl;
//其他操作代码
}

}
}

2.3 std::defer_lock

  • 意思:加上defer_lock是初始化了一个没有加锁的mutex
  • 前提:当下线程再使用该参数前,不要使用lock,不然没有意义,逻辑相悖;
  • 使用std::defer_lock的原因:是以后可以调用unique_lock的一些方法

三、unique_lock的成员函数(前三个要与defer_lock联合使用)

3.1 lock(): 加锁

unique_lock<mutex> myUniLock(myMutex, defer_lock);
//加锁!
myUniLock.lock();
//注意:可以不用自己解锁,myUniLock对象析构的时候会进行unlock()操作;

3.2 unlock(): 解锁

unique_lock<mutex> myUniLock(myMutex, defer_lock);
myUniLock.lock();//加锁!
//处理共享数据的代码
myUniLock.unlock();//解锁!
//处理非共享数据的代码(可能很多)
//.......
myUniLock.lock();//加锁!
//处理共享数据的代码
myUniLock.unlock();//解锁!

为什么有时候需要unlock():因为lock锁住的代码越多,锁的粒度越粗,执行效率就低;反而如果我们只锁住共享的代码,锁住代码少,锁的粒度细,执行效率高!

要选这合适的粒度:不能漏掉共享数据的保护,但是也不可以将其他不必要的代码加入!

3.3 try_lock(): 尝试给互斥量加锁

  • 如果拿到锁,则返回true,如果拿不到锁,函数不阻塞,返回false,继续往下执行;

这个操作和try_to_lock操作很像,个人感觉像是在defer_lock情况下加上这种不阻塞的功能;

3.4 release():

  • unique_lock<mutex>myUniLock(myMutex);
    相当于把myMutex和myUniLock绑定在了一起,而release()就是解除绑定,返回它所管理的mutex对象的指针,并释放所有权,不再指向mutex对象;
  • mutex* ptx = myUniLock.release();
    所有权由ptx接管,如果原来mutex对象进行了加锁,处于加锁状态,就需要ptx在后面进行解锁了;
  • 注意release()和unlock()的区别,一个是释放了所有权,一个只是释放锁,该对象还是和mutex绑定着;

四、unique_lock所有权的传递

unique_lock<mutex> myUniLock(myMutex);
把myMutex和myUniLock绑定在了一起,也就是myUniLock拥有myMutex的所有权

所有权转移方式:

①使用move转移:

所有权可以转移,但是不能复制!

unique_lock<mutex> myUniLock(myMutex);
//unique_lock<mutex> myUniLock2(myUniLock); //复制所有权是非法,一种拷贝构造;
unique_lock<mutex> myUniLock2(std::move(myUniLock));//移动语言,传右值,调用带右值引用的拷贝构造,将myUniLock2和myMutex绑定一起,而myUniLock指向空!

②在函数中return一个临时变量,即可以实现转移

unique_lock<mutex> rtn_unique_lock()
{
unique_lock<mutex> myUniLock(myMutex);//位置1
//移动构造函数那里讲从函数返回一个局部的unique_lock对象是可以的
//返回这种局部对象会导致系统生成临时的unique_lock对象,并调用unique_lock的移动构造函数
return myUniLock;
}
// 然后就可以在外层调用,在myUniLock2具有对myMutex的所有权
std::unique_lock<std::mutex> myUniLock2 = rtn_unique_lock();//位置2

其实这种方法的本质是:用在函数中创建临时变量(位置1),将局部临时变量拷贝一份给调用函数(位置2,这里又有一份临时变量),最后再由位置2的临时变量 赋值给myUniLock2!

可以看出,是非常消耗内存,浪费资源时间的,因为位置1、2的临时对象构造马上又析构了,后面也不会用它们。所以强烈推荐使用move转移语义调用移动构造函数!

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: