2

多线程05:unique_lock详解 - D-booker

 1 year ago
source link: https://www.cnblogs.com/D-booker/p/16261987.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

📕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转移语义调用移动构造函数!


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK