std::mutex和lock系列
1. std::mutex：独占的互斥量，不能递归使用。下面是它的类的部分定义：
class mutex
{
public:
// std::mutex不支持拷贝和赋值操作。
mutex(const mutex&) = delete;
mutex& operator=(const mutex&) = delete;
constexpr mutex() noexcept; // 构造函数：新的对象是未锁的
~mutex();
public:
void lock(); // 上锁。会有三种情况
// (1) 如果该互斥量当前没有被锁住，则调用线程将该互斥量锁住，直到调用unlock之前，该线程一直拥有该锁
// (2) 如果当前互斥量被其他线程锁住，则当前的调用线程被阻塞住
// (3)如果当前互斥量被当前调用线程锁住，则会产生死锁(deadlock)。
void unlock(); // 解锁
bool try_lock(); // 尝试上锁。成功，返回true。失败时返回false，但不阻塞。会有三种情况
// (1) 如果当前互斥量没被其他线程占有，则锁住互斥量，直到该线程调用unlock
// (2) 如果当前互斥量被其他线程占用，则调用线程返回false，且不会被阻塞
// (3) 如果互斥量己被当前线程锁住，则会产生死锁
};
为什么有些类会去禁止拷贝和赋值呢？主要是防止浅拷贝的问题，因为类中如果有指针的话，浅拷贝方式的结果是两个不同对象的指针
指向同一块内存区域，容易出现访问冲突，多次delete等错误，不是我们所希望的。
1）互斥量不允许拷贝，也不允许移动。新创建的互斥量对象是未上锁的。
2）lock和unlock必须成对出现，否则可能引起未定义行为。
注：实践中不推荐直接去调用成员函数lock()，调用lock()就意味着，必须在每个函数出口都要去调用unlock()，也包括异常的情况。
如果程序员没有进行unlock或者因为异常无法unlock，那么系统就会发生死锁。针对这个问题，C++11中引入了std::unique_lock
与std::lock_guard两种数据结构。通过对lock和unlock进行一次薄的封装(只是包装，真正的加锁和解锁还都是mutex完成的)，
实现自动unlock的功能。
2. std::lock_guard：C++标准库为互斥量提供了一个RAII语法的模板类std::lock_guard，在构造时就能提供已锁的互斥量，并在析构的时候
进行解锁，从而保证了一个已锁互斥量能被正确解锁(自解锁)，不会因为某个线程异常退出而影响其他线程。下面是它的类的部分定义。
struct adopt_lock_t {}; // 空的标记类
constexpr adopt_lock_t adopt_lock {}; // 常量对象
template <class _Mutex>
class lock_guard
{
public:
using mutex_type = _Mutex;
explicit lock_guard(_Mutex& _Mtx) : _MyMutex(_Mtx) { _MyMutex.lock(); } // 构造，并加锁
lock_guard(_Mutex& _Mtx, adopt_lock_t) : _MyMutex(_Mtx) {} // 只构造，不加锁
~lock_guard() noexcept { _MyMutex.unlock(); } // unlock
lock_guard(const lock_guard&) = delete;
lock_guard& operator=(const lock_guard&) = delete;
private:
_Mutex& _MyMutex;
};
1）lock_guard对象不可拷贝和移动。
2）它有两个重载的构造函数，其中lock_gurad(_Mutex&)会自动对_Mutex进行加锁，而lock_gurad(_Mutex&,adopt_lock_t)则只构造
但不加锁，因此需要在某个时候通过调用_Mutex本身的lock()进行上锁。(说明：adopt_lock_t是个空的标签类，起到通过标签来重载构造函数的作用)。
3）在lock_gurad对象的生命周期内，它所管理的Mutex对象会一直保持上锁状态，直至生命周期结束后才被解锁。不需要，也无法手动通过lock_gurad对
Mutex进行上锁和解锁操作。从总体上而言，没有给程序员提供足够的灵活度来对互斥量的进行上锁和解锁控制。
3. std::unique_lock：std::unique_lock 与std::lock_guard都能实现自动加锁与解锁功能，但是std::unique_lock要比std::lock_guard更
灵活，但是更灵活的代价是占用空间相对更大一点且相对更慢一点。下面是它的类的部分定义：
// 空的标记类
struct adopt_lock_t {};
struct defer_lock_t {};
struct try_to_lock_t {};
// 常量对象
constexpr adopt_lock_t adopt_lock {};
constexpr defer_lock_t defer_lock {};
constexpr try_to_lock_t try_to_lock {};
template <class _Mutex>
class unique_lock { // 在析构函数中自动解锁mutex
public:
using mutex_type = _Mutex;
unique_lock() noexcept : _Pmtx(nullptr), _Owns(false) { // 默认构造函数
}
explicit unique_lock(_Mutex& _Mtx) : _Pmtx(_STD addressof(_Mtx)), _Owns(false) { // 构造并上锁。
_Pmtx->lock(); // 如果其他unique_lock己拥有该_Mtx，则会阻塞等待
_Owns = true; // 成功获取锁，拥有锁的所有权。
}
unique_lock(_Mutex& _Mtx, adopt_lock_t)
: _Pmtx(_STD addressof(_Mtx)), _Owns(true) { // 构造，并假定己上锁（mutex需要在外面事先被锁住）。注意拥有锁的所有权
}
unique_lock(_Mutex& _Mtx, defer_lock_t) noexcept
: _Pmtx(_STD addressof(_Mtx)), _Owns(false) { // 构造，但不上锁。false表示并未取得锁的所有权。
}
unique_lock(_Mutex& _Mtx, try_to_lock_t)
: _Pmtx(_STD addressof(_Mtx)), _Owns(_Pmtx->try_lock()) { // 构造，并尝试上锁。如果上锁不成功，并不会阻塞当前线程
}
//支持移动构造
unique_lock(unique_lock&& _Other) noexcept : _Pmtx(_Other._Pmtx), _Owns(_Other._Owns) { // 移动拷贝，destructive copy
_Other._Pmtx = nullptr; // 失去对原mutex的所有权
_Other._Owns = false;
}
//支持移动赋值
unique_lock& operator=(unique_lock&& _Other) { // 移动赋值， destructive copy
if (this != _STD addressof(_Other)) { // different, move contents
if (_Owns) {
_Pmtx->unlock();
}
_Pmtx = _Other._Pmtx;
_Owns = _Other._Owns;
_Other._Pmtx = nullptr;
_Other._Owns = false;
}
return *this;
}
~unique_lock() noexcept { // clean up
if (_Owns) {
_Pmtx->unlock(); // 析构函数中解锁
}
}
unique_lock(const unique_lock&) = delete;
unique_lock& operator=(const unique_lock&) = delete;
void lock() { // lock the mutex
_Validate();
_Pmtx->lock();
_Owns = true;
}
_NODISCARD bool try_lock() { // try to lock the mutex
_Validate();
_Owns = _Pmtx->try_lock();
return _Owns;
}
void unlock() { // try to unlock the mutex
if (!_Pmtx || !_Owns) {
_THROW(system_error(_STD make_error_code(errc::operation_not_permitted)));
}
_Pmtx->unlock();
_Owns = false;
}
void swap(unique_lock& _Other) noexcept { // swap with _Other
_STD swap(_Pmtx, _Other._Pmtx);
_STD swap(_Owns, _Other._Owns);
}
_Mutex* release() noexcept { // 返回指向它所管理的 Mutex 对象的指针，并释放所有权
_Mutex* _Res = _Pmtx;
_Pmtx = nullptr;
_Owns = false;
return _Res;
}
_NODISCARD bool owns_lock() const noexcept { return _Owns; } // 返回当前 std::unique_lock 对象是否获得了锁
explicit operator bool() const noexcept { return _Owns; } // 返回当前 std::unique_lock 对象是否获得了锁
_NODISCARD _Mutex* mutex() const noexcept { return _Pmtx; } // return pointer to managed mutex
private:
_Mutex* _Pmtx;
bool _Owns; // 是否拥有锁（当mutex被lock时，为true；否则为false）
};
1）以独占所有权的方式管理Mutex对象的上锁和解锁操作，即没有其他的unique_lock对象同时拥有某个Mutex对象的所有权。
2）与std::lock_guard一样，在unique_lock生命期结束后，会对其所管理的Mutex进行解锁。(注意：unique_lock只对拥有所有权的mutex才会在析构函数中被自动unlock)。
3）这里再介绍下unique_lock的构造函数：
a. unique_lock()默认构造函数：新创建的unique_lock对象不管理任何Mutex对象。
b. unique_lock(_Mutex& m)：构造并上锁。如果此时某个另外的unique_lock己管理m对象，则当前线程会被阻塞。
c. unique_lock(_Mutex& m, adopt_lock_t)：构造，并假定m己上锁。（m需要事先被上锁，构造结束后unique_lock就拥有m的所有权）
d. unique_lock(_Mutex& _Mtx, defer_lock_t)：构造，但不上锁。对象创建以后，可以手动调用unique_lock的lock来上锁，才拥有_Mtx的所有权。
强调一下，只有拥有所有权的mutex才会在析构函数中被自动unlock。
e. unique_lock(_Mutex& _Mtx, try_to_lock_t)：构造，并尝试上锁。如果上锁不成功，并不会阻塞当前线程。
