《C++ Concurrency in Action》(CCIA)第三章中提到一个Lock Hierarchy的办法能够有效地避免死锁。这里结合Herb Sutter的这篇文章Use Lock Hierarchies to Avoid Deadlock简单得了解一下这个Lock Hierarchy。

一个典型的死锁会发生在如下的场景中：

• 一段代码试图去同时独占地去获取两个共享资源（mutex或者其他）a和b，按照先a后b的顺序。
• 另一段代码试图去同时独占的去获取两个共享资源a和b，但是获取顺序是相反，先b后a。
• 这两段代码可能同时执行。

这种情况下就会出现个两个代码块互相等待对方资源的情况，造成死锁。并非所有的情况都是很明确的能看到两个获取两个资源，有可能是你占有一个资源的时候调用了其他方法，也有可能是因为一些回调函数。所以这个问题可能会隐藏的很深。

普遍的建议就是永远按照同样的顺序去获取多个锁，但是正如上面所说的有时候多个锁可能是在不同的地方获取的，并没有那么明显。

有一个方法可以破这个就是Lock Hierarchies。每一个mutex都分配一个层级号码，并且严格按照下面两个规则：

1. 当占有层级为N的mutex的时候，只能去获取层次< N的mutex
2. 当试图同时占有多个同层级的mutex的时候，这些锁必须一次性获取，通过类似于std::lock的方法去保证顺序。

Herb给了一张很形象的图来描述这个方案。

实现细节

实现一个hierarchical mutex也很简单，原理和细节如下：

• 提供一个mutex wrapper，并且在所有的地方都是用这个wrapper来进行对mutex的操作，并且能够设置一个层次号
• 在wrapper内部放一个thread local的变量currentLevel来保存当前线程的层次号并将其初始化为大于所有level的号码
• 提供一些方法，比如lock, unlock，try_lock
• lock方法只有当currentLevel大于mutex wrapper的层次号才去上锁，否则抛出异常。如果上锁，则保存currentLevel并将currentLevel设置为当前的mutex 的层次号
• unlock的时候讲currentLevel重置会原来的层次号

代码

CCIA书中给出了一个很简单的hierarchical_mutex的实现。大家可以自己看看

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

#include <mutex>
#include <stdexcept>
#include <climits>

class hierarchical_mutex
{
    std::mutex internal_mutex;
    unsigned long const hierarchy_value;
    unsigned long previous_hierarchy_value;
    static thread_local unsigned long this_thread_hierarchy_value;

    void check_for_hierarchy_violation()
    {
        if(this_thread_hierarchy_value <= hierarchy_value)
        {
            throw std::logic_error("mutex hierarchy violated");
        }
    }
    void update_hierarchy_value()
    {
        previous_hierarchy_value=this_thread_hierarchy_value;
        this_thread_hierarchy_value=hierarchy_value;
    }
public:
    explicit hierarchical_mutex(unsigned long value):
        hierarchy_value(value),
        previous_hierarchy_value(0)
    {}
    hierarchical_mutex(const hierarchical_mutex&) = delete;
    hierarchical_mutex& operator=(const hierarchical_mutex&) = delete;
    void lock()
    {
        check_for_hierarchy_violation();
        internal_mutex.lock();
        update_hierarchy_value();
    }
    void unlock()
    {
        this_thread_hierarchy_value=previous_hierarchy_value;
        internal_mutex.unlock();
    }
    bool try_lock()
    {
        check_for_hierarchy_violation();
        if(!internal_mutex.try_lock())
            return false;
        update_hierarchy_value();
        return true;
    }
};
thread_local unsigned long
    hierarchical_mutex::this_thread_hierarchy_value(ULONG_MAX);       

int main()
{
    hierarchical_mutex m1(42);
    hierarchical_mutex m2(2000);
    
}

多个线程间共享数据会出现什么问题？

如果所有的数据都是只读的，那么多线程之间同时访问是不会有问题的。但是如果有人要读的同时有人要改就会出现问题。因为并非所有操作都能在一步完成，一般的操作会是先去读取数据，然后做一些其他的运算或者判断，然后回写数据。那么可能发生以下一些情况：

• 但是如果多个线程同时做这个操作的话，可能某一个线程回写的时候，当时判断的逻辑已经不成立了。
• 如果两个线程同时尝试去修改同一份数据，就会出问题。
• 其他更复杂的情况

当多个线程共享内存并且去尝试修改内存里的内容的时候，就会出现race condition。这会让代码出现一些无法预料的情况。比如说：

1
2
3
4

if (x == 5)
{
	y = x * 2;
}

这段代码在单线程下，如果x等于5，有一定等于10。但是如果多于一个线程运行这段代码，则y的值依赖于两个线程之间的执行顺序。如果还有一些线程在修改x的值，情况就更复杂了。

更糟糕的是在C++中，如果并发的修改同一个对象，会出现未定义的行为(undefined behavior)。

解决方案

应对race condition的解决方案有以下几种：

1. 通过某种保护机制来确保同一时间只有一个线程能够对某一个数据进行访问。
2. 通过lock-free的形式进行编程。主要指的是将对于数据的修改变成一系列不可分割的操作，C++中通常利用atomic来实现。具体会在lock-free一章中进行介绍。
3. 通过STM(software transaction memory)。这个方式是将内存的修改处理成跟数据库事务类似的机制，当修改完成commit到内存中，要么成功要么失败，不会存在中间状态。目前C++语言层面没有对这个功能的直接支持。

C++中主要使用#1和#2。#1的话主要是通过mutex为核心来实现。

利用Mutex来保护数据

Mutex是mutual exclusion（互斥）的意思。提供了lock和unlock两个方法，std::mutex同一时间值能有一个线程获得lock，当有一个线程拥有mutex的时候，其余调用lock尝试获得锁的线程会处于等待状态。

mutex本质上是一种资源，所以在C++中一般使用RAII来进行封装，避免出现lock和unlock调用不配对的情况。

C++11中提供了std::lock_guard<class Mutex>和std::unique_lock<class Mutex>封装。这两个类可以接受任何符合BasicLockable的mutex类型。

除了std::mutex以外，C++17中还提供了以下几种mutex：

• std::mutex (since C++11) 同时只能有一个线程获得锁，并且一个线程之只能lock一次。
• std::recursive_mutex (since C++11) 可重入锁，一个线程可以多次去lock同一个recursive_mutex。
• std::timed_mutex (since C++11)。在std::mutex的基础上提供了 try_lock_for和try_lock_until，允许在超时的情况下返回。
• std::recursive_timed_mutex (since C++11)。在std::recursive_mutex的基础上提供了 try_lock_for和try_lock_until，允许在超时的情况下返回。
• std::shared_mutex (since C++17)。传说中的读写锁。提供lock和shared_lock两套方法。lock即获得排他锁(exclusive lock)，shared_lock即获得共享锁(shared lock)

使用mutex时候需要注意的事情

当我们用mutex将我们需要保护的数据保护起来以后是不是就可以高枕无忧了呢？这只是“噩梦”的开始。。。。

你需要注意一下若干点：

• 不要将你保护的数据当做以引用或指针形式传入“不知名”的外部函数；
• 同样也不要将你要保护的数据作为指针或引用返回函数外部；
• 当你有多个锁要锁的时候，需要注意死锁；
• 如果你提供一个类型需要保证线程安全，确保你在设计api的时候精心考量；
• 控制锁的粒度，避免一些耗时的无必要的操作放在mutex保护范围内；

死锁

当你试图获取一个以上的锁的时候，如果姿势不对就可能产生死锁。解决死锁的通用的方法是，在所有需要同时获得多个锁的地方都按照一样的顺序去获取锁。当你需要同时获取两个锁的时候，std::lock可以帮你避免死锁的问题。

但是如果你的锁是在不同地方分别获得的，你还是有可能死锁。

关于如何避免死锁，有一些通用的建议：

• 避免在一个锁的内部嵌套另外一个锁；
• 不要在拥有一个锁的时候去调用其他方法，因为你不知道其他方法会做一些什么事情；
• 用固定的顺序去获取锁；
• 利用Lock Hierarchy，这个核心思想是保证固定顺序去获得锁。每一个锁都分配一个层次号，锁的获取顺序只能是从高层到底层。反向则不行。书中给的例子很好，值得好好去理解。
• 死锁并不一定发生在有锁的地方，任何需要等待其他线程的地方都可能发生死锁。

控制锁的粒度

In general, a lock should be held for only the minimun possible time needed to perform the required operations.

不要多、不要少、够用最好。

其他保护共享数据的方法

• static初始化。C++11开始，static初始化变量保证是线程安全的。对于一些只需要初始化一次的静态变量使用。
• 利用std::recursive来避免一些可重入的情况，但是大部分情况需要可重入的锁意味着代码设计可能有问题。最好通过调整代码来避免这种情况。
• 利用std::shared_lock来提高性能，针对大部分情况都是读，只有少数情况下会去修改的数据。

C++11标准中加入了对多线程编程的支持，主要添加了下面一些方面：

• 定义了内存模型
• <thread>，引入std::thread来管理、控制线程。
• <atomic>，原子操作相关类。
• <mutex>，引入mutex，以及相关的类，用于锁等互斥操作。
• <condition_variable>，引入condition_variable以及相关类，用于线程间同步。
• <future>，引入future, promise以及相关的一些类，主要用于线程间同步和通信的一些机制。

这篇主要介绍对于线程管理的相关话题，对书中的内容进行总结并适当扩展。

• 如何创建一个线程
• 如何销毁一个线程
• std::thread的所有权(owenership)
• 如何控制线程数量
• 线程ID

如何创建一个线程

1
2

template< class Function, class... Args > 
explicit thread( Function&& f, Args&&... args );

std::thread构造函数如上，它可以接受任何callable的类型，包括全局方法、成员方法、std::function、仿函数、lambda表达式等。并且后面可以带参数，用来传递给方法。

例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

void func1() {}
class A {
public:
    void func2(){}
};

struct B {
public:
    void operator()() { }
};


    A obja;
    B objb;
    A obja;
    B objb;
    std::thread t1(func1);          //全局方法
    std::thread t2(&A::func2, obja);//成员方法
    std::thread t3(objb);           //functor
    std::thread t4([](){});         //lambda

注意事项：

• std::thread对象一旦创建，线程马上就起来了，没有办法延迟启动。
• std::thread一旦起来以后没有办法通过api它杀掉，除非通过native_handle拿到平台相关的线程句柄进行操作。这个非C++提供而是操作系统提供。

传参

启动线程的时候可以传递参数，传参的形式默认为拷贝，如果有类型转换则是在线程启动时进行。所以需要保证传递的参数不依赖于方法栈上的其他内存。

如果不满足于默认的按值拷贝，可以通过std::ref或std::move进行传引用或转成右值进行move操作。下面给出几个例子。

1
2
3
4
5
6
7
8
9

void pass_by_val(int i) {}
void pass_by_ref(int &i) {}
void pass_by_move(std::unique_ptr<big_obj> bigObj){}

    int i;
    std::thread t1(pass_by_val, i);
    std::thread t2(pass_by_ref, std::ref(i));
    std::thread t3(pass_by_move, std::make_unique<big_obj>());

注意事项：

• std::ref 注意引用的生命周期和线程的生命周期的关系。

如何销毁一个线程

你没法销毁一个线程，你只能等它跑完或者让他在后台运行并且把其管理权移交给C++运行库。

下面介绍一组和线程结束相关的api：

• bool jionable()： 如果是默认线程(即std::thread t;)则是false。只要一个线程被join过一次以后则变为false，即使一个线程已经结束了，但是没有被join过，还是会返回true。
• void join()。等待线程结束运行，一个线程只能被调用一次，如果在jioinable为false的情况下调用，会直接抛出std::system_error。
• void detach()。将线程放到后台运行，并且将管理权转给C++运行库。

注意事项：

• 一个线程在析构前必须调用join或者detach来显示的处理它的生命周期，否则的话会析构时直接抛出异常。
• join本身并非线程安全，如果多个线程在没有保护的情况下同时join同一个std::thread会undefined behavior

std::thread的所有权(owenership)

No two std::thread objects may represent the same thread of execution; std::thread is not CopyConstructible or CopyAssignable, although it is MoveConstructible and MoveAssignable.
http://en.cppreference.com/w/cpp/thread/thread

std::thread 只能move不能被拷贝，所以如果想要把std::thread放进容器的话必须确保是右值。直接构造出来或者用std::move进行转换都可以。

比如下面这样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

void calc_something(int i){ std::cout << i; }

   std::vector<std::thread> thread_vec;
   for (int i = 0 ; i < 3; i++)
   {
       std::thread t(calc_something, i);
       thread_vec.push_back(std::move(t));                   // use std::move
       thread_vec.push_back(std::thread(calc_something, i)); // 直接构建为右值
       thread_vec.emplace_back(calc_something, i);           // 用emplace_back
   }
   
   for(auto & t : thread_vec)
   {
       if (t.joinable()) t.join();
   }

如何控制线程数量

线程数量并非越多越好，数量太多会导致CPU的频繁上下文切换，反而会适得其反。std::thread::hardware_concurrency静态方法可以获得。

Returns the number of concurrent threads supported by the implementation. The value should be considered only a hint.
http://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency

但是这个数量仅供参考，因为依赖于不同编译器和平台的实现。有可能会返回0，表示这个数量未定义，也就是说不知道在这个硬件上有多少个并发线程可以执行。

线程ID

通过 std::thread::id std::thraed::get_id()可以拿到一个线程的id。这个id主要的用途是用来打印log和作为关系容器的key。

1
2
3
4
5
6

std::map<std::thread::id, std::thread> thread_map;
for (int i = 0 ; i < 3; i++)
{
    std::thread t(calc_something, i);
    thread_map[t.get_id()] = std::move(t);
}

这个系列主要学习TCP协议，主要以阅读TCP/IP Illustrated, Volume 1 (2nd Edition)和TCP/IP详解 卷1：协议为主，并结合一些网上的资料。

这章标题为：TCP: The Transmission Control Protocol (Preliminaries)，主要是介绍一些TCP协议要解决的问题，以及大致的设计思路。具体的技术细节要在之后的章节进行详细的阐述。

简单设计一个协议

TCP协议下层的协议都不是“可靠”的，它们不保证传输的可靠性。所以要建立一个可靠地传输协议需要克服一下几个问题：

1. 包内部的数据错误(packet bit errrors)。在传输的过程中有可能导致传输的数据中的bit有错误。
2. 丢包(packet erasure)
3. 包的顺序不对(packet reordering)。
4. 重复的包(packet duplication)。

解决1和2可以用重传的机制，发送端发送包给接收端，接收端接收到以后确认没有错误返回一个确认信息（ACK/acknowledge）。如果发送端没有及时收到确认信息，则重传直到收到确认信息。

解决3和4可以假如序列号（sequence number），这样接收端就可以直到收到的包的顺序和是否重复。

上面的两个简单地解决方案可以解决我们提到的四个问题。但是这个方案本身还有一些悬而未决和不足的地方：

1. 发送端应该等待多久才认为是超时了？（这个问题比较复杂，会在十四章详述）
2. 如果接收端发出来的ACK信息丢失了怎么办？（可以归类为第一个问题）
3. 如果接收端收到包但是有错误怎么处理？（假如checksum校验，如果发现有错误则不确认，即可归类为第一个问题）
4. 这个方案只能一个一个包发送，大部分情况下发送端处于空闲状态，效率低下。（下面会引入窗口概念）

窗口和滑动

解决上述方案中的第四个问题，我们可以引入一个窗口的概念。一次不是只发送一个包，而是发送一组包。可以想象成一个窗口，当前面发送的包已经被确认以后，则可以将窗口往下进行滑动去发送更多的包。窗口的基本意思可以看书上的插图，比较直观。

可以看到窗口的大小会直接影响到同时发出多少个包，这个大小的设置就直接影响到了接收端和中途的网络设备。如果太大的话可能会导致接收端无法处理，也可能导致中途的网络设备无法处理造成丢包，从而影响发送效率。太小的话则无法很好地充分利用网络资源和接收端的资源。

这里会引入两个概念。流量控制（flow control）和阻塞控制（congestion control）。

接收端可以根据自己的情况告诉发送端自己合适的窗口大小是多少，一般通过ACK包一起发送回去。这个属于流量控制，又称显式控制（explicit signaling）。

网络设备的拥堵情况则没有办法通过显式的控制，而是需要通过一些算法来计算出来一个比较合适的窗口大小。这个可以称为隐式控制（implicit signaling）。这个会在十五章里面详细讨论。

如何设置超时？

对于每一个包的传输时间（round-trip-time），即从发送到收到确认的时间，我们可以知道。我们能通过一些统计来估算出一个大概的时间当做超时。很显然平均值不是一个很好的选择，因为如果用平均值的话可能会有很多请求直接被超时了。如何设置超时也是一个需要深入讨论的问题，会在十四章中进行讨论。

介绍TCP

TCP协议是一个面向连接（connection-oriented）的协议，这个意思是两个应用必须先建立连接，然后才能进行通行。

TCP是一个可靠的协议，它具备以下几个特点确保其其可靠性：

• 强制checksum校验，保证数据传输是对的。如果传输的数据块太大则需要引入其他的中间层来保证。
• 有timer来保证超时会重发。
• 有ACK来保证接收端确认收到包。并且ACK的确认是累加性的，如果接收端收到了x+2 返送了ACK x+3，但ACK x+3丢了。下次接收端接收到x+3的时候会返回ACK x+4，这样就可以避免x+2重传。
• TCP有序列号来解决乱序和重复包的问题。
• TCP为全双工，两边都可以进行传输。

TCP头部和封装

插两张图

图中可以看到有8个比特位用来控制TCP的一些flag，用于不同的请求。可能会多于一个比特位被置成1。

前戏

先抛出两个问题

• 如果delete一个指针，但是它真实的类型和指针类型不一样会发生什么？
• 是谁调用了析构函数？

下面这段代码会发生什么有趣的事情？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

// delete_diff_type.cpp
#include <iostream>

using namespace std;

class Foo
{
public:
    Foo() { cout << "Foo()" << endl; }
    ~Foo() { cout << "~Foo()" << endl; }
};

class FakeFoo
{
public:
    FakeFoo() { cout << "FakeFoo()" << endl; }
    ~FakeFoo() { cout << "~FakeFoo()" << endl; }
};

int main(int argc, const char * argv[]) {
    
    void* vptr = new Foo();
    delete vptr;    // warning
    
//    FakeFoo* ffptr = static_cast<FakeFoo*>(new Foo()); // error
    FakeFoo* ffptr = reinterpret_cast<FakeFoo*>(new Foo());
    delete ffptr;
    
    Foo* fptr = new Foo();
    delete fptr;
    
    return 0;
}

1
2
3
4
5
6

输出:
Foo()
Foo()
~FakeFoo()
Foo()
~Foo()

看一下汇编代码可以看到main函数主要做了下面这几件事

1
2
3
4
5
6
7
8
9
10
11
12
13

; symbol stub for: operator new(unsigned long)
; Foo::Foo at delete_diff_type.cpp:8
; symbol stub for: operator delete(void*)

; symbol stub for: operator new(unsigned long)
; Foo::Foo at delete_diff_type.cpp:8
; FakeFoo::~FakeFoo at delete_diff_type.cpp:16
; symbol stub for: operator delete(void*)

; symbol stub for: operator new(unsigned long)
; Foo::Foo at delete_diff_type.cpp:8
; Foo::~Foo at delete_diff_type.cpp:9
; symbol stub for: operator delete(void*)

从汇编中可以看出，构造造函数和析构函数是编译器根据指针的类型生成的调用代码。而且编译器是不允许没有继承关系的指针之间进行转换的，void* 是个例外，只要不作死用reinterpret_cast把指针转换成不相关的类型是不会有问题的。

所以上面两个问题大概就有答案了。delete语句会至少产生两个动作，一个是调用指针对应类型的析构函数，然后去调用operator delete释放内存。所以如果delete的指针和其指向的真实类型不一样的时候，编译器只会调用指针类型的析构函数，这也就为什么基类的析构函数需要声明称虚函数才能够保证delete基类指针的时候子类析构函数能够被正确的调用。
operator delete是都会被调用到的，所以指针指向的那块内存是能够“正常的”被释放掉用。

std::shared_ptr<void> 的行为

那么这个跟std::shared_ptr<void> 有什么关系呢？

先看一段代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

#include <iostream>

using namespace std;

class Foo
{
public:
    Foo() { cout << "Foo()" << endl; }
    ~Foo() { cout << "~Foo()" << endl; }
};

int main(int argc, const char * argv[]) {
    shared_ptr<void> vptr = shared_ptr<Foo>(new Foo);
    return 0;
}

1
2
3

输出：
Foo()
~Foo()

与第一段代码中类似，不过把void*换成了std::shared_ptr<void>，那么shared_ptr<void>为什么能够调用到正确的析构函数呢？一定是shared_ptr里面搞了什么鬼。

std::shared_ptr<void> 为啥能正常工作

那么就看看源代码看看到底为啥这货能够工作，下面是libcxx中shared_ptr的部分源码，把关键的部分抠出来了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

/** C1. shared_ptr 构造函数 **/

template<class _Tp>
template<class _Yp>
shared_ptr<_Tp>::shared_ptr(_Yp* __p,
                            typename enable_if<is_convertible<_Yp*, element_type*>::value, __nat>::type)
    : __ptr_(__p)
{
    unique_ptr<_Yp> __hold(__p);
    typedef typename __shared_ptr_default_allocator<_Yp>::type _AllocT;
    typedef __shared_ptr_pointer<_Yp*, default_delete<_Yp>, _AllocT > _CntrlBlk;
    __cntrl_ = new _CntrlBlk(__p, default_delete<_Yp>(), _AllocT());
    __hold.release();
    __enable_weak_this(__p, __p);
}

/** C2. shared_ptr 拷贝构造 **/
template<class _Tp>
inline
shared_ptr<_Tp>::shared_ptr(const shared_ptr& __r) _NOEXCEPT
    : __ptr_(__r.__ptr_),
      __cntrl_(__r.__cntrl_)
{
    if (__cntrl_)
        __cntrl_->__add_shared();
}

/** C3. shared_ptr::__cntrl_ 类型 **/
__shared_weak_count* __cntrl_;

/** C4. shared_ptr 析构函数 **/

template<class _Tp>
shared_ptr<_Tp>::~shared_ptr()
{
    if (__cntrl_)
        __cntrl_->__release_shared();
}

/** C5. __shared_weak_count::__release_shared **/

bool __release_shared() _NOEXCEPT {
    if (__libcpp_atomic_refcount_decrement(__shared_owners_) == -1) {
    __on_zero_shared();
    return true;
    }
    return false;
}

/** C6. __shared_ptr_pointer::__release_shared **/
template <class _Tp, class _Dp, class _Alloc>
/* 重点 !!! virtual !!! */
void
__shared_ptr_pointer<_Tp, _Dp, _Alloc>::__on_zero_shared() _NOEXCEPT
{
    // __data__ 是 内部工具类__compressed_pair
    // __data_.first().second()是 deleter
    // __data_.first().first() 是 shared_ptr<T> 中T类型的指针
    __data_.first().second()(__data_.first().first());
    __data_.first().second().~_Dp();
}


/** C7. default deleter **/

template <class _Tp>
struct _LIBCPP_TEMPLATE_VIS default_delete {
    // ... 此处省略若干行
  void operator()(_Tp* __ptr) const _NOEXCEPT {
    delete __ptr;
  }
};

不要慌，给你慢慢道来。

这个故事简单得说是这样的：

• 每一个shared_ptr 内部有一个control block，里面会存放一个要维护的指针，一个计数，一个删除器(deleter)，一个分配(allocator)。这里我们要关心的是删除器。顾名思义，它是用来删除指针的。
• shared_ptr中的 有一个__cntrl_即control block。字段的类型是__shared_weak_count指针，这个类是一个非模板类。shared_ptr<T>创建的control block的类型是一个类模板template <class _Tp, class _Dp, class _Alloc> __shared_ptr_pointer继承自__shared_weak_count。 见代码C3。
• 当创建一个新的shared_ptr的时候，构建一个新的control block。见代码C1。
• 当一个shared_ptr A赋值或者拷贝构造给另一个shared_ptrB的时候（当然是在类型能够转换的前提下），B会把A的__cntrl_拷一份，同时将其引用加一。注意，这个时候拷贝的是指针，__cntrl_还是指向最初创建的那个对象。见代码C2。
• 当shared_ptr被析构或者重置的时候会调用__cntrl_->__release_shared()。见代码C4。
• __cntrl_->__release_shared()如果发现当前的计数为-1的时候，调用__on_zero_shared()。见代码C5。
• __on_zero_shared是一个虚方法，那么它就会调用到最初创建的__shared_ptr_pointer的实现。
• __shared_ptr_pointer的实现中是有完整的类型和删除器的信息的。见代码C6。
• 默认的删除器很简单的执行了delete __ptr操作，因为类型是已知的所以能够正确的调用到析构函数。见代码C7。

这种实现方式给shared_ptr带来额外好处

Effective C++ 条款07告诉我们“要为多态基类声明 virtual 析构函数”。当然我认为建议依然有效，但是用了shared_ptr以后带来的一个额外好处就是即便你的析构函数忘记写成virtual也能帮你正确的调用析构函数。