本文分析的是llvm libc++的实现：http://libcxx.llvm.org/

C++11中的各种mutex, lock对象，实际上都是对posix的mutex，condition的封装。不过里面也有很多细节值得学习。

std::mutex

先来看下std::mutex：

包增了一个pthread_mutex_t __m_，很简单，每个函数该干嘛就干嘛。

三种锁状态：std::defer_lock, std::try_to_lock, std::adopt_lock

std::lock_guard

这个类比较重要，因为我们真正使用lock的时候，大部分都是要用这个。

这个类其实很简单：

在构造函数里调用 mutext.lock()，
在释构函数里，调用了mutex.unlock() 函数。

因为C++会在函数抛出异常时，自动调用作用域内的变量的析构函数，所以使用std::lock_guard可以在异常时自动释放锁，这就是为什么要避免直接使用mutex的函数，而是要用std::lock_guard的原因了。

注意，std::lock_guard的两个构造函数，当只传递mutex时，会在构造函数时调用mutext.lock()来获得锁。

当传递了adopt_lock_t时，说明调用者已经拿到了锁，所以不再尝试去获得锁。

std::unique_lock

unique_lock实际上也是一个包装类，起名为unique可能是和std::lock函数区分用的。
注意，多了一个owns_lock函数和release()函数，这两个在std::lock函数会用到。

owns_lock函数用于判断是否拥有锁；

release()函数则放弃了对锁的关联，当析构时，不会去unlock锁。
再看下unique_lock的实现，可以发现，上面的三种类型就是用来做偏特化用的：

std::lock和std::try_lock函数

上面的都是类对象，这两个是函数。

std::lock和std::try_lock函数用于在同时使用多个锁时，防止死锁。这个实际上很重要的，因为手写代码来处理多个锁的同步问题，很容易出错。

要注意的是std::try_lock函数的返回值：

当成功时，返回-1；

当失败时，返回第几个锁没有获取成功，以0开始计数；

首先来看下只有两个锁的情况，代码虽然看起来比较简单，但里面却有大文章：

上面的lock函数用尝试的办法防止了死锁。

上面是两个锁的情况，那么在多个参数的情况下呢？

先来看下std::try_lock函数的实现：

里面递归地调用了try_lock函数自身，如果全部锁都获取成功，则依次把所有的unique_lock都release掉。

如果有失败，则计数失败的次数，最终返回。

再来看多参数的std::lock的实现：

可以看到多参数的std::lock的实现是：

先获取一个锁，然后再调用std::try_lock去获取剩下的锁，如果失败了，则下次先获取上次失败的锁。

重复上面的过程，直到成功获取到所有的锁。

上面的算法用比较巧妙的方式实现了参数的轮转。

std::timed_mutex

std::timed_mutex   是里面封装了mutex和condition，这样就两个函数可以用：
try_lock_for
try_lock_until 

实际上是posix的mutex和condition的包装。

std::recursive_mutex和std::recursive_timed_mutex

这两个实际上是std::mutex和std::timed_mutex 的recursive模式的实现，即锁得获得者可以重复多次调用lock()函数。

和posix mutex里的recursive mutex是一样的。

看下std::recursive_mutex的构造函数就知道了。

std::cv_status

这个用来表示condition等待返回的状态的，和上面的三个表示lock的状态的用途差不多。

std::condition_variable

包装了posix condition variable。

里面的函数都是符合直觉的实现，值得注意的是：

cv_status是通过判断时间而确定的，如果超时的则返回cv_status::timeout，如果没有超时，则返回cv_status::no_timeout。

condition_variable::wait_until函数可以传入一个predicate，即一个用户自定义的判断是否符合条件的函数。这个也是很常见的模板编程的方法了。

std::condition_variable_any

std::condition_variable_any的接口和std::condition_variable一样，不同的是std::condition_variable只能使用std::unique_lock<std::mutex>，而std::condition_variable_any可以使用任何的锁对象。

下面来看下为什么std::condition_variable_any可以使用任意的锁对象。

可以看到，在std::condition_variable_any里，用shared_ptr<mutex>  __mut_来包装了mutex。所以一切都明白了，回顾std::unique_lock<std::mutex>，它包装了mutex，当析构时自动释放mutex。在std::condition_variable_any里，这份工作让shared_ptr<mutex>来做了。

因此，也可以很轻松得出std::condition_variable_any会比std::condition_variable稍慢的结论了。

其它的东东：

sched_yield()函数的man手册：
sched_yield() causes the calling thread to relinquish the CPU.  The thread is moved to the end of the queue for its
       static priority and a new thread gets to run.  

在C++14里还有std::shared_lock和std::shared_timed_mutex，但是libc++里还没有对应的实现，因此不做分析。

总结

llvm libc++中的各种mutex, lock, condition variable实际上是封闭了posix里的对应实现。封装的技巧和一些细节值得细细推敲学习。

看完了实现源码之后，对于如何使用就更加清晰了。

参考：

http://en.cppreference.com/w/cpp

http://libcxx.llvm.org/

互斥锁有可重入、不可重入之分。C++标准库中用mutex表示不可重入的互斥锁,用recursive_mutex表示可重入的互斥锁。为这两个类增加根据时间来阻塞线程的能力，就又有了两个新的互斥锁：timed_mutex(不可重入的锁)、recursive_timed_mutex(可重入的锁)。

互斥锁单独使用时主要是为了使对共享资源的互斥使用，即同时只能有一个线程使用，以防止同时使用可能造成的数据问题。

C++标准库的所有mutex都是不可拷贝的，也不可移动。

mutex基本操作

上锁 lock 如果mutex未上锁，则将其上锁。否则如果已经其它线程lock，则阻塞当前线程。

上锁 try_lock 如果mutex未上锁，则将其上锁。否则返回false，并不阻塞当前线程。

解锁 unlock  如果mutex被当前线程锁住，则将其解锁。否则，是未定义的行为。

timed_mutex在mutex的基础上增加了以下两个操作

try_lock_for(duration) 如果timed_mutex未上锁，则将其上锁，否则阻塞当前线程，但最长只阻塞duration表示的时间段。

try_lock_until(time_point) 如果timed_mutex未上锁，则将其上锁，否则阻塞当前线程，但最长只会阻塞到time_point表示的时间点就不再阻塞。

try_lock_for/until可以检测到死锁的出现，这是目前想到的一种用途。

if(!try_lock_for(chrono::hours(1)))
{
  throw "出现死锁!";  
}

可重入的锁 recursive_mutex、recursive_timed_mutex与对应的mutex、timed_mutex操作一致。不同点在于，不可重入的锁在lock或try_lock一个已经被当前线程lock的锁时会导致死锁，而可重入的锁不会。

辅助类

template<class Mutex> class lock_guard;

lock_guard用于脱离lock_guard对象生存期后自动对互斥锁进行解锁操作。

explicit lock_guard(mutex_type &m);对象创建时执行 m.lock(),对象销毁时执行 m.unlock()

explicit lock_guard(mutex_type &m,adpot_lock_t tag);对象创建不执行lock,对象销毁时执行 m.unlock()。所以m应该是一个已经被当前线程lock的互斥锁。

template<class Mutex> class unique_lock;

unique_lock()noexcept;不管理任何锁。

explicit unique_lock(mutex_type &m);对象创建时执行 m.lock()。

unique_lock(mutex_type &m,try_to_lock_t tag);对象创建时执行 m.try_lock()。

unique_lock(mutex_type &m,defer_lock_t tag);对象创建时不进行上锁操作，m要满足没有被当前线程锁住的条件。

unique_lock(mutex_type &m,adopt_lock_t tag);对象创建时不进行上锁操作，m要满足已经被当前线程锁住的条件。

unique_lock(mutex_type &m,const duration & real_time);对象创建时执行 m.try_lock_for(real_time)。

unique_lock(mutex_type &m,const time_point & abs_time);对象创建时执行 m.try_lock_until(abs_time)。 

unique_lock(unique_lock &&);移动构造

操作：unique_lock具备它所管理的锁的所有操作 lock、unlock、try_lock、try_lock_for、try_lock_until。

mutex_type *release(); 不再管理互斥锁。

void swap(unique_lock &);交换管理的互斥锁。

bool owns_lock() 用于探测unique_lock是否管理着一个互斥锁且其处于上锁状态。bool operate bool() 与owns_lock等同。

mutex_type * mutex();用于返回管理的互斥锁的指针，但仍对其进行管理。

在unique_lock销毁的时候，owns_lock为真才会执行unlock。

总的来说，lock_guard在时空间效率上比较高，但功能单一。unique_lock功能多，使用灵活，但时空间效率不如lock_guard。如果使用了辅助类来管理互斥锁，就不要直接操作锁了，否则容易引发混乱，产生BUG。

辅助函数

template <class Mutex1, class Mutex2, class... Mutexes>
int try_lock (Mutex1& a, Mutex2& b, Mutexes&... cde);

根据参数顺序对多个锁进行上锁，如果成功锁住所有锁，返回-1，返回值大于0表示失败的锁的位置号。

template <class Mutex1, class Mutex2, class... Mutexes>
void lock (Mutex1& a, Mutex2& b, Mutexes&... cde);

对多个锁进行上锁，该函数是阻塞的。另，它保证发生异常的情况下已经上锁的锁会被解锁。