【c++11】并发指南之mutex类与lock类

1  mutex类：

1.1 std::mutex，基本锁

1.2 std::recursive_mutex，递归锁 

std::recursive_mutex 与 std::mutex 一样，也是一种可以被上锁的对象，但是和 std::mutex 不同的是，std::recursive_mutex 允许同一个线程对互斥量多次上锁（即递归上锁），来获得对互斥量对象的多层所有权，std::recursive_mutex 释放互斥量时需要调用与该锁层次深度相同次数的 unlock()，可理解为 lock() 次数和 unlock() 次数相同，除此之外，std::recursive_mutex 的特性和 std::mutex 大致相同。

1.3 std::time_mutex，定时锁

std::time_mutex 比 std::mutex 多了两个成员函数，try_lock_for()，try_lock_until()。

try_lock_for 函数接受一个时间范围，表示在这一段时间范围之内线程如果没有获得锁则被阻塞住（与 std::mutex 的 try_lock() 不同，try_lock 如果被调用时没有获得锁则直接返回 false），如果在此期间其他线程释放了锁，则该线程可以获得对互斥量的锁，如果超时（即在指定时间内还是没有获得锁），则返回 false。

try_lock_until 函数则接受一个时间点作为参数，在指定时间点未到来之前线程如果没有获得锁则被阻塞住，如果在此期间其他线程释放了锁，则该线程可以获得对互斥量的锁，如果超时（即在指定时间内还是没有获得锁），则返回 false。1.4 std::recursive_timed_mutex，定时递归锁

1.2 mutex的成员函数：

1.2.1 构造函数：std::mutex不支持copy和move操作，最初的std::mutex对象是处于unlocked状态。

 1.2.2 lock函数：

 (1).如果该互斥量当前没有被锁住，则调用线程将该互斥量锁住，直到调用 unlock之前，该线程一直拥有该锁。

 (2).如果当前互斥量被其他线程锁住，则当前的调用线程被阻塞住。

 (3).如果当前互斥量被当前调用线程锁住，则会产生死锁(deadlock)。

1.2.3、unlock函数：解锁，释放调用线程对该互斥锁的所有权。

1.2.4、try_lock：尝试锁住互斥量，如果互斥量被其他线程占有，则当前线程也不会被阻塞。线程调用该函数也会出现下面 3 种情况，

(1). 如果当前互斥量没有被其他线程占有，则该线程锁住互斥量，直到该线程调用 unlock 释放互斥量。

(2). 如果当前互斥量被其他线程锁住，则当前调用线程返回 false，而并不会被阻塞掉。(与lock函数不同的一点，非阻塞式)

(3). 如果当前互斥量被当前调用线程锁住，则会产生死锁(deadlock)。

1.2.5、native_handle：返回当前句柄。

2  lock类

2.1 std::lock_guard，与 Mutex RAII 相关，方便线程对互斥量上锁。

区域锁lock_guard使用起来比较简单，除了构造函数外没有其他member function，在整个区域都有效。在某个 lock_guard 对象的声明周期内，它所管理的锁对象会一直保持上锁状态；而 lock_guard 的生命周期结束之后，它所管理的锁对象会被解锁。在 lock_guard 对象构造时，传入的 Mutex 对象(即它所管理的 Mutex 对象)会被当前线程锁住。在lock_guard 对象被析构时，它所管理的 Mutex 对象会自动解锁，由于不需要程序员手动调用 lock 和 unlock 对 Mutex 进行上锁和解锁操作，因此这也是最简单安全的上锁和解锁方式，尤其是在程序抛出异常后先前已被上锁的 Mutex 对象可以正确进行解锁操作，极大地简化了程序员编写与 Mutex 相关的异常处理代码。

值得注意的是，lock_guard 对象并不负责管理 Mutex 对象的生命周期，lock_guard 对象只是简化了 Mutex 对象的上锁和解锁操作，方便线程对互斥量上锁，即在某个 lock_guard 对象的声明周期内，它所管理的锁对象会一直保持上锁状态；而 lock_guard 的生命周期结束之后，它所管理的锁对象会被解锁。

lock_guard 构造函数如下表所示：

locking (1)	explicit lock_guard (mutex_type& m);
adopting (2)	lock_guard (mutex_type& m, adopt_lock_t tag);
copy [deleted](3)	lock_guard (const lock_guard&) = delete;

 (1)locking初始化：lock_guard 对象管理 Mutex 对象 m，并在构造时对 m 进行上锁（调用 m.lock()), 

 (2)lock_guard 对象管理 Mutex 对象 m，与 locking 初始化(1) 不同的是， Mutex 对象 m 已被当前线程锁住。

 (3)lock_guard 对象的拷贝构造和移动构造(move construction)均被禁用，因此 lock_guard 对象不可被拷贝构造或移动构造。

用法：

std::mutex mtx; //通常声明为全局的mutex
std::lock_guard<std::mutex> lck(mtx);  

2.2 std::unique_lock，与 Mutex RAII 相关，方便线程对互斥量上锁，但提供了更好的上锁和解锁控制。

    unique_lock 对象以独占所有权的方式（ unique owership）管理 mutex 对象的上锁和解锁操作，所谓独占所有权，就是没有其他的 unique_lock 对象同时拥有某个 mutex 对象的所有权。

    在构造(或移动(move)赋值)时，unique_lock 对象需要传递一个 Mutex 对象作为它的参数，新创建的 unique_lock 对象负责传入的 Mutex 对象的上锁和解锁操作。

    std::unique_lock 对象也能保证在其自身析构时它所管理的 Mutex 对象能够被正确地解锁（即使没有显式地调用 unlock 函数）。因此，和 lock_guard 一样，这也是一种简单而又安全的上锁和解锁方式，尤其是在程序抛出异常后先前已被上锁的 Mutex 对象可以正确进行解锁操作，极大地简化了程序员编写与 Mutex 相关的异常处理代码。

    unique_lock 对象同样也不负责管理 Mutex 对象的生命周期，unique_lock 对象只是简化了 Mutex 对象的上锁和解锁操作，方便线程对互斥量上锁，即在某个 unique_lock 对象的声明周期内，它所管理的锁对象会一直保持上锁状态；而 unique_lock 的生命周期结束之后，它所管理的锁对象会被解锁，这一点和 lock_guard 类似

    unique_lock的函数

default (1)	unique_lock() noexcept;
locking (2)	explicit unique_lock(mutex_type& m);
try-locking (3)	unique_lock(mutex_type& m, try_to_lock_t tag);
deferred (4)	unique_lock(mutex_type& m, defer_lock_t tag) noexcept;
adopting (5)	unique_lock(mutex_type& m, adopt_lock_t tag);
locking for (6)	template <class Rep, class Period> unique_lock(mutex_type& m, const chrono::duration<Rep,Period>& rel_time);
locking until (7)	template <class Clock, class Duration> unique_lock(mutex_type& m, const chrono::time_point<Clock,Duration>& abs_time);
copy [deleted] (8)	unique_lock(const unique_lock&) = delete;
move (9)	unique_lock(unique_lock&& x);

下面我们来分别介绍以上各个构造函数：

(1) 默认构造函数

新创建的 unique_lock 对象不管理任何 Mutex 对象。

(2) locking 初始化

新创建的 unique_lock 对象管理 Mutex 对象 m，并尝试调用 m.lock() 对 Mutex 对象进行上锁，如果此时另外某个 unique_lock 对象已经管理了该 Mutex 对象 m，则当前线程将会被阻塞。

(3) try-locking 初始化

新创建的 unique_lock 对象管理 Mutex 对象 m，并尝试调用 m.try_lock() 对 Mutex 对象进行上锁，但如果上锁不成功，并不会阻塞当前线程。

(4) deferred 初始化

新创建的 unique_lock 对象管理 Mutex 对象 m，但是在初始化的时候并不锁住 Mutex 对象。 m 应该是一个没有当前线程锁住的 Mutex 对象。

(5) adopting 初始化

新创建的 unique_lock 对象管理 Mutex 对象 m， m 应该是一个已经被当前线程锁住的 Mutex 对象。(并且当前新创建的 unique_lock 对象拥有对锁(Lock)的所有权)。

(6) locking 一段时间(duration)

新创建的 unique_lock 对象管理 Mutex 对象 m，并试图通过调用 m.try_lock_for(rel_time) 来锁住 Mutex 对象一段时间(rel_time)。

(7) locking 直到某个时间点(time point)

新创建的 unique_lock 对象管理 Mutex 对象m，并试图通过调用 m.try_lock_until(abs_time) 来在某个时间点(abs_time)之前锁住 Mutex 对象。

(8) 拷贝构造 [被禁用]

unique_lock 对象不能被拷贝构造。

(9) 移动(move)构造

新创建的 unique_lock 对象获得了由 x 所管理的 Mutex 对象的所有权(包括当前 Mutex 的状态)。调用 move 构造之后， x 对象如同通过默认构造函数所创建的，就不再管理任何 Mutex 对象了。

综上所述，由 (2) 和 (5) 创建的 unique_lock 对象通常拥有 Mutex 对象的锁。而通过 (1) 和 (4) 创建的则不会拥有锁。通过 (3)，(6) 和 (7) 创建的 unique_lock 对象，则在 lock 成功时获得锁。

#include <iostream>  
#include <thread>  
#include <mutex>  
std::mutex foo,bar;  
void task_a() {  
    std::lock(foo, bar);//foo和bar已被当前线程锁住  
    /******************************************************* 
    *adopting 初始化: 
    *adopt_lock 是一个常量对象,通常作为参数传入给unique_lock 或  
    *lock_guard 的构造函数。新创建的 unique_lock 对象管理 Mutex  
    *对象 m， m 应该是一个已经被当前线程锁住的 Mutex 对象。 
    *******************************************************/  
    std::unique_lock<std::mutex> lck1(foo, std::adopt_lock);  
    std::unique_lock<std::mutex> lck2(bar, std::adopt_lock);  
    std::cout << "task a\n";  
}  
void task_b() {  
    //新创建的 unique_lock 对象不管理任何 Mutex 对象。  
    std::unique_lock<std::mutex> lck1, lck2;  
    /****************************************************** 
    * deferred 初始化: 
    *新创建的 unique_lock 对象管理 Mutex 对象 m，但是在初始化 
    *的时候并不锁住 Mutex 对象。 m 应该是一个没有当前线程锁住的  
    *Mutex 对象。 
    ******************************************************/  
    lck1 = std::unique_lock<std::mutex>(bar, std::defer_lock);  
    lck2 = std::unique_lock<std::mutex>(foo, std::defer_lock);  
    std::lock(lck1, lck2);  
    std::cout << "task b\n";  
}  
int main() {  
    std::thread th1(task_a);  
    std::thread th2(task_b);  
    th1.join();  
    th2.join();  
    system("pause");  
    return EXIT_SUCCESS;  
}

 通过try_lock_for/try_lock_until则可以控制加锁的等待时间，此时这种锁为乐观锁。