boost线程同步

l  内锁

l  外锁

除了C++11标准提供的锁，boost.thread提供了其他额外的锁和工具。

内锁：

考虑一个银行账户class，该class提供存款和取款从不同的地点。(可以说是多线程编程中的”Hello, World”)

该账户的姓名为Joe。 另外有两个线程，一个线程为银行代理，该代理负责将钱存入Joe的账户，也就是说它代表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 ofbankAgent    boost::thread thread2(Joe);// start concurrent execution of Joe    thread1.join();    thread2.join();    return 0;}

两个线程并发执行，代理每次存入$500，存10次，Joe每次取$100，取10次。

     只要代理和Joe不同时操作账户。上面的代码可以正确的运行。但是谁也不能保证。所以，我们打算使用互斥量保证对账户的操作时是排他性的(独占)。

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;    }};

这样，保证了存取款操作不会被同时执行。

互斥量是一种简单基础的机制，保证同步执行。在上面的例子中操作同步执行是很容易令人信服的(在不出现异常的情况下)。但是，在一个复杂的并发与共享的环境中，大量的使用互斥量将使得使用繁琐，可读性也差。取而代之，对于复杂的同步，我们引入一系列的通用类型。

利用RAII我们能够简化范围性的锁定。下面的代码，哨兵(lock_guard)锁的构造函数会锁传入的互斥量。析构时，解锁互斥量。

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_;    }};

然而，仅仅使用这种内部的对象级别的锁(object-level)，可能还不能满足复杂的业务需求。比如，上面的模型是很容易发生死锁的。尽量如此，对象级别的锁还是很有用的在许多情况下。将其与其他机制结合起来，可以为多线程访问提供满意的解决方案。

     上面的BankAccount 使用了内部锁定。这种对象级的内部锁定，保证了对该对象的成员函数的访问是线程同步的，不会把这个对象搞死。这种方式，对于给定的类的某个对象，在同一时刻，有且只有一个成员函数在执行，所有成员函数的调用将是序列化的。

     这种方法是合理的，且易于实现的。但是不幸的是，”简单”有时可能意味着可能过于简单了(出现问题了呗)。当然并不是说这个方法有问题，而是业务逻辑复杂，仅仅使用这种方式，是不够的。

     仅仅使用这种内部锁，不足以应付真实世界。我们上面的例子是简单的模型，想象一下，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);}

注意到这段不能通过编译，因为acct.mtx_是对象私有的，不能在对象外面访问。两种方式解决：

• 使mtx_成为public，看着比较反常
• 添加lock/unlock函数，使得BankAccount可锁

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();    }};

或者从有这两个函数的类继承。

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_;    }};

ATM取款变成：

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

现在账户acct先被guard对象加锁，然后又被提款操作再次加锁。可能发生下面两种事情：

• 你使用的互斥量实现上可能支持同一线程对同一锁多次加锁(递归锁)。如果是递归式锁，上述代码正常工作，但是明显的，第二次提款的加锁动作是没必要的，这带来了一定的性能损失
• 你使用的锁不是递归式的，那么在第二次加锁后，将自己阻塞自己，死锁。

因为boost::mutex不是递归式的，因此我们需要使用它的递归版本boost::recursive_mutex

class BankAccount: public basic_lockable_adapter<recursive_mutex>{     // ...};

注意，让客户(调用方)手动自己去加解锁，比较方便灵活，但是这是将责任推给了客户，如果客户不正确的使用。比如，为了存款加外锁，但是之后忘记了解锁。或者之前的例子一样，ATM取款，没有将两次取款整体加锁。或者使用了boost::mutex导致死锁。

     如果你的类，在使用中，需要客户来保证，即对外界代码要求过分，过于依赖外界。那说明你设计的类，封装的不好。

     总结：1.内锁效率损失或者遇到不是递归式锁将死锁。2.外部加锁过于依赖调用方来保证正确性，它回避问题，将责任丢给外界，使得类的使用容易出现错误。

 

 

外锁：

基于上一节的讨论，理想的BankAccount 应该像下面这样：

• 支持两种锁模型(internal and external)
• 高效的；即不要在没必要的加锁的情况下，还去加锁
• 安全的，即在没有得到合适的锁情况下，不能操作账户

让我们做一个有价值的思考：每当你要锁定一个BankAccount，你都使用一个lock_guard<BankAccount> 对象去锁定。反过来说，哪里有lock_guard<BankAccount>对象，哪里就有一个BankAccount存在。因此，你可以将lock_guard<BankAccount>对象看做一种许可，拥有该对象表明你有权限对账户操作。lock_guard<BankAccount>对象应该是不可拷贝和别名的。

1.   只要许可仍然活着，某个BankAccount仍然被锁住的

2.   当许可lock_guard<BankAccount>销毁，BankAccount的互斥量将释放

 

现在，我们打算对之前的boost.thread中的模板lock_guard进行增强。我们将增强的版本叫做strict_lock。实质上，strict_lock的角色只是栈中的变量。strict_lock必须是不可拷贝的、不可别名的。strict_lock通过将拷贝构造函数和赋值函数声明为private的来禁止复制行为。

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时，你能做什么，以及你不能做什么：

• 你必须显示的使用有效的T对象，实例化strict_lock<T>，这是实例化它的唯一方式

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

• 你不能将其拷贝给其他。特别的，你不能以传值的方式传给函数，以及从函数返回
• 不过，你仍然可以通过传递引用进出函数

// 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>对象时，你锁住了T对象，并且在之后的某个点，T对象会被解锁。

     现在我们有了strict_lock，如何利用它为BankAccount定义一个安全、灵活的接口呢？思路如下：

• BankAccount的接口函数(在本例中，Deposit和Withdraw)有两种形式的重载
• 一种与原来的(函数签名式)相同，另一种这多了一个strict_lock<BankAccount>参数，第一种使用内部锁；第二种需要一个外部锁，这个外部锁需要客户在编译期就提供的，用户代码中创建strict_lock<BankAccount>对象。
• 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>&)。举例，下面是一个ATMWithdrawal函数的正确实现：

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

这种方式不但相对的安全，而且没有多余的加锁动作。

值得注意的是，以模板实现的strict_lock比起直接用继承实现，能提供更高的安全。使用继承的方式，strict_lock继承基类的锁接口，需要调用锁接口(如果调用出现异常，上锁失败)，但是模板不需要，不过继承比模板需要编译时间更少。继承方式，让我们知道有某个从锁类继承而来的某个类对象现在被锁住了，而模板strict_lock<BankAccount>，当你拥有这么个对象时候，表明有某个BankAccount已经处于锁定状态了(strict_lock的构造传递的是引用)。相当于一个是进行时ing，一个是过去式done。

注意到我的言辞，我提及到ATMWithdrawal是相对安全的。实际上它不是真的绝对安全的，因为strict_lock<BankAccount>只表明了你要锁的对象的类型(BankAccount)，类型系统只是确保某个BankAccount对象被锁住了，并没有限定究竟是哪个具体的BankAccount对象被锁定。比如，考虑下面的蓄意构造的假实现:

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这种语言，需要程序员小心翼翼和守纪律，C++则稍微好点，不过它仍然是坚持信任程序员的行为。C/C++并没有考虑程序员的恶意行为(不像Jave之类的)。当然你也可以打破语言最初的设计初衷，通过”适当的”手法。

     忘记加锁的可能性，相比于知道要加锁，但是锁错了对象的可能性要大的多。

     使用strick_lock许可证在编译器查出更多常见的错误，让不怎么会出现的错误在运行时检查。

     让我们看看如何实现，首先我们需要向模板类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需要使用这个接口比较

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;    }};

如果你要在多线程环境使用，请使用自己的同步方法在接下来的例子中。

现在有个类AccountManger，它持有账户并操作账户。

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

进一步假设，设计上要求我们在操作AccountManager中的账户时，必须先锁住该管理类。    对于这个设计需求，我们该怎么用C++表达呢？

      解决办法是，使用一个桥型模板externally_locked，用来控制对账户的访问。

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类型的对象披了层外套，现在访问T对象需要使用get、set方法，并且同时传递一个对该对象的锁。

      现在，我们将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_;};

      现在的模型正是我们需要的——想要访问账户，现在需要调用get，而调用get你必须传递strict_lock<AccountManager>，也就是说你必须先锁住AccountManager。不过有一件事，你必须小心，不要将get得到的引用保存下来使用，如果这样的话，当引用所指的对象销毁了，你的访问将出现问题，尽量不要这么做，我们的原则是尽量的让编译器做更多的事情，而降低自己需要投入的注意力，这能减轻我们的负担。

      典型的，像下面这样去使用externally_locked，假设你要原子性的从checking账户转账到savings账户：

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

      我们实现了两个重要的目标，第一，可读性更好，从表面形式看，我们容易看出变量被锁保护。第二，这种设计，你不上锁就不可能访问得到账户，externally_locked相对于一种激活钥匙。