unique_lock<mutex> myUniLock(myMutex)
lock_guard中也可以用这个参数;
表示这个互斥量已经被lock(),即不需要在构造函数中lock这个互斥量了,前提:必须提前lock;
adopt_lock就是起一种标记作用,标志效果:“假设调用方线程已经拥有了互斥的所有权(即已经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; //其他操作代码 } } }
unique_lock<mutex> myUniLock(myMutex, defer_lock); //加锁! myUniLock.lock(); //注意:可以不用自己解锁,myUniLock对象析构的时候会进行unlock()操作;
unique_lock<mutex> myUniLock(myMutex, defer_lock); myUniLock.lock();//加锁! //处理共享数据的代码 myUniLock.unlock();//解锁! //处理非共享数据的代码(可能很多) //....... myUniLock.lock();//加锁! //处理共享数据的代码 myUniLock.unlock();//解锁!
为什么有时候需要unlock():因为lock锁住的代码越多,锁的粒度越粗,执行效率就低;反而如果我们只锁住共享的代码,锁住代码少,锁的粒度细,执行效率高!
要选这合适的粒度:不能漏掉共享数据的保护,但是也不可以将其他不必要的代码加入!
这个操作和try_to_lock操作很像,个人感觉像是在defer_lock情况下加上这种不阻塞的功能;
unique_lock<mutex>myUniLock(myMutex);
相当于把myMutex和myUniLock绑定在了一起,而release()就是解除绑定,返回它所管理的mutex对象的指针,并释放所有权,不再指向mutex对象;mutex* ptx = myUniLock.release();
所有权由ptx接管,如果原来mutex对象进行了加锁,处于加锁状态,就需要ptx在后面进行解锁了;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转移语义调用移动构造函数!