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相对于一种激活钥匙。