线程安全的 Observer 模式

对象的创建很简单

对象构造要做到线程安全，唯一的要求是在构造期间不要泄露 this 指针，即：

1. 不要在构造函数中注册任何回调
2. 也不要在构造函数中把 this 传给跨线程的对象
3. 即便在构造函数的最后一行也不行

之所以这样规定，是因为在构造函数执行期间对象还没有完成初始化，如果 this 被泄露（escape）给了其他对象（其自身创建的子对象除外），那么别的线程有可能访问这个半成品对象，这会造成难以预料的后果。

对象的销毁太难

对象析构，这在单线程里不构成问题，最多需要注意避免空悬指针和野指针。而在多线程程序中，存在了太多的竞态条件。对于一般的成员函数而言，做到线程安全的办法是让它们顺次执行，而不要并发执行，也就是让每个成员函数的临界区不重叠。这是显而易见的，不过有一个隐含条件：成员函数用来保护临界区的互斥器本身必须是有效的。而析构函数破坏了这一假设，他会把 mutex 成员变量销毁掉。

1. mutex 不是办法

mutex 只能保证函数一个接一个地执行，考虑下面的代码，它试图用互斥锁来保护析构函数，考虑如下的代码：

#include "Observer.h"
#include "MutexLockGuard.h"

/* class Foo : public Observer
{
public: 
    Foo(Observable* s)
    {
        s->register_(this); // 构造函数泄露 this 指针
    }

    virtual void update();
}; */

class Foo : public Observer
{
public:
    Foo();
    virtual void update();

// 另外定义一个函数，在构造函数完成后执行回调函数的注册
    void observe(Observable* s)
    {
        s->register_(this);
    }
private:
    MutexLock mutex_;
};

//Foo* pFoo = new Foo;
//Observable* s = getSubject();
//pFoo->observe(s);

Foo::~Foo()
{
    MutexLockGuard lock(mutex_);
    // (1)...
}

void Foo::update()
{
    MutexLockGuard lock(mutex_);
    // (2)...
}

// thread A
delete x;
x = NULL;

// thread B
if (x) {
    x->update();
}

尽管线程 A 在销毁对象之后把指针置位了 NULL ，尽管线程 B 在调用 x 的成员函数之前检查了指针 x 的值，但还是无法避免一种 race condition：

1. 线程 A 执行到了析构函数的（1）处，已经持有了互斥锁，即将往下执行。
2. 线程 B 通过了 if（x）检测，阻塞在（2）处。

接下里会发生什么？A 析构函数会把 mutex_ 销毁，那么（2）处有可能永远阻塞下去，有可能进入“临界区”，然后 core dump，或者发生其他更糟糕的情况。

这个例子至少说明 delete 对象之后把指针置为 NULL 在多线程竞态环境下根本没用，如果一个程序要靠这个来防止二次释放，说明代码逻辑除了问题。

2. 作为数据成员的 mutex 不能保护析构

前面的例子说明，作为 class 数据成员的 MutexLock 只能用于同步本 class 的其他数据成员的读和写，它不能保护安全的析构。因为 MutexLock 成员的生命周期最多与对象一样长，而析构动作可说是发生在对象身故之后（或者身亡之时）。另外，对于基类对象，当调用到基类析构函数的时候，派生类对象的那部分已经析构了，那么基类对象拥有的 MutexLock 不能保护整个析构过程。再说，析构过程本来也不需要保护，因为别的线程都访问不到这个对象时，析构才是安全的，否则会有竞态发生。

另外如果要同时读写一个 class 的两个对象，有潜在死锁的可能。比方说有 swap() 这个函数：

#include "Counter.h"

void swap(Counter& a,Counter& b)
{
    MutexLockGuard aLock(a.mutex_);	// potential dead lock
    MutexLockGuard bLock(b.mutex_);
    int64_t value = a.value_;
    a.value_ = b.value_;
    b.value_ = value;
}

// 如果线程 A 执行 swap(a,b); 而同时线程 B 执行 swap(b,a);就有可能产生死锁;
// operator=() 也是类似的道理

Counter& Counter::operator=(const Counter& rhs)
{
    if(this == &rhs)
    return *this;

    MutexLockGuard myLock(mutex_);	// potential dead lock
    MutexLockGuard itsLock(rhs.mutex_);
    value_ = rhs.value_;	// 改成 value_ = rhs.value() 会死锁
    return *this;
}

一个函数如果要锁住相同类型的多个对象，为了保证始终按相同的顺序加锁，我们可以比较 mutex 对象的地址，始终先加锁地址较小的 mutex

一个动态创建的对象是否还活着

一个动态创建的对象是否还活着，光看指针是看不出来的（引用也一样看不出来）。指针就是指向了一块内存，这块内存上的对象如果已经销毁，那么就根本不能访问（就像 free 之后的地址不能访问一样），既然不能访问又如何知道对象的状态呢？换句话说，判断一个指针是不是合法指针没有高效的办法，这是 C\C++ 指针问题的根源。（万一原地址又新建了一个新的对象呢？再万一这个新的对象的类型异于老的对象呢？）

对象的三种关系

在面向对象程序设计中，对象的关系主要有三种：composition、aggregation、association。composition（组合\复合）关系在多线程里不会遇到什么麻烦，因为对象 x 的生命周期由其唯一的拥有者 owner 控制，owner 析构的时候会把 x 也析构掉。从形式上看，x 是owner 的直接数据成员，或者 scoped_ptr 持有的容器元素。

后两种关系在 C++ 里比较难办，处理不好就会造成内存泄漏或重复释放。association 是一种很宽泛的关系，它表示一个对象 a 用到了另一个对象 b ，调用了后者的成员函数。从代码形式上看，a 持有 b 的指针（或引用），但是 b 的生命期不由 a 单独控制。aggregation（聚合）关系从形式上看与 association 相同，除了 a 和 b 有逻辑上的整体与部分的关系。如果 b 是动态创建的并在整个程序结束前有可能被释放，那么就会出现竞态条件。