C++并发与多线程学习笔记--unique

unique_lock 取代lock_quard
unique_lock 的第二个参数
- std::adopt_lock
- std::try_to_lock
- std::defer_lock
unique_lock的成员函数
- lock()
- unlock()
- try_to_lock()
- release()
unique_lock所有权的传递

unique_lock 取代lock_guard

应用场景：两个线程A、B，其中A对队列添加元素，B移除元素。

unique_lock是个类模板，工作中，一般使用lock_gard(推荐使用)，取代mutex的lock()和unlock()。unique_lock比lock_gard灵活许多，但是unique_lock效率差一点，并且内存占用多一点。

std::unique_lock<std::mutex> sbgard(mu_mutex);

unique_lock 的第二个参数

unique_lock比较灵活，主要是因为这个第二个参数。 lock_guard可以带第二个参数。

std::unique_lock<std::mutex> sbguard(my_mutex, std::adopt_lock);

　　std::adopt_lock这个参数表示标记作用，unique_lock支持更多参数，表示互斥量已经被lock了

std::adopt_lock:表示这个互斥量已经被Lock了，必须把互斥量提前lock，否则会报异常。这个标记的效果：假设调用方线程已经拥有了互斥的所有权，也就是说已经lock成功了，通知lock_guard不需要在构造函数中Lock这个互斥量了。unique_lock也是同样的功能，就是不希望在unique_lock()的构造函数中再次lock了。

std::adopt_lock

用adopt_lock的前提条件是要先给互斥量加锁，然后在后面的语句中不会再次lock()，即后续的std::lock_guard中才能使用std::adopt_lock这个参数，然后unique_lock自动unlock。

std::unique_lock<std::mutex> sbguard(my_mutex, std::adopt_lock);

　　如果另外一个线程A拿了锁之后，执行20s，然后这个线程B等待A释放锁。此时，A一直占用资源，B一直得不到资源，unique_lock如果一直拿不到锁，让它去先做别的事情，所以引入了try_to_lock。

std::try_to_lock

std::try_to_lcok会尝试用 mutex的lock()去锁定mutex，但是没有锁定成功，也会立即返回，并不会阻塞。用try_to_lock的前提是不能使用lock:

std::unique_lock<std::mutex> sbguard(my_mutex, std::try_to_lock);

　　a)注意，不能先去try_to_lock，尝试加锁。此时就有成功或者失败，尝试拿锁成功或者尝试拿锁失败。

　　b)如果拿到了锁，才能去操作共享数据(临界区)，sbguard.owns_lock拿到锁，就不能操作共享数据，可以做一些别的事情。

　　c)A拿到锁，sleep 20s，此时B拿不到锁，一直在等待。线程不需要一直等资源，通过sbguard.owns_lock的值进行判断。

std::defer_lock

前提：不能自己先lock，否者会出现异常。defer_lock的意思不需要给mutex加锁：初始化了没有加锁的mutex，没加锁的mutex，可以灵活地调用unique_lock的一些重要的成员函数。

std::unique_lock<std::mutex> sbguard(my_mutex, std::defer_lock);

　之后需要手动 lock，unlock在析构函数中自动执行了。

unique_lock的成员函数

a)lock()，加锁

b)unlock()，解锁

有lock就可以有unlock，不过在unique_lock中使用了锁，类的析构函数执行了解锁的操作。有的时候会出问题，但是实际上不稳定。有的时候可能临时需要处理一些其他事情。

lock()

//处理一些共享数据

unlock()

　　也可以用unqiue_lock，编码变得更加灵活：

std::unique_lock<std::mutex> sbguard(mutex);

lock();

//处理一些共享数据

unlock();

//处理一些非共享数据

lock();

////

////

　　此时unlock不必手工unlock，此时的unlock在unique_lock的析构函数中执行。

try_lock()

尝试给互斥量加锁，如果拿不到锁，则返回false，如果拿到了锁，返回true，函数不阻塞。

if(sbguard.try_lock()==true)

{

    //拿到锁了

    访问共享数据

}else

{

     //没拿到锁

}

release()

返回它所管理的mutex对象指针，并释放所有权，也就是说这个unique_lock和mutex不再有关系，严格区分unlock()和release()的区别。release()把绑在一起的东西解开了(解开关系)，unlock()是解开锁头。

如果原来mutex对象处于加锁状态，需要接管过来并负责解锁。

std::unique_lock<std::mutex> sbguard(my_mutex);

std::mutex *ptx = sbguard.release();

//此时sbguard和my_mutex的关系解除了，现在就有责任自己解锁my_mutex

//如果自己不解锁，那么就卡住了

解锁语法:自己负责my_mutex的解锁。

ptx->nulock();

　release()返回的是原始的mutex指针。

锁头锁住的代码的多少成为粒度，粒度一般用粗细来描述；

a)锁住代码少，粒度细，执行效率高。

b)锁住代码多，粒度粗，执行效率低。

要学会尽量选择合适粒度的代码进行保护。

unique_lock所有权的传递

unique_lock需要和mutex绑定到一起才是一个完整的unique_lock，应该是unique_lock需要管理一个mutex指针才能起作用。

所有权：指定unique_lock拥有mutex的所有权，unique_lock可以把所有用的所有权，可以转移给其他的unique_lock对象，所有权转移，mutex可以转移，但是不能复制

可以使用std::move(mutex)

std::unique_lock<std::mutex>  sbguard1(mutex);

std::unique_lock<std::mutex>  sbguard2(std::move(mutex));

　此时sbguard1为空，sbguard2接管了原来sbguard1和mutex的关系，其实就是新的unique_lock()指向了原来的mutex。

参考文献

https://blog.csdn.net/guanguanboy/article/details/100514731