Boost C++ 库

例如，考虑对银行账户类进行建模，该类支持从多个位置同时存款和取款（可以说是多线程编程的“Hello, World”）。

这里，组件是 Callable 概念的模型。

在 C++11 (Boost) 中，组件的并发执行是通过 std::thread(boost::thread) 实现的

boost::thread thread1(S);

其中 S 是 Callable 的模型。 这个表达式的意思是 S() 的执行将与执行该表达式的当前执行线程同时进行。

以下示例包括一个人的银行帐户 (Joe) 和两个组件，一个对应于银行代理向 Joe 的帐户存款，另一个代表 Joe。 Joe 只会从帐户中取款

class BankAccount;

BankAccount JoesAccount;

void bankAgent()
{
    for (int i =10; i>0; --i) {
        //...
        JoesAccount.Deposit(500);
        //...
    }
}

void Joe() {
    for (int i =10; i>0; --i) {
        //...
        int myPocket = JoesAccount.Withdraw(100);
        std::cout << myPocket << std::endl;
        //...
    }
}

int main() {
    //...
    boost::thread thread1(bankAgent); // start concurrent execution of bankAgent
    boost::thread thread2(Joe); // start concurrent execution of Joe
    thread1.join();
    thread2.join();
    return 0;
}

银行代理会不时地将 500 美元存入 JoesAccount。Joe 也会类似地从他的帐户中取出 100 美元。 这些句子描述了 bankAgent 和 Joe 是同时执行的。

只要组件 bankAgent 和 Joe 不在同一时间访问 JoesAccount，上面的例子就可以很好地工作。 然而，不能保证这种情况不会发生。 我们可以使用互斥量来保证对每个银行的独占访问。

class BankAccount {
    boost::mutex mtx_;
    int balance_;
public:
    void Deposit(int amount) {
        mtx_.lock();
        balance_ += amount;
        mtx_.unlock();
    }
    void Withdraw(int amount) {
        mtx_.lock();
        balance_ -= amount;
        mtx_.unlock();
    }
    int GetBalance() {
        mtx_.lock();
        int b = balance_;
        mtx_.unlock();
        return b;
    }
};

执行 Deposit 和 Withdraw 操作将不再能够同时访问余额。

互斥量是获取同步的简单而基本的机制。 在上面的例子中，相对容易确信同步工作正常（在没有异常的情况下）。 在具有多个并发对象和多个共享对象的系统中，可能难以通过互斥量来描述同步。 大量使用互斥量的程序可能难以阅读和编写。 相反，我们将引入许多通用类来处理更复杂的同步和通信形式。

使用 RAII 习惯用法，我们可以使用作用域锁简化很多，在下面的代码中，guard 的构造函数锁定传入的对象 mtx_，而 guard 的析构函数解锁 mtx_。

class BankAccount {
    boost::mutex mtx_; // explicit mutex declaration 
    int balance_;
public:
    void Deposit(int amount) {
        boost::lock_guard<boost::mutex> guard(mtx_);
        balance_ += amount;
    }
    void Withdraw(int amount) {
        boost::lock_guard<boost::mutex> guard(mtx_);
        balance_ -= amount;
    }
    int GetBalance() {
        boost::lock_guard<boost::mutex> guard(mtx_);
        return balance_;
    }
};

对象级锁定习惯用法并未涵盖线程模型的全部丰富性。 例如，当您尝试协调多对象事务时，上面的模型很容易出现死锁。 尽管如此，对象级锁定在许多情况下都很有用，并且与其他机制结合使用可以为面向对象程序中的许多线程访问问题提供令人满意的解决方案。

上面的 BankAccount 类使用内部锁定。 基本上，使用内部锁定的类保证对其公共成员函数的任何并发调用都不会破坏该类的实例。 这通常通过让每个公共成员函数在进入时获取对象的锁来确保。 这样，对于该类的任何给定对象，在任何时候只能有一个成员函数调用处于活动状态，因此操作可以很好地序列化。

这种方法实现起来相当容易，并且具有吸引人的简单性。 不幸的是，“简单”有时可能会演变成“过于简单”。

对于许多现实世界的同步任务，内部锁定是不够的。 想象一下，您想使用 BankAccount 类来实现 ATM 取款交易。 要求很简单。 ATM 交易包括两次提款 - 一次用于实际现金，一次用于 2 美元的手续费。 这两次提款必须严格按顺序出现； 也就是说，它们之间不能存在其他交易。

显而易见的实现是错误的

void ATMWithdrawal(BankAccount& acct, int sum) {
    acct.Withdraw(sum);
    // preemption possible
    acct.Withdraw(2);
}

问题是，在上述两次调用之间，另一个线程可以对帐户执行另一个操作，从而违反了第二个设计要求。

为了解决这个问题，让我们在两个操作期间从外部锁定帐户

void ATMWithdrawal(BankAccount& acct, int sum) {
    boost::lock_guard<boost::mutex> guard(acct.mtx_); 1
    acct.Withdraw(sum);
    acct.Withdraw(2);
}

请注意，上面的代码无法编译，mtx_ 字段是私有的。 我们有两种可能性

我们可以显式添加这些函数

class BankAccount {
    boost::mutex mtx_;
    int balance_;
public:
    void Deposit(int amount) {
        boost::lock_guard<boost::mutex> guard(mtx_);
        balance_ += amount;
    }
    void Withdraw(int amount) {
        boost::lock_guard<boost::mutex> guard(mtx_);
        balance_ -= amount;
    }
    void lock() {
        mtx_.lock();
    }
    void unlock() {
        mtx_.unlock();
    }
};

或从添加这些可锁定函数的类继承。

basic_lockable_adapter 类有助于将 BankAccount 类定义为

class BankAccount
: public basic_lockable_adapter<mutex>
{
    int balance_;
public:
    void Deposit(int amount) {
        boost::lock_guard<BankAccount> guard(*this);
        balance_ += amount;
    }
    void Withdraw(int amount) {
        boost::lock_guard<BankAccount> guard(*this);
        balance_ -= amount;
    }
    int GetBalance() {
        boost::lock_guard<BankAccount> guard(*this);
        return balance_;
    }
};

并且无法编译的代码变为

void ATMWithdrawal(BankAccount& acct, int sum) {
    boost::lock_guard<BankAccount> guard(acct);
    acct.Withdraw(sum);
    acct.Withdraw(2);
}

请注意，现在 acct 在已被 guard 锁定后，又被 Withdraw 锁定。 运行此类代码时，会发生以下两种情况之一。

由于 boost::mutex 不是递归的，我们需要使用其递归版本 boost::recursive_mutex。

class BankAccount
: public basic_lockable_adapter<recursive_mutex>
{

    // ...
};

调用者确保的锁定方法更加灵活且效率最高，但非常危险。 在使用调用者确保的锁定的实现中，BankAccount 仍然拥有一个互斥量，但其成员函数根本不操作它。 Deposit 和 Withdraw 不再是线程安全的。 相反，客户端代码负责正确锁定 BankAccount。

class BankAccount
    : public basic_lockable_adapter<boost:mutex> {
    int balance_;
public:
    void Deposit(int amount) {
        balance_ += amount;
    }
    void Withdraw(int amount) {
        balance_ -= amount;
    }
};

显然，调用者确保的锁定方法存在安全问题。 BankAccount 的实现代码是有限的，易于访问和维护，但是存在无限数量的客户端代码来操作 BankAccount 对象。 在设计应用程序时，区分对有界代码和无界代码施加的要求非常重要。 如果您的类对无界代码提出了不适当的要求，这通常表明封装已失效。

总而言之，如果在设计多线程类时采用内部锁定，则会使自己面临效率低下或死锁的风险。 另一方面，如果您依赖于调用者提供的锁定，则会使您的类容易出错且难以使用。 最后，外部锁定通过将其全部留给客户端代码来完全避免了该问题。

那么该怎么办呢？ 理想情况下，BankAccount 类应执行以下操作

让我们做一个有价值的观察：每当您锁定 BankAccount 时，您都可以通过使用 lock_guard<BankAccount> 对象来做到这一点。 将此语句翻转过来，只要有 lock_guard<BankAccount>，某处也会有一个锁定的 BankAccount。 因此，您可以将 lock_guard<BankAccount> 对象视为 - 并使用它 - 作为许可证。 拥有 lock_guard<BankAccount> 使您有权执行某些操作。lock_guard<BankAccount> 对象不应被复制或别名（它不是可传递的许可证）。

最终的效果是在你的代码中的任何时刻，如果拥有一个 lock_guard<BankAccount> 对象，就能保证一个 BankAccount 被锁定。（但是，你并不确切知道哪个 BankAccount 被锁定，这个问题我们稍后会解决。）

现在，让我们对 Boost.Thread 中定义的 lock_guard 类模板进行一些增强。我们将增强后的版本称为 strict_lock。本质上，strict_lock 的作用仅仅是作为自动变量存在于栈上。strict_lock 必须遵循非复制和非别名策略。strict_lock 通过将拷贝构造函数和赋值运算符设为私有来禁用拷贝。

template <typename Lockable>
class strict_lock  {
public:
    typedef Lockable lockable_type;


    explicit strict_lock(lockable_type& obj) : obj_(obj) {
        obj.lock(); // locks on construction
    }
    strict_lock() = delete;
    strict_lock(strict_lock const&) = delete;
    strict_lock& operator=(strict_lock const&) = delete;

    ~strict_lock() { obj_.unlock(); } //  unlocks on destruction 

    bool owns_lock(mutex_type const* l) const noexcept // strict lockers specific function 
    {
      return l == &obj_;
    }
private:
    lockable_type& obj_;
};

沉默有时胜过雄辩——对于 strict_lock 来说，禁止做什么与可以做什么同样重要。让我们看看你可以对 strict_lock 的实例化做什么，以及不能做什么。

BankAccount myAccount("John Doe", "123-45-6789");
strict_lock<BankAccount> myLock(myAccount); // ok

extern strict_lock<BankAccount> Foo(); // compile-time error
extern void Bar(strict_lock<BankAccount>); // compile-time error

// ok, Foo returns a reference to strict_lock<BankAccount>
extern strict_lock<BankAccount>& Foo();
// ok, Bar takes a reference to strict_lock<BankAccount>
extern void Bar(strict_lock<BankAccount>&);

所有这些规则的制定都是为了一个目的——强制保证拥有一个 strict_lock<T> 就意味着

现在我们有了如此严格的 strict_lock，我们如何利用它的力量来为 BankAccount 定义一个安全、灵活的接口呢？想法如下：

一句（被篡改的）谚语说：一小段代码胜过千言万语，所以这里是新的 BankAccount 类：

class BankAccount
: public basic_lockable_adapter<boost::mutex>
{
    int balance_;
public:
    void Deposit(int amount, strict_lock<BankAccount>&) {
        // Externally locked
        balance_ += amount;
    }
    void Deposit(int amount) {
        strict_lock<BankAccount> guard(*this); // Internally locked
        Deposit(amount, guard);
    }
    void Withdraw(int amount, strict_lock<BankAccount>&) {
        // Externally locked
        balance_ -= amount;
    }
    void Withdraw(int amount) {
        strict_lock<BankAccount> guard(*this); // Internally locked
        Withdraw(amount, guard);
    }
};

现在，如果你想要内部锁定的好处，你只需调用 Deposit(int) 和 Withdraw(int)。如果你想使用外部锁定，你通过构造一个 strict_lock<BankAccount> 来锁定对象，然后你调用 Deposit(int, strict_lock<BankAccount>&) 和 Withdraw(int, strict_lock<BankAccount>&)。例如，这是 ATMWithdrawal 函数的正确实现：

void ATMWithdrawal(BankAccount& acct, int sum) {
    strict_lock<BankAccount> guard(acct);
    acct.Withdraw(sum, guard);
    acct.Withdraw(2, guard);
}

这个函数兼具两全其美的优点——它既相当安全又相当高效。

值得注意的是，与直接的多态方法相比，strict_lock 作为一个模板提供了额外的安全性。在这种设计中，BankAccount 将从 Lockable 接口派生。strict_lock 将操作 Lockable 引用，因此不需要模板。这种方法是合理的；但是，它提供的编译时保证较少。拥有一个 strict_lock 对象只能说明某个从 Lockable 派生的对象当前被锁定。在模板方法中，拥有一个 strict_lock<BankAccount> 提供了更强的保证——它是一个 BankAccount 保持锁定状态。

这里有一个模棱两可的词——我提到 ATMWithdrawal 相当安全。它实际上并不安全，因为没有强制执行 strict_lock<BankAccount> 对象锁定相应的 BankAccount 对象。类型系统仅确保某些 BankAccount 对象被锁定。例如，考虑以下 ATMWithdrawal 的虚假实现：

void ATMWithdrawal(BankAccount& acct, int sum) {
    BankAccount fakeAcct("John Doe", "123-45-6789");
    strict_lock<BankAccount> guard(fakeAcct);
    acct.Withdraw(sum, guard);
    acct.Withdraw(2, guard);
}

这段代码编译时没有警告，但显然没有做正确的事情——它锁定一个帐户并使用另一个帐户。

重要的是要理解在 C++ 类型系统的范围内可以强制执行哪些内容，以及需要在运行时强制执行哪些内容。到目前为止，我们所建立的机制确保在调用 BankAccount::Withdraw(int, strict_lock<BankAccount>&) 期间锁定某个 BankAccount 对象。我们必须在运行时强制执行究竟哪个对象被锁定。

如果我们的方案仍然需要运行时检查，那么它有什么用呢？一个粗心或恶意的程序员可以很容易地锁定错误的对象，并在没有实际锁定的情况下操纵任何 BankAccount。

首先，让我们解决恶意问题。C 语言需要程序员付出大量的注意力和纪律。C++ 在这方面取得了一些进展，要求略低，但仍然从根本上信任程序员。这些语言不关心恶意（例如 Java 关心）。毕竟，你可以通过“适当”地使用强制转换来破坏任何 C/C++ 设计（如果适当在这种情况下是一个合适的词）。

该方案很有用，因为程序员忘记任何锁定的可能性远大于程序员记得锁定，但锁定了错误对象的可能性。

使用 strict_lock 允许对最常见的错误来源进行编译时检查，并对不太常见的问题进行运行时检查。

让我们看看如何强制执行相应的 BankAccount 对象被锁定。首先，我们需要向 strict_lock 类模板添加一个成员函数。bool strict_lock<T>::owns_lock(Lockable*) 函数返回对锁定对象的引用。

template <class Lockable> class strict_lock {
    ... as before ...
public:
    bool owns_lock(Lockable* mtx) const { return mtx==&obj_; }
};

其次，BankAccount 需要使用此函数将锁定的对象与 this 进行比较。

class BankAccount {
: public basic_lockable_adapter<boost::mutex>
    int balance_;
public:
    void Deposit(int amount, strict_lock<BankAccount>& guard) {
        // Externally locked
        if (!guard.owns_lock(*this))
            throw "Locking Error: Wrong Object Locked";
        balance_ += amount;
    }
// ...
};

上面测试产生的开销远低于第二次锁定递归互斥量。

现在让我们假设 BankAccount 根本不使用自己的锁定，并且只有一个线程中性的实现。

class BankAccount {
    int balance_;
public:
    void Deposit(int amount) {
        balance_ += amount;
    }
    void Withdraw(int amount) {
        balance_ -= amount;
    }
};

现在你可以在单线程和多线程应用程序中使用 BankAccount，但在后一种情况下你需要提供自己的同步。

假设我们有一个 AccountManager 类，它持有和操作一个 BankAccount 对象。

class AccountManager
: public basic_lockable_adapter<boost::mutex>
{
    BankAccount checkingAcct_;
    BankAccount savingsAcct_;
    ...
};

让我们还假设，根据设计，AccountManager 在访问其 BankAccount 成员时必须保持锁定状态。问题是，我们如何使用 C++ 类型系统来表达这种设计约束？我们如何声明“只有在锁定其父 AccountManager 对象后，你才能访问此 BankAccount 对象”？

解决方案是使用一个小桥模板 externally_locked 来控制对 BankAccount 的访问。

template <typename  T, typename Lockable>
class externally_locked {
    BOOST_CONCEPT_ASSERT((LockableConcept<Lockable>));

public:
    externally_locked(T& obj, Lockable& lockable)
        : obj_(obj)
        , lockable_(lockable)
    {}

    externally_locked(Lockable& lockable)
        : obj_()
        , lockable_(lockable)
    {}

    T& get(strict_lock<Lockable>& lock) {

#ifdef BOOST_THREAD_THROW_IF_PRECONDITION_NOT_SATISFIED
        if (!lock.owns_lock(&lockable_)) throw lock_error(); //run time check throw if not locks the same
#endif
        return obj_;
    }
    void set(const T& obj, Lockable& lockable) {
        obj_ = obj;
        lockable_=lockable;
    }
private:
    T obj_;
    Lockable& lockable_;
};

externally_locked 封装一个 T 类型的对象，并且实际上通过 get 和 set 成员函数提供对该对象的完全访问权限，前提是你传递一个对 strict_lock<Owner> 对象的引用。

AccountManager 没有将 checkingAcct_ 和 savingsAcct_ 设置为 BankAccount 类型，而是持有 externally_locked<BankAccount, AccountManager> 类型的对象。

class AccountManager
    : public basic_lockable_adapter<boost::mutex>
{
public:
    typedef basic_lockable_adapter<boost::mutex> lockable_base_type;
    AccountManager()
        : checkingAcct_(*this)
        , savingsAcct_(*this)
    {}
    inline void Checking2Savings(int amount);
    inline void AMoreComplicatedChecking2Savings(int amount);
private:

    externally_locked<BankAccount, AccountManager> checkingAcct_;
    externally_locked<BankAccount, AccountManager> savingsAcct_;
};

模式与之前相同 - 要访问由 checkingAcct_ 封装的 BankAccount 对象，你需要调用 get。要调用 get，你需要传递给它一个 strict_lock<AccountManager>。你必须注意的一件事是不要持有通过调用 get 获得的指针或引用。如果你这样做，请确保在 strict_lock 被销毁后不要使用它们。也就是说，如果你给封装的对象起别名，你就会从“编译器负责”模式回到“你必须注意”模式。

通常，你像下面这样使用 externally_locked。假设你想从你的支票账户到你的储蓄账户执行原子转账：

void AccountManager::Checking2Savings(int amount) {
    strict_lock<AccountManager> guard(*this);
    checkingAcct_.get(guard).Withdraw(amount);
    savingsAcct_.get(guard).Deposit(amount);
}

我们实现了两个重要的目标。首先，checkingAcct_ 和 savingsAcct_ 的声明向代码阅读者清楚地表明该变量受到 AccountManager 上的锁保护。其次，该设计使得在没有实际锁定 BankAccount 的情况下无法操纵这两个帐户。externally_locked 可以被称为主动文档。

现在假设 AccountManager 函数需要获取一个 unique_lock，以便减少临界区。并且在某个时候它需要访问 checkingAcct_。由于 unique_lock 不是严格锁，所以以下代码无法编译

void AccountManager::AMoreComplicatedChecking2Savings(int amount) {
    unique_lock<AccountManager> guard(*this, defer_lock);
    if (some_condition()) {
        guard.lock();
    }
    checkingAcct_.get(guard).Withdraw(amount); // COMPILE ERROR
    savingsAcct_.get(guard).Deposit(amount);  // COMPILE ERROR
    do_something_else();
}

我们需要一种方法，在处理 savingsAcct_ 期间，将所有权从 unique_lock 转移到 strict_lock，然后在 unique_lock 上恢复所有权。

void AccountManager::AMoreComplicatedChecking2Savings(int amount) {
    unique_lock<AccountManager> guard1(*this, defer_lock);
    if (some_condition()) {
        guard1.lock();
    }
    {
        strict_lock<AccountManager> guard(guard1);
        checkingAcct_.get(guard).Withdraw(amount);
        savingsAcct_.get(guard).Deposit(amount);
    }
    guard1.unlock();
}

为了使这段代码可编译，我们需要存储 Lockable 或 unique_lock<Lockable> 引用，具体取决于构造函数。我们还需要存储我们存储的是哪种引用，并在析构函数中调用 Lockable 的 unlock 或恢复所有权。

这对我来说太复杂了。另一种可能性是定义一个嵌套的严格锁类。缺点是，我们不是只有一个严格锁，而是有两个，我们需要复制每个接受 strict_lock 的函数，或者将这些函数定义为模板。模板函数的问题是我们不再能从 C++ 类型系统中获益。我们必须添加一些静态元函数来检查 Locker 参数是否是严格锁。问题是，我们真的无法检查这一点，或者可以吗？is_strict_lock 元函数必须由严格锁开发者专门化。我们需要相信它是“口头承诺”。优点是现在我们可以管理两个以上的严格锁，而无需更改我们的代码。这真的很好。

现在我们需要声明这两个类都是 strict_lock。

template <typename Locker>
struct is_strict_lock : mpl::false_ {};

template <typename Lockable>
struct is_strict_lock<strict_lock<Lockable> > : mpl::true_ {}

template <typename Locker>
struct is_strict_lock<nested_strict_lock<Locker> > : mpl::true_ {}

现在让我展示一下这个 nested_strict_lock 类的样子，以及它对 externally_locked 类和 AccountManager::AMoreComplicatedFunction 函数的影响。

首先，nested_strict_lock 类将在一个临时锁上存储 Locker，并在构造函数中转移锁的所有权。在销毁时，它将恢复所有权。请注意 lock_traits 的使用，以及 Locker 需要对互斥锁的引用，否则将抛出异常。

template <typename Locker >
class nested_strict_lock
    {
      BOOST_CONCEPT_ASSERT((MovableLockerConcept<Locker>));
public:
    typedef typename lockable_type<Locker>::type lockable_type;
    typedef typename syntactic_lock_traits<lockable_type>::lock_error lock_error;

    nested_strict_lock(Locker& lock)
        : lock_(lock)  // Store reference to locker
        , tmp_lock_(lock.move()) // Move ownership to temporary locker 
    {
        #ifdef BOOST_THREAD_THROW_IF_PRECONDITION_NOT_SATISFIED
        if (tmp_lock_.mutex()==0) {
            lock_=tmp_lock_.move(); // Rollback for coherency purposes 
            throw lock_error();
        }
        #endif
        if (!tmp_lock_) tmp_lock_.lock(); // ensures it is locked 
    }
    ~nested_strict_lock() {
        lock_=tmp_lock_.move(); // Move ownership to nesting locker 
    }
    bool owns_lock() const { return true; }
    lockable_type* mutex() const { return tmp_lock_.mutex(); }
    bool owns_lock(lockable_type* l) const { return l==mutex(); }


private:
    Locker& lock_;
    Locker tmp_lock_;
};

externally_locked 的 get 函数现在是一个模板函数，它接受 Locker 作为参数，而不是 strict_lock。我们可以在调试模式下添加测试，以确保 Lockable 对象已被锁定。

template <typename  T, typename Lockable>
class externally_locked {
public:
    // ...
    template <class Locker>
    T& get(Locker& lock) {
        BOOST_CONCEPT_ASSERT((StrictLockerConcept<Locker>));

        BOOST_STATIC_ASSERT((is_strict_lock<Locker>::value)); // locker is a strict locker "sur parole" 
        BOOST_STATIC_ASSERT((is_same<Lockable,
                typename lockable_type<Locker>::type>::value)); // that locks the same type 
#ifndef BOOST_THREAD_EXTERNALLY_LOCKED_DONT_CHECK_OWNERSHIP  // define BOOST_THREAD_EXTERNALLY_LOCKED_NO_CHECK_OWNERSHIP if you don't want to check locker ownership
        if (! lock ) throw lock_error(); // run time check throw if no locked 
#endif
#ifdef BOOST_THREAD_THROW_IF_PRECONDITION_NOT_SATISFIED
        if (!lock.owns_lock(&lockable_)) throw lock_error();
#endif
        return obj_;
    }
};

AccountManager::AMoreComplicatedFunction 函数只需要将 strict_lock 替换为 nested_strict_lock。

void AccountManager::AMoreComplicatedChecking2Savings(int amount) {
    unique_lock<AccountManager> guard1(*this);
    if (some_condition()) {
        guard1.lock();
    }
    {
        nested_strict_lock<unique_lock<AccountManager> > guard(guard1);
        checkingAcct_.get(guard).Withdraw(amount);
        savingsAcct_.get(guard).Deposit(amount);
    }
    guard1.unlock();
}

// #include <boost/thread/lockable_concepts.hpp> 

namespace boost
{

  template<typename L>
  class BasicLockable; // EXTENSION
}

// #include <boost/thread/lockable_traits.hpp> 

namespace boost
{
  namespace sync
  {
    template<typename L>
    class is_basic_lockable;// EXTENSION
  }
}

互斥锁上的一些算法通过 SFINAE 使用此特性。

如果参数 L 满足 Lockable 要求，则此特性为 true_type。

// #include <boost/thread/lockable_concepts.hpp> 
namespace boost
{
  template<typename L>
  class Lockable;
}

// #include <boost/thread/lockable_traits.hpp> 
namespace boost
{
  namespace sync
  {
    template<typename L>
    class is_lockable;// EXTENSION
  }
}

互斥锁上的一些算法通过 SFINAE 使用此特性。

如果参数 L 满足 Lockable 要求，则此特性为 true_type。

// #include <boost/thread/lockable_traits.hpp> 

namespace boost
{
  namespace sync
  {
    template<typename L>
    class is_recursive_mutex_sur_parole: false_type; // EXTENSION
    template<>
    class is_recursive_mutex_sur_parole<recursive_mutex>: true_type; // EXTENSION
    template<>
    class is_recursive_mutex_sur_parole<timed_recursive_mutex>: true_type; // EXTENSION
  }
}

默认情况下，trait is_recursive_mutex_sur_parole 是 false_type，并且专门为提供的 recursive_mutex 和 timed_recursive_mutex。.

它应该由用户专门化，以提供递归锁定的其他模型。

// #include <boost/thread/lockable_traits.hpp> 
namespace boost
{
  namespace sync
  {
    template<typename L>
    class is_recursive_basic_lockable;// EXTENSION
  }
}

如果 is_basic_lockable 且 is_recursive_mutex_sur_parole，则此 trait 为 true_type。

// #include <boost/thread/lockable_traits.hpp> 
namespace boost
{
  namespace sync
  {
    template<typename L>
    class is_recursive_lockable;// EXTENSION
  }
}

如果 is_lockable 且 is_recursive_mutex_sur_parole，则此 trait 为 true_type。

// #include <boost/thread/lockable_concepts.hpp> 

namespace boost
{
  template<typename L>
  class TimedLockable; // EXTENSION
}

// #include <boost/thread/lockable_concepts.hpp> 

namespace boost
{
  template<typename L>
  class SharedLockable;  // C++14
}

// #include <boost/thread/lockable_concepts.hpp> 

namespace boost
{
  template<typename L>
  class UpgradeLockable; // EXTENSION
}

// #include <boost/thread/locks.hpp>
// #include <boost/thread/lock_guard.hpp> 

template<typename Lockable>
class lock_guard
{
public:
    explicit lock_guard(Lockable& m_);
    lock_guard(Lockable& m_,boost::adopt_lock_t);

    ~lock_guard();
};

// #include <boost/thread/lock_concepts.hpp> 

namespace boost
{

  template<typename Lock>
  class StrictLock;
}

类型 L::mutex_type 表示由此锁锁定的互斥锁。

由于语义“确保关联的互斥锁在锁的生命周期内被锁定。”不能通过语法要求来描述，因此 is_strict_lock_sur_parole 特征必须由定义锁的用户专门化，以便以下断言为真

is_strict_lock_sur_parole<L>::value == true

以下类是 StrictLock 的模型

// #include <boost/thread/locks.hpp>
// #include <boost/thread/lock_types.hpp> 

template<typename Lockable>
class unique_lock
{
public:
    typedef Lockable mutex_type;
    unique_lock() noexcept;
    explicit unique_lock(Lockable& m_);
    unique_lock(Lockable& m_,adopt_lock_t);
    unique_lock(Lockable& m_,defer_lock_t) noexcept;
    unique_lock(Lockable& m_,try_to_lock_t);

#ifdef BOOST_THREAD_PROVIDES_SHARED_MUTEX_UPWARDS_CONVERSIONS
    unique_lock(shared_lock<mutex_type>&& sl, try_to_lock_t); // C++14 
    template <class Clock, class Duration>
    unique_lock(shared_lock<mutex_type>&& sl,
                const chrono::time_point<Clock, Duration>& abs_time); // C++14
    template <class Rep, class Period>
    unique_lock(shared_lock<mutex_type>&& sl,
                const chrono::duration<Rep, Period>& rel_time); // C++14
#endif

    template <class Clock, class Duration>
    unique_lock(Mutex& mtx, const chrono::time_point<Clock, Duration>& t);
    template <class Rep, class Period>
    unique_lock(Mutex& mtx, const chrono::duration<Rep, Period>& d);
    ~unique_lock();

    unique_lock(unique_lock const&) = delete;
    unique_lock& operator=(unique_lock const&) = delete;
    unique_lock(unique_lock<Lockable>&& other) noexcept;
    explicit unique_lock(upgrade_lock<Lockable>&& other) noexcept; // EXTENSION

    unique_lock& operator=(unique_lock<Lockable>&& other) noexcept;

    void swap(unique_lock& other) noexcept;
    Lockable* release() noexcept;

    void lock();
    bool try_lock();

    template <class Rep, class Period>
    bool try_lock_for(const chrono::duration<Rep, Period>& rel_time);
    template <class Clock, class Duration>
    bool try_lock_until(const chrono::time_point<Clock, Duration>& abs_time);

    void unlock();

    explicit operator bool() const noexcept;
    bool owns_lock() const noexcept;

    mutex_type* mutex() const noexcept;

#if defined BOOST_THREAD_USE_DATE_TIME || defined BOOST_THREAD_DONT_USE_CHRONO
    unique_lock(Lockable& m_,system_time const& target_time);
    template<typename TimeDuration>
    bool timed_lock(TimeDuration const& relative_time);
    bool timed_lock(::boost::system_time const& absolute_time);
#endif

};

template <class Clock, class Duration>
unique_lock(shared_lock<mutex_type>&& sl,
            const chrono::time_point<Clock, Duration>& abs_time);