本文旨在对 C++11 中引入的内存模型，特别是内存序的部分进行一些深入的探讨，主要包含了以下内容

• 关于 C++11 的内存模型
  • 内存模型的重要性
  • 内存模型是什么
• C++ 内存模型之内存布局
• C++ 内存模型之内存序
  • 操作间关系
    • sequenced-before 关系
    • synchronizes-with 关系
    • happens-before 关系
  • 修改顺序和 Visible side-effects
  • C++ 内存序模型
    • Relaxed Ordering
    • Release-Acquire Ordering
    • Sequential Consistent Ordering
    • 总结
• 内存栅栏(Memory Fence)
  • Acquire Fence
  • Release Fence
  • Full Fence
• Reference

关于 C++11 的内存模型

内存模型的重要性

纵观计算机的发展史，多线程概念的提出要远慢于操作系统和编译器的实现。在多线程提出以前，编译器和操作系统认为程序当中仅有一个执行流，很多编译器以及处理器的优化都建立在这个假设之上。而在多线程程序大行其道的今天，这种假设已经不再成立。编译器以及处理器的优化可能会对多线程程序的运行造成影响，主要体现在以下几方面：

• 因编译器的优化而导致的指令重排：
• CPU 的乱序执行
• 多核 CPU 的 Cache 不一致问题
  一些编译器，如 gcc 在编译代码时可以通过 -O 参数来指定优化级别，而其中就包含了指令重排的优化。例如 gcc 可以将程序中彼此没有依赖关系的访问内存操作放在一起，并为其生成相应的汇编代码。

对于 CPU 而言，存在乱序执行的一个直观例子就是计算机组成原理中，在讲解流水线时所提到的数据冒险。

而对于多核系统而言，往往多个核心之间配备有不同的 L1 Cache 和 L2 Cache，如图示：

如果 cache 采用写回法的缓存策略，每次只在将 cache 块替换出去时才将 cache 块中的数据写回内存。那么当 core1 和 core2 访问并修改相同数据时，就会面临数据不一致的问题。

由于存在上述的优化操作，开发人员编写的多线程程序在最终运行时往往表现出和他们一开始预期的不同，这就导致了 bug 的产生。为了解决上述问题，C++ 11 引入了新的内存模型。事实上，有研究^[0]表明，只有在语言层面上提出内存模型，才可以使得编译器对多线程程序进行优化变成可能。

除了对于 C++11 中引入的标准线程库具有重大意义以外，对 C++ 内存模型，特别是其中的内存序的了解，也有助于让开发者在程序中引入 Lock-Free 策略，更好地提高多线程程序的并发性^[1]。

内存模型是什么？

C++11 中的内存模型本质上是一套行为规范，它包括了两个层面的内容，一个是结构层面的内容 —— 内存布局，描述了在语言视角下数据是如何存放于内存当中，另一个是并发层面的内容 —— 内存序， 描述一个线程对某个共享对象的修改何时能够被其他线程看到。而编译器在对 C++ 11 下的多线程程序进行编译及优化时，必须遵守这一套行为规范，特别是其中关于内存序的要求。

C++ 内存模型之内存布局

在 C++ 中，所有的数据都是对象，而所谓的对象就是一片有属性的内存区域，其中属性包括了对象的类型以及生命周期能。不论对象的类型是什么，一个对象都必然占据一个或多个内存位置(Memory Location)。

每一个内存位置上的必定是以下两种情况之一：

• 标量类型，包括数字类型、指针类型、枚举类型以及 nullptr_t
• 相邻位域的最大序列

例如以下代码：

1
2
3
4
5
6
7
8
9
10

struct my_data{
int var_1;
    double var_2;
    unsigned var_3:10;
    int var_4:25;
    int:0;
    int var_6;
    char* var_7;
    std::string var_8;
};

C++ 内存模型之内存序

操作间的关系

sequenced-before 关系

sequenced-before 是一种非对称，可传递的成对关系，它描述了在同一线程下，表达值求值的顺序。有以下几种可能：

• A sequenced-before B：A 的求值将会在 B 的求值开始之前完成
• A 与 B 之间不存在任何方向的 sequenced-before 关系：
  • A 与 B 的求值之间不仅是无序的，且彼此之间可以重叠(CPU 交替执行 A 与 B 的求值指令)。
  • A 与 B 的求值之间是无序的，但彼此之间不可重叠。

通常而言，同一线程下的顺序语句在语义上总是符合 sequenced-before 关系的。例如 A 语句位于 B 语句之前，那么语义上满足 A sequenced-before B，但由于编译器的优化，实际执行中可能是 B 语句先执行。例如：

1
2
3
4
5
6
7

// 语义上符合 ① sequenced-before ②
// 但实际上，最终执行结果可能是先执行 ②; 再执行 ①
int a = 10;// ①
int b = 100;// ②
// 语义上符合 ③ sequenced-before ④，且由于存在依赖关系，因此 ③ 会在 ④ 之前执行
int var = 1024;// ③
++var;// ④

synchronizes-with 关系

synchronizes-with 描述的是一种线程间的同步关系，如果 A synchronizes-with B， 那么可以确认 A 状态在 B 执行之前一定是可见的。像原子操作的 acquire-release、mutex 的 lock 与 unlock，thread 的 create 与 join 之间都可以构成 synchronizes-with 关系。使用 synchronizes-with 可以用来构成 inter-threads happen-before 关系

happens-before 关系

A、B 是两个在多核 CPU 上执行的操作。如果 A happens-before B，那么 A 所产生的内存变化会在 B 执行之前被看到（visible）。happens-before 主要包含了两种情况：

• 如果 A 和 B 位于同一线程内，当 A sequenced-before B 时，可以说 A happens-before B
• 如果 A 和 B 位于不同的线程内，当 A inter-threads happens-before B 时，可以说 A happens-before B

inter-threads happens-before 关系，顾名思义，就是发生在线程间的 happens-before 关系。它包含但又不限于前面所提到的 synchronizes-with 关系。例如

1
2
3
4
5
6
7
8
9
10
11

// write thread
void writer_thread(){
 data.push_back(42); // ①
 data_ready=true; // ②
}
// read thread
void read_thread(){
 while(!data_ready.load())// ③
 std::this_thread::sleep(std::milliseconds(1));
 std::cout<<”The answer=”<<data[0]<<”\n”; //④
}

从上述代码中，① sequenced-before ②、③ sequenced-before ④、② synchronizes-with ④，因此我们有 ① happens-before ④， ② happens-before ④。

修改顺序 和 Visible side-effects

C++ 标准中对 side-effects 的定义如下：

[intro.execution]:

Reading an object designated by a volatile glvalue (3.10), modifying an object, calling a library I/O function, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment.

简单地说，所谓的 side-effect 就是指当执行完一个对表达式的求值操作后，导致了被操作对象状态的改变。例如 执行完 int var = 10; int i = var++;后，表达式 var++的结果是 10，但 var 的状态发生了改变(从10 变成11)，那么 var++就产生了一个 side-effect.

在 C++ 中对于某个特定的原子变量的所有访问操作都存在一个修改序列。对于程序的每次运行而言，这一修改序列可能不同，但针对具体的某一次运行，都必然有一个确定的顺序。而所谓的修改顺序的一致性，就是指所有访问该原子变量的线程都只会看到同一个修改序列。换句话讲，一旦这个原子变量的状态发生改变，那么这个改变后的状态应当同步给所有的线程，这样就避免了在访问同个原子变量的多个线程之间出现数据不一致的问题。

C++ 内存序模型

内存序的定义：

1
2
3
4
5
6
7
8

typedef enum memory_order {
    memory_order_relaxed,
    memory_order_consume,
    memory_order_acquire,
    memory_order_release,
    memory_order_acq_rel,
    memory_order_seq_cst
} memory_order;

注意：由于 C++ 17 中重新修订了 release-consume ordering 的规范，C++ 并不提倡使用 memory_order_consume，因此在接下来的讨论中，我们将不会涉及 memory_order_consume的讨论。

C++ 中提供了三种不同的内存序，按照约束条件强弱划分，由弱到强可分为：Relaxed Ordering、Release-Acquire Ordering 以及 Sequential Consistent Ordering。它们和 C++ 中的 memory_order 之间的关系如下：

为了更清晰的说明问题，我将 memory_order 和相关的内存序模型放在一起讨论。

Relaxed Ordering

Relaxed Ordering: 这一模型是 C++ 内存序模型中约束条件最宽松的。对于指定了 memory_order_relaxed的原子操作，C++ 语言做出了以下两个承诺(注意黑体字)：

• 操作是原子性的
• 对于某个特定的原子变量，保证其在线程内的修改一致性，对于跨线程的修改一致性不做任何保证。

我们可以看一下下面这段代码：

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

#include <atomic>
#include <thread>
#include <assert.h>
std::atomic<bool> x,y;
std::atomic<int> z;
void write_x_then_y(){
x.store(true,std::memory_order_relaxed);// ①
y.store(true,std::memory_order_relaxed); // ②
}
void read_y_then_x(){
while(!y.load(std::memory_order_relaxed)); // ③
if(x.load(std::memory_order_relaxed)) // ④
++z;
}
int main(){
x=false;
y=false;
z=0;
std::thread a(write_x_then_y);
std::thread b(read_y_then_x);
a.join();
b.join();
assert(z.load()!=0); 
}

在下面这段代码中，assert(z.load()!=0); 是有可能会被触发的。这是因为对于线程 a 而言，交换 ① 和 ② 并不违背 Relaxed Ordering 所作出的承诺：① 和 ② 分别操作的是 x 和 y 两个原子变量，且 x 和 y 各自的修改序列中就只包含了一个操作，因此C++ 允许编译器或 CPU 对 ① 或 ② 进行指令重排。一旦 ① 和 ② 的指令顺序对调，且线程 a 与 b 的执行序列变成 ② => ③ => ④ => ①，那么 assert(z.load()!=0); 就会发生。

Release-Acquire Ordering

在讨论 Release-Acquire ordering 之前，我们需要先知道以下两个概念以及一个例子：

• Acquire Operation: 被标记为 memory_order_acquire 或 memory_order_acq_rel 的 load 操作，或者 mutex 的 lock 操作，相当于读操作

• Release Operation: 被标记为 memory_order_release 或 memory_order_acq_rel 的 store 操作，或者 mutex 的 unlock 操作，相当于写操作

假设现有两个线程 A 和 B，以及一个全局的原子变量 var，如果 A 先对 var 执行了 release 操作(store操作)，而 B 后对 var 执行了 acquire 操作(load操作)，那么当 B 执行完 load 操作后，它将能够看到 A 在 store 操作之前所执行的所有写操作(不管是对非原子变量还是其他的原子变量)，如下图：

从上面的例子可以看出，Release-Acquire Ordering 为不同线程中对同一原子变量的一对 acquire 操作和 release 操作之间引入了 synchronizes-with 关系，它做出如下承诺：

• 任何发生在 release 操作之前的读写操作都不会被重排到 release 操作之后
• 任何发生在 acquire 操作之后的读写操作都不会被重排到 acquire 操作之前

另外，这层关系只存在于执行 acquire 操作和 release 操作的两个线程 A 和 B 之间。换言之，如果有其他线程(比如 C)正在运行，那么 Release-Acquire Ordering 并不对 C 所看到的修改序列做任何保证。换句话讲，C 看到的 A 对变量的修改序列既有可能和 B 看到 A 的修改序列相同，也有可能不同，语言不做保证，具体的情况由编译器或 CPU 的优化结果决定。

对于前面 Relaxed Ordering 中的例子而言，我们只需要指定 y 的 load 和 store 操作序列为 Release_Acquire Ordering 就可以确保assert(z.load()!=0);不会被触发。

1
2
3
4
5
6
7
8
9

void write_x_then_y(){
x.store(true,std::memory_order_relaxed);// ①
y.store(true,std::memory_order_release); // ②
}
void read_y_then_x(){
while(!y.load(std::memory_order_acquire)); // ③
if(x.load(std::memory_order_relaxed)) // ④
++z;
}

另外，在一些重视指令执行序列(strongly-ordered)的硬件平台，如 x86 等，大多数操作都是符合 Release-Acquire Ordering 的，编译器在编译程序时无需生成额外的指令来保证 Release-Acquire Ordering。而在一些弱序性(weakly-ordered)的硬件平台，如 ARM 上，则需要通过内存栅栏(memory fence)来实现。

总的来说，Release-Acquire Ordering 相当于提供了两条”基线”，位于 release 线之前的相关指令不能越过这条线到这条线之后去执行，而位于 acquire 线之后的相关指令则不能越过 acquire 线跑到前面去执行。另外，由于 std::mutex 本身的 lock 与 unlock 也属于 acquire 和 release 操作，因此也符合 Release-Acquire Ordering，其中临界区的概念就是被 acquire 线和 release 线所包围的那片区域。

Sequential Consistent Ordering

Sequential Consistent Ordering 是C++ 所提供的内存序中约束性最强的一种，它将 Release-Acquire Ordering 中，对同一原子变量的修改序列从只在执行 release 操作的线程和执行 acquire 操作的线程之间保持同步，推广到了在全局所有线程中保持同步。换句话讲，套用 Release-Acquire Ordering 的例子，在使用 Sequential Consistent Ordering 的情况下，C 线程看到的 A 线程中对变量的修改序列和 B 线程看到的 A 线程中对变量的修改序列是完全一致的。

任何指定为 memory_order_seq_cst 或采用默认内存序的原子操作都采用此内存序。

我们可以将前面的例子扩展到多个线程，如下：

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

#include <atomic>
#include <thread>
#include <assert.h>
std::atomic<bool> x,y;
std::atomic<int> z;
void write_x(){
    x.store(true, std::memory_order_seq_cst);
}
void write_y(){
    y.store(true, std::memory_order_seq_cst);
}
void read_x_then_y(){
    while (!x.load(std::memory_order_seq_cst));
    if (y.load(std::memory_order_seq_cst)) {
        ++z;
    }
}
void read_y_then_x(){
    while (!y.load(std::memory_order_seq_cst));
    if (x.load(std::memory_order_seq_cst)) {
        ++z;
    }
}
int main(){
    x=false;
y=false;
z=0;
    std::thread a(write_x);
    std::thread b(write_y);
    std::thread c(read_x_then_y);
    std::thread d(read_y_then_x);
    a.join(); b.join(); c.join(); d.join();
    assert(z.load() != 0);  // will never happen
}

在上述代码中，只有指定内存序为 Sequential Consistent Ordering 才能确保 assert(z.load() != 0)不会被触发。如果指定操作的内存序为 Release-Acquire Ordering，那么 c 和 d 就有可能会看到关于 x 和 y 的不同的修改序列。

在所有多核硬件系统平台上，Sequential Consistent Ordering 都需要使用 memory fence 指令来实现，因此它会将特定内存位置的访问同步到所有的核中，这可能会造成性能瓶颈。

最后，关于 Sequential Consistent Ordering 有两个值得仔细分辨的点：

• 全局一致的修改顺序强调的是在程序的每次运行下，所有线程都能看到某个原子变量的统一的修改顺序。但是不同次运行中，同一个变量的修改顺序不一定是相同的。例如程序第一次运行所有线程所看到的某一个变量的修改顺序和程序第二次运行所有时所有线程看到的修改顺序不同。
• 在很多情况下，对于同一个线程下不同原子变量的 memory_order_seq_cst 操作是可以被重排序的

总结

C++ 并发编程困难不仅在于开发人员需要捋清不同线程之间复杂的协作关系，还需要在一定程度上对抗编译器和 CPU 所做出的优化。C++ 提供三种不同的内存序，旨在能够让开发者根据自身需要自行选择，以最低限度约束编译器及 CPU 的优化。

从上述三个内存序来看，Relaxed Ordering 只保证了在同线程内的单个原子变量的修改一致性，而 Release-Acquire Ordering 则通过一对 release 和 acquire 操作，将这种修改一致性扩展到了相关的两个线程当中，而 Sequential Consistent Ordering 则将这种修改一致性扩展到了全局的所有线程当中。

内存栅栏(Memory Fence)

在 C++ 中，除了使用原子操作指定内存序以外，还可以通过内存栅栏来指定内存序。根据指定都能内存序的不同，fence 可以分成以下三类：

• acquire fence：指定内存序为 memory_order_acquire 的 std::atomic_thread_fence
• release fene：指定内存序为 memory_order_release 的 std::atomic_thread_fence
• full fence：指定内存序为 memory_order_seq_cst 或者 memory_order_acq_rel 的 std::atomic_thread_fence

对于编译器及处理器的乱序重排，一共可以分为四种情况：

• Load-Load(读后读)
• Load-Store(读后写)
• Store-Load(写后读)
• Store-Store(写后写)

指令重排的结果可以用下面这张图来表示(其中文字代表操作类型，箭头表示指令重排的移动方向)：

如果理解了前面的 Release-Acquire Ordering 中关于 acquire 基线和 release 基线的描述，就可以很容易了理解接下来的内容了。

Acquire Fence

如同前面所提到的 acquire 基线那样， Acquire Fence 可以防止 Fence 后的读写操作重排到 Fence 前的任意 load 操作之前，即抑制 Load-Load 重排和 Load-Store 重排，如下图：

Release Fence

如同前面所提到的 release 基线那样， 防止 Fence 前的读写操作重排到 Fence 后的任意 store 操作之后，即抑制 Load-Store 重排和 Store-Store 重排，如下图：

注意：Acquire Fence 和 Release Fence 在同步关系上的约束性其实要比 Release-Acquire Ordering 中相应的”acquire 基线” 和 “release 基线”要强，我想可能是因为在 Release-Acquire Ordering 中 “acquire 基线”本身就是一个 acquire 操作，”release 基线”本身也是一个 release 操作。而 Acquire Fence 和 Release Fence 严格意义上并不算操作。

Full Fence

Full Fence 就相当于是前面 Acquire Fence 和 Release Fence 功能的并集，它能够抑制 Load-Load、Load-Store 以及 Store-Store 重排，但是它不能抑制 Store-Load 重排。

回到前面 Relaxed Ordering 的例子中，我们也可以通过 Release Fence 来防止语句 ① 和语句 ② 之间的重排序，例如：

1
2
3
4
5
6
7
8
9
10
11

void write_x_then_y(){
x.store(true,std::memory_order_relaxed);// ①
    std::atomic_thread_fence(std::memory_order_release);
y.store(true,std::memory_order_relaxed); // ②
}
void read_y_then_x(){
while(!y.load(std::memory_order_relaxed)); // ③
    std::atomic_thread_fence(std::memory_order_acquire);
if(x.load(std::memory_order_relaxed)) // ④
++z;
}

Reference

[0]. 《Threads Cannot be Implemented as a Library》—— Hans-J. Boehm

[1]. An Introduction to Lock-Free Programming

[2]. 《C++ Concurrency In Action》 —— Anthony Williams

[3]. 《C++11 Momery Model》 —— Scott B. Baden

[4]. cppreference.com:memory-order

[5]. cppreference.com:std::atomic_thread_fence

本文并不是一篇关于Smart Pointer的基础文章，它假定阅读读者至少使用过 C++11 下的 Smart Pointer，因此文章中并不涉及 Smart Pointer 的基础用法，而是希望讨论一些更深层次的东西，主要包含了以下内容

• 引用型 Smart Pointer 的内存布局以及相关推论
• make_shared 的优劣
• enable_shared_from_this 与 shared_from_this 的实现
• weak_ptr 的内存布局及相关应用
• unique_ptr 与 PImpl Idiom 的相关问题
• Reference

引用型 Smart Pointer 的内存布局

在 C++11 中，shared_ptr的大小为裸指针的两倍，它包含两个数据成员：一个指向共享资源的指针和一个指向控制块的指针。控制块中存放了引用计数、用户自定义删除器的副本以及分配器的副本(后两个要求用户显式指出)，而结构如下：

从 shared_ptr 的内存布局可以看出，我们可以得出以下三个结论和两个问题：

结论一：用户定义的 deleter 和 allocator 与 shared_ptr 的类型无关

用户自定义的 deleter 和 allocator 并不属于 shared_ptr 类型的一部分。换言之，不论用户定义的 deleter 是函数指针、functor 抑或是 lambda，都不影响 shared_ptr 的最终大小。其次，对于指向同一类型对象，但是定义了不同 deleter 的 shared_ptr而言，它们之间没有类型差异，可以共存于同一个容器当中，例如下面的代码是可以通过编译的：

1
2
3
4

shared_ptr<Object> p1(new Object, customDeleter1);
shared_ptr<Object> p2(new Object, customDeleter2);
shared_ptr<Object> p3(new Object);
std::vector<shared_ptr<Object>> vec{p1, p2, p3};

结论二：对 Object 的读写无法是原子的

对于 shared_ptr 而言，对对象的读写操作分成了两个部分，一个是对 Object 的访问，另一个则是对 reference count的更新操作。对于后者而言，在主流平台上的实现都是原子操作，而且没有用到锁机制，性能不俗。但是由于读写 Object 和更新 reference count 是两个不同的操作，shared_ptr 没有提供额外的机制来保证这两个操作的原子性，因此不论Object的读写是不是线程安全的，shared_ptr本身也不是 100% 线程安全的。因此在多线程环境下读写同一个shared_ptr还是需要使用 mutex 进行保护的。

结论三：从原则上，Object 与 Control Block 在空间上不必是相邻，这在内存分配时可能会带来潜在的效率及安全问题

从内存布局上可以看出, shared_ptr中的Object和Control Block在空间上不必是相邻的，这会带来一些运行效率上的问题，例如auto ptr = shared_ptr<Object>(new Object)可能会涉及两次内存分配，带来一些额外的开销，也可能会带来安全性的问题，例如 new Object 执行成功了，但是因为某种原因导致new出来的指针没有及时存入到shared_ptr中，造成了内存的泄漏。关于这个问题的解决方案，我会在后面的 make_shared 部分来讨论。

问题一：Control Block 中的 weak count 和 reference count 有什么区别？

在 C++ 中，析构与释放内存并不是同义词。对于new和delete而言，前者的工作是先开辟一片内存空间，然后在该内存空间上执行构造函数，构造完毕后将句柄返回给调用者，而后者的工作则是先在指定的内存空间上执行析构函数，完成一些清理善后工作，之后将这片内存空间归还给操作系统。由此可以看出，析构和内存释放其实是两个过程。回到这个问题上，**Control Block中的reference count决定了Object会在何时被析构，而weak count决定了Control Block所占用的内存区域何时被释放**。

问题二：什么样的行为会导致 Control Block 的创建？

对于指向同一个Object的多个shared_ptr而言，维护它们的Control Block的唯一性至关重要。以下的三种构造方式会触发Control Block的创建：

• 使用裸指针来构造shared_ptr
• 使用unique_ptr来构造shared_ptr
• 使用make_shared来构造shared_ptr

因此，使用同一个裸指针反复创建多个shared_ptr不仅不能使shared_ptr发挥它们应有的功能，还可能会带来安全问题：只要其中一个shared_ptr被析构，那么对剩下的任何一个shared_ptr执行解引用操作都会导致未定义行为

除了上述的三种行为外，使用weak_ptr来构造shared_ptr、或者通过拷贝构造、拷贝赋值、移动构造、移动赋值的方式构造shared_ptr也不会导致Control Block的创建。其中，出于效率的考虑，使用移动赋值和移动构造也不会更新reference count信息。

make_shared 的优劣

针对前面结论三中所提到的效率及安全问题，我们先上一小段代码来进一步说明问题：

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

void Process(std::shared_ptr<Object> spw, int priority){
    //... do something;
}
int computePriority(const string& key){
    int priority = 0;
    // ... calculate priority by key
    return priority;
}
int main(){
 //...   
    Process(std::shared_ptr<Object>(new Object), computerPriority("Window"));
}

对于上述代码，当执行语句Process(std::shared_ptr<Object>(new Object), computerPriority("Window"));,需要先进行参数的计算，但参数计算顺序是不确定的。换句话讲，语句Process(std::shared_ptr<Object>(new Object), computePriority("Window"));的执行顺序可能是：

1. 执行 new Object，在堆内存上构造出 Object 对象
2. 执行 computePriority(“Window”) 函数
3. 将 new Object所得到的指针包装成 shared_ptr对象
4. 将参数传递给 Process执行

在上述过程中，如果computePriority抛出了异常，那么就会导致步骤 1 中 new 出来的指针无法及时存放到shared_ptr中，从而无法自动执行析构，造成了内存的泄漏。

对于上述问题，一个最简单的方式便是将new Object从Process当中分离出来，如：

1
2
3
4
5
6
7

// 此处省略了 Process 与 computePriority 的代码
int main(){
    //...
    int priority = computerPriority("Window");
    auto ptr = shared_ptr<Object>(new Object);
    Process(std::move(ptr), priority);//使用移动构造以避免更新 ptr 的 reference count
}

这种方式解决了前面所提到的内存泄漏的问题，不过依然为Object 和 Control Block 分别分配了内存空间。一种更好的方式是使用 C++ 标准库提供的 make_shared来实现，如下：

1
2
3
4

int main(){
    //...
Process(std::make_shared<Object>(), computePriority("Window"));
}

相较于shared_ptr<Object>(new Object)的方式，make_shared<Object>()会一次性分配好Object和Control Block的内存空间，并在该内存空间上构造Object的对象。这样既解决了前面可能因函数求参顺序不确定而导致的内存泄漏的问题，同时也提高了运行的效率，减少了一次内存的分配。除了安全和效率两个优点外，make_shared还有助于提高程序的可维护性，一方面使用make_shared来构造shared_ptr可以避免产生任何形式的裸指针，也就降低了用户因误用裸指针而导致的shared_ptr出现Control Block信息不一致的可能性，另一方面结合 auto关键字也可以使得shared_ptr与特定类型名称的耦合程度尽可能低，代码改起来工作量也会少一些。

当然，make_shared也不是银弹，也有其自身的局限性。首先，使用make_shared构造shared_ptr无法指定 deleter 和 allocator。其次，将Object和Control Block的内存空间合并虽然提高了效率，但可能会导致这片内存区域迟迟无法被释放。正如前面weak count与reference count的作用时所提到的，当Object 和Control Block不属于同一片内存空间时，一旦reference count降为零，则会析构Object并回收其所占用的内存；当weak count降为零时，则会析构并回收Control Block所占用的内存。若Object和Control Block属于同一片内存空间时，则当reference count降为零时，会析构Object对象，但只有当reference count和weak count都为零时，才会回收这片内存空间。因此，如果当对象占用内存较大，且指向该对象weak_ptr的生命周期要远长于指向该对象的shared_ptr时，使用make_shared就不那么合理了。

enable_shared_from_this 和 shared_from_this 的实现

使用make_shared可以替代new表达式来构造shared_ptr对象，进而降低指向同一对象的shared_ptr出现Control Block不一致的问题。但这种作法并非万无一失，因为最常被用来构造shared_ptr对象的指针除了new句柄，也包括了this指针，例如：

1
2
3
4
5
6
7
8

std::vector<shared_ptr<Object>> vec;
class Object{
public:
    void Process(){
        //...
        vec.emplace_back(this);
    }
};

而解决方法是先继承标准库中的模板基类enable_shared_from_this<T>，并使用shared_from_this代替this指针，具体如下：

1
2
3
4
5
6
7

class Object : public enable_shared_from_this<Object>{
public:
    void Process(){
        //...
        vec.emplace_back(shared_from_this());
    }
};

在上述代码中，Object继承了一个由Object所实例化的模板基类enable_shared_from_this<Object>。这种做法在 CRTP Idiom 中会经常使用到。CRTP 可以通过静态绑定的方法提升继承多态的性能。enable_shared_from_this的一个可能实现如下：

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

template<class D>
class enable_shared_from_this {
protected:
    constexpr enable_shared_from_this() { }
    enable_shared_from_this(enable_shared_from_this const&) { }
    enable_shared_from_this& operator=(enable_shared_from_this const&) {
        return *this;
    }
public:
    shared_ptr<T> shared_from_this() { return shared_ptr<T>(self_); }
    shared_ptr<T const> shared_from_this() const { return shared_ptr<T const>(self_); }

private:
    weak_ptr<D> self_;
    friend shared_ptr<D>;
};

template<typename T>
shared_ptr<T>::shared_ptr(T* ptr) {
    // ...
    // Code that creates control block goes here.
    // ...

    // NOTE: This if check is pseudo-code. Won't compile. There's a few
    // issues not being taken in to account that would make this example
    // rather noisy.
    if (is_base_of<enable_shared_from_this<T>, T>::value) {
        enable_shared_from_this<T>& base = *ptr;
        base.self_ = *this;
    }
}

在 enable_shared_from_this中，包含了一个类型为 weak_ptr<D>的指针self_。当调用shared_from_this函数时，会利用self_来构造shared_ptr，这种做法并不会触发shared_ptr创建Control Block的行为。不过，这种做法要求当前对象在调用shared_from_this()之前必须具备Control Block，否则将触发未定义行为，通常会抛出bad_weak_ptr异常。换言之，使用shared_from_this的对象最好也由shared_ptr管理，否则可能会引发异常。例子可见下面代码：

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

class Object: public enable_shared_from_this<Object>{
public:
    Object(const string& str):name(str){}
    void test(){
        auto ptr = shared_from_this();
        cout << ptr->name << endl;
    }    
private:
    const string name;
};

int main(){
    //Object* ptr = new Object("Hello");//使用 new 句柄直接调用 test 函数将会引发 bad_weak_ptr 异常
    auto ptr = make_shared<Object>("Hello");
    ptr->test();
    //delete ptr;
}

weak_ptr 的内存布局及相关应用

weak_ptr通常作为shared_ptr的补充，它并不会改变shared_ptr的引用计数。它的大小和shared_ptr相同，且和对应的shared_ptr指向同一个控制块，不过与 shared_ptr 不同的是，weak_ptr 不能直接执行解引用操作。weak_ptr的常用操作主要有以下三个：

作用一: 缓存优化

通常对于访问数据库或是读取文件等耗时的操作，一般都会使用缓存的方式来提高效率。如果使用shared_ptr来管理数据库连接或是文件句柄，则在缓存时要额外注意资源对象的生命周期问题，而weak_ptr为我们提供了一套解决方案，例如：

1
2
3
4
5
6
7
8
9
10
11

std::unique_ptr<const Object> loadObject(ObjectID id);
std::shared_ptr<const Object> fastLoadObject(ObjectID id){
    static std::unordered_map<ObjectID, std::weak_ptr<const Object>> cache;
    auto objPtr = cache[id].lock(); 
    // to cached object (or null if object's not in cache)     
    if (!objPtr) { // if not in cache,         
        objPtr = loadObject(id); // load it
        cache[id] = objPtr; // cache it     
    }
    return objPtr;
}

使用weak_ptr来做缓存可以避免额外延长资源的生命周期，使得资源在使用结束后能够及时地被回收，同时使用weak_ptr的lock函数可以判断当前的weak_ptr所指向的对象是否已被删除，如果被删除，则返回空的shared_ptr对象。如果没有被删除，则weak_ptr会提升为shared_ptr，进而我们就可以对其进行相关的操作。这种让强弱引用相互搭配以避免影响资源回收的做法比较常见，典型有如 lua 语言中，使用对偶表示来实现私有性时，将外部表设置为弱引用键表，这样才能让 GC 在适当的时候能够顺利的回收内存。

作用二：解决悬空指针问题

关于如何使用weak_ptr解决悬空指针问题，主要有三种方法:

• 利用weak_ptr的lock函数对weak_ptr进行提升，具体的做法可见前面的作用一:缓存优化的内容；
• 利用weak_ptr构造shared_ptr，具体的做法可以见前面enable_shared_from_this的实现，这里不多做赘述；
• 利用weak_ptr的expired函数，如下：

1
2
3
4
5
6
7

void process(weak_ptr<Object> objPtr){
    //...
    if(objPtr.expired()){
        //do something
    }
    //...
}

前两种方法不仅涉及了对指针是否悬空的判断，还涉及到了对Object的操作。而在第三种方法中，expired()只能判断当前的weak_ptr是否悬空，但由于weak_ptr不能直接解引用，因此如果需要对Object进行相应的操作，就必须手动将weak_ptr提升为shared_ptr，这样就需要使用锁机制来保证原子性。

作用三：解决环形引用问题

当上图中 B 也持有了一个指向 A 的 shared_ptr 时，就会引发”环形引用”问题：A 和 B 之间的相互引用会使得它们之间彼此的 reference count 至少为1，这就使得 A 和 B 所占用的资源迟迟不能被回收，造成了内存的泄漏。解决这一问题的方法便是让 B 持有一个指向 A 的 weak_ptr 而非 shared_ptr。由于 weak_ptr 不会增加 reference count，因此 A 所占有的资源可以先于 B 被释放，一旦 A 释放了，那么 B 被释放也只是时间上的问题。

unique_ptr 与 PImpl Idiom 的相关问题

unique_ptr 的类型

默认 deleter 的std::unique_ptr 的大小与裸指针一致，而且大部分操作(例如解引用)采用了相同的指令，因此从效率及空间利用率上来讲，std::unique_ptr都可以代替裸指针使用。若用户采用了自定义的 deleter，则std::unique_ptr 的大小还会受到 deleter 的影响:

• 当 deleter 是函数指针时，std::unique_ptr 会增加 4 或 8 个字节的大小(取决于指针大小)
• 当 deleter 是函数对象时，std::unique_ptr 所增加的大小取决于函数对象中所存储的数据成员
• 当 deleter 是无捕获列表的 lambda 表达式时，std::unique_ptr 则不会增加额外的大小。

因此在自定义 deleter 时要优先考虑无捕获列表的 lambda 表达式

std::unique_ptr提供了指向 T 类型数组的类型 —— std::unique_ptr<T[]>。根据定义方式的不同，std::unique_ptr也提供了不同的接口来针对不同的实现。例如数组型的 unique_ptr 不支持解引用运算(比如 * 和 ->)，但支持 [] 运算

另外，std::unique_ptr可以很方便的转化为 std::shared_ptr，且转换的过程会创建 Control Block, 但反之则不行

unique_ptr 与 PImpl Idiom

正如前面所说，deleter 作为 unique_ptr 类型的一部分，不仅体现在 deleter 的类型会影响 unique_ptr 所占用空间的大小，还体现在了 PImpl Idiom 上。 在 C++ 中，PImpl 是一种常用的技巧，合理运用可以减少编译时间，例如：

1
2
3
4
5
6
7
8
9
10

//Object.h
class Object {
public:
     Object();
     …
private:
     std::string name;
     std::vector<double> data;
     Gadget g1, g2, g3; // Gadget is some user-defined type
};

在上述代码中，每当 Gadget.h 发生变更时，所用使用到 Object的文件都需要重新编译。现在采用 unique_ptr和 pImpl 的方法来解除 Object 和 Gadget 依赖关系，如下：

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

//Object.h
class Object {
public:
    Object();
 …
private:
struct Impl; // declare implementation struct
std::unique_ptr<Impl> pImpl;
};
//Object.cpp
#include "Object.h" 
#include "gadget.h"
#include <string>
#include <vector>
struct Object::Impl { // as before
std::string name;
std::vector<double> data;
    Gadget g1, g2, g3;
};
Object::Object() : pImpl(std::make_unique<Impl>()) {}
//client.cpp
#include "Object.h"
int main(){
    Object w; // error!
}

对上述代码进行编译，我们会得到一个错误信息：

1

$ error: invalid application of ‘sizeof’ to incomplete type ‘Object::Impl’

在上述代码中，当需要析构对象 w 时，由于我们没有为 Object 显式定义析构函数，因此编译器会为我们生成相应的析构函数并将其内联到相应的位置，并调用 unique_ptr<Impl> 的析构函数。由于 unique_ptr<Impl> 采用的是 default deleter，它会先对中所持有的Impl*进行静态类型检查static_assert，以确保Impl*指向了一个完全类型。不过因为这段析构代码是由编译器生成并内联到了指定位置的，因此编译器看不到位于 Object.cc 文件中的 Impl 的详细定义，进而认为Impl*指向了一个不完全类型，触发了编译错误

一旦明白了原因，那么解决方案就很清晰了：只需要在实现文件Object.cc的 Impl 定义的后面补上析构函数的定义即可，具体做法如下：

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

//Object.h
class Object { 
public:
    Object();
    ~Object(); // dtor is needed—see below
 …
private:
struct Impl; // declare implementation struct
std::unique_ptr<Impl> pImpl;
};
//Object.cpp
#include "Object.h" 
#include "gadget.h"
#include <string>
#include <vector>
struct Object::Impl { // as before
std::string name;
std::vector<double> data;
    Gadget g1, g2, g3;
};
Object::Object() 
: pImpl(std::make_unique<Impl>()) // std::unique_ptr
{}
Object::~Object() = default;
//Client.cpp
#include "Object.h"
int main(){
    Object w; // no error
}

通过显式地定义了函数体，编译器在析构时就能够看到 Impl 的定义，自然也就不会产生 delete incomplete type 的错误了

而使用 shared_ptr 则没有上述的限制，例如：

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

//Object.h
class Object { 
public:
 Object();
 … // no declarations for dtor or move operations
private:
 struct Impl; 
 std::shared_ptr<Impl> pImpl; // std::shared_ptr
}; 
// Client.cpp
#include "Object.h"
int main(){
    Object w1;
auto w2(std::move(w1)); // move-construct w2
w1 = std::move(w2); // move-assign w1
}

上述代码可以正常通过编译并且运行。

这一切都源自于 unique_ptr 和 shared_ptr之间关于 deleter 的支持方式上的差异。对于 unique_ptr 而言，deleter 以合成（composition）的方式包含于 unique_ptr 之中，需要在编译期执行类型检查，这种的 deleter 被称之为 static deleter。而对于 shared_ptr 而言，deleter 以聚合（aggregation）的方式存在于shared_ptr之中，不需要在编译期执行检查，这种 deleter 被称之为 dynamic deleter。

关于 unique_ptr 和 shared_ptr 在不同场合下对类型的要求可见下表，其中 I 表示 Incomplete Type，C 表示 Complete Type，而 N/A 表示不支持该函数

Reference

[0]. 《Effective Modern C++》
[1]. 《Linux 多线程服务端编程 —— 使用 muduo C++ 网络库》
[2]. How std::enable_shared_from_this::shared_from_this works
[3]. Is std::unique_ptr required to know the full definition of T?

本文主要涉及了对 C++ 语言中 lvalue、xvalue 和 rvalue 的一些探讨，主要包括以下内容

• 一段有趣的代码
• C++ 中的 Expression Category Taxonomy
• prvalue 的作用以及判定标准
• xvalue 的定义及判定标准
• lvalue 的定义及判断标准
• 关于 glvalue 与 rvalue
• Reference

本文按照先总后分，自底向上的逻辑讨论，先论述 C++ 中的 Expression Category Taxonomy，再到底层的 prvalue、xvalue 以及 lvalue，最后回到 glvalue 及 rvalue 上。

起因：一段有趣的代码^[0]

在前一段时间，我写出了如下的一段代码：

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

// value.cc
#include <iostream>
using namespace std;

class A{
public:
    void sendByRvalue(string&& str){
        cout << str << endl;
    }
};

class B{
private:
    A a;
    void send(string&& str){
        a.sendByRvalue(str);
    }
public:
    void run(const string& str){
        send("run " + str + "\n");
    } 
}; 

int main(void){
    string str("hello world");
    B b;
    b.run(str);
    return 0;
}

这段代码看似平平无奇，但当我对其进行编译时，我却得到了如下的错误信息：

1
2
3

$ clang++ value.cc -std=c++11
$ error: rvalue reference to type 'basic_string<[...]>' cannot bind to lvalue of type 'basic_string<[...]>'
        a.sendByRvalue(str);

从错误的信息来看，出错的原因应该是我试图将一个左值 str 传递给一个参数类型为 rvalue reference 的 sendByRvalue 函数。等等，好像哪里不对？str 本来就是一个 rvalue reference 啊。起初我怀疑是 str 在传递给 send 函数时发生了突变，导致在执行send函数体时变成了 lvalue，于是我对代码做了一点修改：

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

class B{
private:
    A a;
    void send(string&& str){
        cout << boolalpha << is_rvalue_reference<decltype(str)>::value << endl;
        a.sendByRvalue(std::move(str));
    }
public:
    void run(const string& str){
        send("run " + str + "\n");
    } 
}; 

现在，代码能够正常编译并运行，但是代码的运行结果却使我大跌眼镜：

1
2

$ true
$ run hello world

显然，str 在传递给 a.sendByRvalue 前还是 rvalue reference。然而，结合之前编译器的错误信息，我们竟然能够得出这样一个结论：一个右值引用变量居然不能传递给一个参数类型为右值引用的函数！？ 这是咋回事？？

C++ 中的 Expression Category Taxonomy

在 C++ 中，任何表达式都具备两个独立的属性：类型(type)和值类别(value category)。关于表达式的 type，指的是常量表达式，整型表达式等概念，而 value category 虽然名字上带有 value，但实际上描述的是表达式而非值，主要包括 glvalue、rvalue、lvalue、xvalue 以及 prvalue，它们之间的关系如下图：

cpp reference 上为这种分类方法提供了解释依据：

With the introduction of move semantics in C++11, value categories were redefined to characterize two independent properties of expressions:

• has identity: it’s possible to determine whether the expression refers to the same entity as another expression, such as by comparing addresses of the objects or the functions they identify (obtained directly or indirectly);
• can be moved from: move constructor, move assignment operator, or another function overload that implements move semantics can bind to the expression. ^[1]

从上述解释中，我们可以知道 C++ 11 中对于表达式值分成 glvalue 和 rvalue 的主要原因。早期的 C++ 标准不支持移动语义，因此对于表达式的类别的判断依据仅为是否拥有 “identity”, 这也就将表达式的类别一分为二，分为了 lvalue 和 rvalue。在 C++ 11 标准中引入了移动语义后，标准将 has identity 的表达式定为 glvalue， 而将can be moved from的表达式定为 rvalue，并根据这两种属性两两组合，得到了以下的 4 种可能：

• have identity and cannot be moved from are called lvalue expressions;
• have identity and can be moved from are called xvalue expressions;
• do not have identity and can be moved from are called prvalue (“pure rvalue”) expressions;
• do not have identity and cannot be moved from are not used.

prvalue 的作用以及判定标准

我们先来看看 prvalue，所谓的 prvalue 是 Pure rvalue 的缩写。prvalue 主要包括以下两种：

• 用于计算与对象无关的值(computes a value that is not associated with an object)
• 创建出来的临时对象

这里简单地解释一下什么叫做与对象无关的值(a value that is not associated with an object)。在 C++ draft 当中是这样解释 object 的：

The constructs in a C++ program create, destroy, refer to, access, and manipulate objects. An object is created by a definition, by a new-expression , by an operation that implicitly creates objects (see below), when implicitly changing the active member of a union, or when a temporary object is created . An object occupies a region of storage in its period of construction , throughout its lifetime, and in its period of destruction. ^[2]

在 C++ 中，所谓的对象是指一个存储区域，这块存储区域需要通过对定义式或 new 表达式显式或隐式地调用来创建。而与对象无关的值，实际上指的就是那些没有相应存储区的值，例如除了字符串字面值以外的所有字面值。

在 C++ 中，属于 prvalue 的表达式有以下几种：

• 除了字符串字面值以外的所有字面值，如 12, true 或者 nullptr
• 返回值类型为 non-reference 类型的函数调用表达式，包括了一般形式的函数调用，如 f()，也包括了重载过的函数运算符，如 “str1 + str2”
• 返回临时值的 built-in 运算符表达式，例如 a++, a + b, &a, a < b 等
• 将对象转换为 non-reference 类型的 cast 表达式，如 static_cast<double>(x)
• 任何枚举值都是 prvalue，也包括定义在类中的枚举值，如 obj.m 或 obj_ptr->m，其中 m 是枚举值
• this 指针
• lambda 表达式

为了避免和前面非对象类的 prvalue 判断相混淆，我特地将类对象的 prvalue 的部分单独拎出来，放在了下面：

针对成员变量：

• 若对象 obj 是 rvalue，则形如 obj.m 与 obj.*mp 为 prvalue，其中 m 为 non-static 的 non-reference 类型的成员变量， mp 为指向数据成员的指针

针对成员函数(注意，此处函数指的是函数本身obj.func，而不是函数调用obj.func())：

• 当 func 为 obj 的 non-static 成员函数时， obj.func 和 obj_ptr->func 也为 prvalue。
• 当 func_ptr 为指向对象成员函数的函数指针时，则obj.*func_ptr 和 obj->*func_ptr 均为 prvalue

xvalue 的定义及判定标准

接下来看看 xvalue，所谓 xvalue 是 eXpiring value 的缩写，代表了资源在回收前可以被重复利用的 glvalue。在 C++ 当中，类型为 xvalue 的表达式有以下四种：

• 对类型为 rvalue 类型的数组进行 built-in 的下标运算，如 arr[n]
• 对于形如 obj.m 或 obj.*mp 的表达式，如果 obj 是 xvalue，或者 m 为 non-static、non-reference 的数据成员，或者 mp 为指向数据成员的指针，则 obj.m 与 obj.*mp 为 xvalue
• 当 obj 为 rvalue 时，且 m 为 non-static non-reference 类型的数据成员，mp 为指向数据成员的指针，则 obj.m 或 obj.*mp 为 xvalue
• 返回类型为 rvalue reference 的函数调用表达式，包括了一般的函数调用以及重载运算符，如 std::move(x)
• 将一个对象强制转换为 rvalue reference 的表达式，如 static_cast<int&&>(obj)

lvalue 的定义及判断标准

最后来看看 lvalue，所谓的 lvalue 最初是指那些可以被放在 built-in 赋值运算符左侧的表达式，然而随着 C++ 语言的演化，这一说法也变得不再准确。在新版本中，lvalue 被定义为那些属于 glvalue 但是不属于 xvalue 的表达式类型。lvalue expression 都符合以下条件：

• 任何有名字的变量，函数，数据成员，无论其类型是什么，一律都是 lvalue。即便是 rvalue reference 类型的具名变量，其 value category 也是 lvalue
• 任何返回类型为 lvalue reference 的函数调用表达式，其中函数调用也包括了以重载运算符形式进行的调用
• 任何返回类型为对函数的 rvalue reference 的函数调用表达式，其中函数调用也包括了以重载运算符形式进行的调用
• 任何返回类型为 lvalue reference 的 built-in 运算符表达式，例如 ++a，a += b 等。
• 对 lvalue 类型数组 arr 执行 built-in 的取下标运算符, 如 arr[n]
• 对指针变量 p 的解引用操作，如 *p 或者 p[n]
• 字符串字面值，如 HelloWorld
• 将对象强制转换为 lvalue reference 的 cast 表达式，如 static_cast<int&>(x)
• 将对象强制转换为对函数的 rvalue reference 的 cast 表达式，如 static_cast<void (&&)(int)>(x)

和前面相同，这里单独将与对象相关的 lvalue 拎出来讨论：

针对成员变量：

• 对于 obj.m 的表达式，如果 obj 是 glvalue 或者 m 是静态数据成员，则 obj.m 是 lvalue
• 对于 obj.*mp 的表达式，如果 obj 是 lvalue 且 mp 是指向数据成员的指针，则 obj.*mp 是 lvalue
• 对于 obj->*mp 的表达式是 lvalue，其中 mp 是指向其数据成员的指针

针对成员函数(注意，此处函数指的是函数本身obj.func，而不是函数调用obj.func())：

• 若 func 为静态成员函数，则 obj.func 和 obj->*func是 lvalue

这里需要提一下，只有字符串字面值是 lvalue，而其他的字面值都是 rvalue。因为在 C++ 中，任何字符串字面值，例如 “Hello world”，其类型都是数组类型，而不是指针类型。这主要是因为在 C 语言中，数组类型必须作为 lvalue，否则无法兼容 C 语言中的一些用法，比如使用 sizeof(arr) 来求出 arr 所占内存空间的大小。C++ 为了兼容 C 语言，沿袭了这一习惯^[3]。

关于 glvalue 与 rvalue

先来看看 glvalue。在 C++ 11 中，glvalue 代表了 Generalized lvalue, 一个 glvalue 要么是 lvalue，要么是 xvalue，具备以下特征：

• 一个 glvalue 通过隐式转换，如 lvalue-to-rvalue、array-to-pointer 或者 function-to-pointer，转换成为 prvalue
• 一个 glvalue 可以是多态的，其对象的动态类型并不一定需要与表达式的静态类型相一致
• 在表达式允许的范围内，glvalue 可以拥有不完全类型

lvalue 可以视为是对 glvalue 特征的一个补充，它除了具备 glvalue 所有的特征以外，还额外具备以下特征：

• 可以使用 built-in 的取地址运算符 & 为 lvalue expression 进行取地址运算，例如 &++i 是合法的
• 一个可变的 lvalue expression 可作为 built-in 的赋值运算符和复合赋值运算符的左操作数
• 一个 lvalue expression 可以用于被绑定到一个 lvalue reference 上

再来看看 rvalue。在 C++ 11 中， 一个 rvalue 要么是 prvalue，要么是 xvalue，具备了以下的特征：

• 无法使用 built-in 的 & 运算符对其取地址，例如 &int(), &i++ 等都是非法的
• rvalue 无法被放在 built-in 的赋值运算符的左侧
• rvalue 可以绑定到 const lvalue reference 或 rvalue reference 类型的变量上，一旦完成绑定，rvalue 的生命周期将会延长到引用结束

对于 prvalue 而言，除了具备 rvalue 的所有特征外，还额外具备以下特征：

• prvalue 不能是除了 void 以外的不完全类型
• non-class、non-array 的 prvalue expression 不能被 cv 限定符修饰
• 一个 prvalue expression 不具备多态性，其动态类型始终和它的静态类型相一致、

而 xvalue 作为 lvalue 到 prvalue 之间的过渡，它同时具备 rvalue 以及 glvalue 的特征。一个 xvalue 既可以像 rvalue 那样被绑定到 rvalue reference 上，又可以像 glvalue 那样体现出多态的特性。

最后，回到之前的那段代码, 尽管 void B::send(string&& str) 中的参数 str 是一个 rvalue reference，但它依然是一个 lvalue，无法用来初始化一个 rvalue reference，自然也就无法传递给函数 void A::sendByRvalue(string&& str)。

Reference

[0]. Why the rvalue reference parameter cannot be passed between functions directly?
[1]. Cppreference: Value categories
[2]. P0593R5. Implicit creation of objects for low-level object manipulation
[3]. Is a literal, say “Hello world”，a rvalue when I passing it to a template which its paramater is an universal reference? - Stackoverflow

本文是 muduo 网络库源码剖析系列文章的第九篇文章，主要涉及了 muduo 网络库中是如何获取进程信息，又是以什么样的方式展现给客户的，其中包含了以下内容：

• 幕后功臣 ： FileUtil 的实现
• 一种基于 REST 风格的进程监控
• 一种基于 Observer Pattern 实现的进程监控
• 最后一点碎碎念

注：由于这两种进程监控的方法都涉及到了与其他组件的配合，例如 HttpServer、hub 等组件，碍于篇幅原因，本文中不会粘贴过多的代码，主要以图表的形式阐述。本文假定读者了解 Http 协议， Observer Pattern 以及 linux 下文件系统等相关知识。另外，为了避免代码与我之前文章代码不一致，此处涉及代码引用自 tmuduo。在进程相关方面， tmuduo 只做了及其微小的修改，与 muduo 源码差距很小。在设计上以 muduo 的思路为主，但代码还是来自于 tmuduo，望知悉。
本着“纸上学来终觉浅，绝知此事要躬行”的想法，我将 muduo 网络库重新实现了一遍，并在上面验证了自己的不少猜想。项目的仓库地址为 git@github.com:Phoenix500526/Tmuduo.git, 欢迎各位fork + star，一起加入学习

幕后功臣 ： FileUtil 的实现

linux 的设计哲学之一便是“一切皆文件”，连进程信息也不例外。在 linux 系统下，想要获取进程信息不是一件难事，只需要读取 procfs 下相应的文件即可。在 tmuduo 中，用来读取文件信息的类有两个，一个是用来获取文件信息的 ReadSmallFile，另一个则是用来向文件中追加信息的 AppendFile，它们均被定义在 tmuduo/base/FileUtil.{h,cc} 文件中，而本文要关注的是 ReadSmallFile

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

// read small file < 64KB
class ReadSmallFile : noncopyable {
 public:
  ReadSmallFile(StringArg filename): fd_(::open(filename.c_str(), O_RDONLY | O_CLOEXEC)), err_(0) {
    buf_[0] = '\0';
    if (fd_ < 0) {
      err_ = errno;
    }
  }
  ~ReadSmallFile() {
    if (fd_ >= 0) {
      ::close(fd_);
    }
  }
  // return errno
  template <typename String>
  int readToString(int maxSize, String* content, int64_t* fileSize,
                   int64_t* modifyTime, int64_t* createTime);

  // Read at maxium kBufferSize into buf_
  // return errno
  int readToBuffer(int* size);

  const char* buffer() const { return buf_; }
  static const int kBufferSize = 64 * 1024;

 private:
  int fd_;
  int err_;
  char buf_[kBufferSize];
};

// read the file content, returns errno if error happens.
template <typename String>
int readFile(StringArg filename, int maxSize, String* content,
             int64_t* fileSize = nullptr, int64_t* modifyTime = nullptr,
             int64_t* createTime = nullptr) {
  ReadSmallFile file(filename);
  return file.readToString(maxSize, content, fileSize, modifyTime, createTime);
}

muduo 中在 ProcessInfo.h 中提供了一系列的 API，提供给用户调用以获得进程信息，我们来看一个例子：

1
2
3
4
5

std::string ProcessInfo::procStatus() {
  std::string result;
  FileUtil::readFile("/proc/self/status", 65536, &result);
  return result;
}

从上例可以看到，由于 linux 系统本身的支持，使得获取进程信息这件事情变得非常简单。然而，procfs 虽然便利，但是也有两个不足：

• 只能暴露 system-wide 的数据，不能查看每个进程内部的数据
• procfs 是本地文件系统，必须登录到这台机器上才能查看，如果要管理多台机器，那么工作量就会大大增加。
  对于第一个问题，我们可以通过让程序主动暴露出内部状态，而针对第二个问题，muduo 中提供了两种不同的做法，以下分别讨论。

基于 REST 风格的进程监控

针对 procfs 的第二个问题，muduo 中所提供的第一种是一种基于 REST 风格的进程监控。所谓 REST 风格，简而言之便是以 “URL 定位资源，用 HTTP 动词描述操作”。在分布式系统当中，使用 HTTP 获取进程信息有以下好处：

• 使用 HTTP 协议，无需使用特定的客户端程序，只需要使用普通的 Web 浏览器就可以实现远程访问，紧急情况下，也可以使用 curl/wget 甚至是 telnet 来访问。
• 实现方便，而且也很容易编写一些脚本来进行自动化的状态收集与分析
• 可以通过 URL 区分资源，很容易实现有选择地查看信息，而不是把进程信息一股脑全 dump 出来
• HTTP 天生支持聚合，一个浏览器页面内可以内置多个 iframe，能一眼看清多个进程的状态。
• 除了 GET 方法外，如果有必要，还可以实现 PUT/POST/DELETE 等方法，通过 HTTP 协议来控制并修改进程状态，让程序做到“能观能控”

其中，Inspector 的实现框图大致如下：

muduo 中相关代码位于 net/inspect/ 下

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
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94

class Inspector : noncopyable {
 public:
  using ArgList = std::vector<std::string>;
  using Callback =
      std::function<std::string(HttpRequest::Method, const ArgList& arg)>;
  Inspector(EventLoop* loop, const InetAddress& httpAddr, const std::string& name)
    : server_(loop, httpAddr, "Inspector:" + name),
      processInspector_(new ProcessInspector),
      systemInspector_(new SystemInspector) {
    assert(CurrentThread::isMainThread());
    assert(g_globalInspector == 0);
    /* omitted some code */
    server_.setHttpCallback(std::bind(&Inspector::onRequest, this, _1, _2));
    processInspector_->registerCommands(this);
    systemInspector_->registerCommands(this);
#ifdef HAVE_TCMALLOC
    performanceInspector_.reset(new PerformanceInspector);
    performanceInspector_->registerCommands(this);
#endif
    loop->runAfter(0, std::bind(&Inspector::start, this));
  }
  // Add a Callback for handling the special uri : /module/command
  void add(const std::string& module, const std::string& command,
           const Callback& cb, const std::string& help){
    UniqueLock lock(mutex_);
    modules_[module][command] = cb;
    helps_[module][command] = help;
  }

 private:
  using CommandList = std::map<std::string, Callback>;
  using HelpList = std::map<std::string, std::string>;

  void onRequest(const HttpRequest& req, HttpResponse* resp) {
    if (req.path() == "/") {
      std::string result;
      UniqueLock lock(mutex_);
      for (std::map<std::string, HelpList>::const_iterator helpListI = helps_.begin();
          helpListI != helps_.end(); ++helpListI) {
        const HelpList& list = helpListI->second;
        for (const auto& it : list) {
          result += "/";
          result += helpListI->first;
          result += "/";
          result += it.first;
          size_t len = helpListI->first.size() + it.first.size();
          result += std::string(len >= 25 ? 1 : 25 - len, ' ');
          result += it.second;
          result += "\n";
        }
      }
      resp->setStatusCode(HttpResponse::HttpStatusCode::k200Ok);
      resp->setStatusMessage("OK");
      resp->setContentType("text/plain");
      resp->setBody(result);
    } else {
      std::vector<std::string> result = split(req.path());
      bool ok = false;
      /* omitted some code */
      std::string module = result[0];
      UniqueLock lock(mutex_);
      std::map<std::string, CommandList>::const_iterator commListI =
          modules_.begin();
      if (commListI != modules_.end()) {
        std::string command = result[1];
        const CommandList& commList = commListI->second;
        CommandList::const_iterator it = commList.find(command);
        if (it != commList.end()) {
          ArgList args(result.begin() + 2, result.end());
          if (it->second) {
            resp->setStatusCode(HttpResponse::HttpStatusCode::k200Ok);
            resp->setStatusMessage("OK");
            resp->setContentType("text/plain");
            const Callback& cb = it->second;
            resp->setBody(cb(req.method(), args));
            ok = true;
          }
      }
    }
      if (!ok) {
        resp->setStatusCode(HttpResponse::HttpStatusCode::k404NotFound);
        resp->setStatusMessage("Not Found");
      }
    }
  }

  HttpServer server_;
  std::unique_ptr<ProcessInspector> processInspector_;
  std::unique_ptr<PerformanceInspector> performanceInspector_;
  std::unique_ptr<SystemInspector> systemInspector_;
  Mutex mutex_;
  std::map<std::string, CommandList> modules_ GUARDED_BY(mutex_);
  std::map<std::string, HelpList> helps_ GUARDED_BY(mutex_);
};

其中，结合大致的框图和相应的代码，可以看出 Inspector 的大致工作流程如下：

1. 将 onRequest 注册为 server_ 的 HttpCallback 函数
2. 在 Inspector 构造初期调用 processInspector_ 等对象的 registerCommands 函数，将其中的命令都注册到 Inspector 的 modules_ 和 helps_ 当中。
3. 启动事件循环，等待客户端发送相应的 http 请求，然后根据 url 指向相应 module 的命令，并将执行结果打包成为 http 响应报文，发送给用户。

其中 ProcessInspector, SystemInspector 以及 PerformanceInspector 的实现是大体一致的，我们以 ProcessInspector 为例，看看其对应的实现如何：

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

class ProcessInspector : noncopyable {
 public:
  void registerCommands(Inspector* ins) {
    ins->add("proc", "overview", ProcessInspector::overview,
           "print basic overview");
    ins->add("proc", "pid", ProcessInspector::pid, "print pid");
    ins->add("proc", "status", ProcessInspector::procStatus,
           "print /proc/self/status");
    ins->add("proc", "opened_files", ProcessInspector::openedFiles,
           "count /proc/self/fd");
    ins->add("proc", "threads", ProcessInspector::threads,
           "list /proc/self/task");
  }

  static std::string ProcessInspector::pid(HttpRequest::Method,
                                  const Inspector::ArgList&) {
    char buf[32];
    snprintf(buf, sizeof buf, "%d", ProcessInfo::pid());
    return buf;
  }
  /* omitted */
};

其中 registerCommands 会调用 Inspector 的 add 函数将对应的命令名称、描述信息以及对应对调函数注册到 Inspector 中。

基于 Observer Pattern 实现的进程监控

muduo 还提供了另外一种基于 Observer Pattern 的实现。这种方式有点像 redis 的集群机制，让不同的节点将自身的相关信息发布到对应的 topic 上，有需要的节点只需要订阅相关的 topic 就可以获得相应节点的进程信息。

在基于 Observer Pattern 模式实现的进程监控方式中，主要涉及了四个不同的概念，分别是话题Topic, 集线器Hub，发布者Pub以及订阅者Sub,它们之间的关系如下：

muduo 当中的 Hub 示例采用了 “\r\n” 分界的文本协议，这样做可以简单地使用 telnet 测试 Hub，使用时采用命令的方式，如：

• 订阅 topic: sub <topic>\r\n
• 退订 topic: unsub <topic>\r\n
• 发布 content: pub <topic>\r\n<content>\r\n

由于代码篇幅过长且 sub 和 pub 都可以用 telnet 来代替，因此这里只放了 hub 以及 Topic 的相关实现。，有需要的可以自行将代码下下来研究。先来看看 Topic 的实现：

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

class Topic : public tmuduo::copyable {
 public:
  Topic(const string& topic) : topic_(topic) {}

  void add(const TcpConnectionPtr& conn) {
    audiences_.insert(conn);
    if (lastPubTime_.valid()) {
      conn->send(makeMessage());
    }
  }
  /* omitted */
  void publish(const string& content, Timestamp time) {
    content_ = content;
    lastPubTime_ = time;
    string message = makeMessage();
    for (auto it = audiences_.begin(); it != audiences_.end(); ++it) {
      (*it)->send(message);
    }
  }

 private:
  string makeMessage() { return "pub " + topic_ + "\r\n" + content_ + "\r\n"; }
  string topic_;
  string content_;
  Timestamp lastPubTime_;
  std::set<TcpConnectionPtr> audiences_;
};

对于 Topic 而言，关键的接口为 add 和 publish，其中 add 会将订阅了该 topic 的连接保存到 audiences_ 当中，而 publish 则负责向 audiences_ 中的连接发送发布消息。从框图中也可以看到在 hub 当中保存了一个 topics_ 的 map, 用于保存所有的 topic,其实现相关部分如下：

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

class PubSubServer : tmuduo::noncopyable {
 public:
  PubSubServer(EventLoop* loop, const InetAddress& serverAddr)
      : loop_(loop), server_(loop, serverAddr, "PubSubServer") {
    server_.setConnectionCallback(
        std::bind(&PubSubServer::onConnection, this, _1));
    server_.setMessageCallback(
        std::bind(&PubSubServer::onMessage, this, _1, _2, _3));
    loop_->runEvery(1.0, std::bind(&PubSubServer::timePublish, this));
  }

 private:
  /* omitted */
  void onMessage(const TcpConnectionPtr& conn, Buffer* buf,
                 Timestamp receiveTime) {
    ParseResult result = ParseResult::kSuccess;
    while (result == ParseResult::kSuccess) {
      string cmd;
      string topic;
      string content;
      result = parseMessage(buf, &cmd, &topic, &content);
      if (result == ParseResult::kSuccess) {
        if (cmd == "pub") {
          doPublish(conn->name(), topic, content, receiveTime);
        } else if (cmd == "sub") {
          LOG_INFO << conn->name() << " subscribes " << topic;
          doSubscribe(conn, topic);
        } else if (cmd == "unsub") {
          doUnsubscribe(conn, topic);
        } else {
          conn->shutdown();
          result = ParseResult::kError;
        }
      } else if (result == ParseResult::kError) {
        conn->shutdown();
      }
    }
  }

  void timePublish() {
    Timestamp now = Timestamp::now();
    doPublish("internal", "utc_time", now.toFormattedString(), now);
  }
private:
  EventLoop* loop_;
  TcpServer server_;
  std::map<string, Topic> topics_;
};

在 hub 的实现上，比较关键的两个函数是 onMessage 和 timePublish，当其他节点向 hub 发送消息时，会触发 onMessage 函数的执行，该函数会根据消息的内容执行相应的函数，而 timePublish 则由定时事件进行触发。这里 timePublish 保留了原有的实现，如果需要发布进程信息可以直接在此进行修改。

最后一点想法

到了这里，基于 Observer Pattern 模式实现的进程监控也大体说完。这两种方式实现不难，只需要了解其中大体流程及 muduo 的相关用法，也可以很快地写出来。在基于 Observer Pattern 的进程监控方式中，一个比较大的问题是 hub 很容易成为 single point of failure. 关于这点，也许在 Redis 的源码中会有解决的方案。而这也是我写这篇文章的目的之一：如果未来有时间，我希望在解决这个问题后，可以直接从这篇文章中接续下去，而不必重新开始。
这篇文章其实并不好写，原因是由于 linux 的 procfs 的实现使得获取进程信息非常简单，如果单独写篇文章比较划不来。可如果将这两种模式总结进来，又很容易使得文章变得非常冗长。

本文是 muduo 网络库源码剖析系列文章的第八篇文章，是对前一篇文章的一个补充。另外需要注意，本文假定读者已经了解了 SFINAE 的基本含义，因此没有花费笔墨具体讨论什么是 SFINAE，如果读者不知道什么是 SFINAE ，建议先阅读知乎大佬：空明流转的文章 《C++模板进阶指南：SFINAE》，以便对 SFINAE 有基本的了解。
本文主要包含以下内容

• SFINAE —— muduo Singleton 中 has_no_destroy 的启示
• has_no_destroy 的进阶玩法 —— 如何判断一个类的基类子类型中是否声明了某个函数
  • has_no_destroy 为何无法判断子类中基类方法
  • 从一个简单的例子讲起 —— 从编译错误中得到的启示
  • has_no_destroy 的进阶实现与测试

本文中所涉及的代码来源于我的个人项目：tmuduo。本着“纸上学来终觉浅，绝知此事要躬行”的想法，我将 muduo 网络库重新实现了一遍，并在上面验证了自己的不少猜想。项目的仓库地址为 git@github.com:Phoenix500526/Tmuduo.git, 欢迎各位fork + star，一起加入学习

SFINAE —— muduo Singleton 中 has_no_destroy 的启示

再讲完了 tmuduo 中单例模式的实现后，我们来看看 muduo 中 Singleton 使用到的另一个技术 —— SFINAE(Substitution failure is not an error)。我们先来看看 Singleton 中 has_no_destroy 的实现：

1
2
3
4
5
6

template<typename T>
struct has_no_destroy{
  template <typename C> static char test(decltype(&C::no_destroy));
  template <typename C> static int32_t test(...);
  const static bool value = sizeof(test<T>(0)) == 1;
};

如前言所述，has_no_destroy 的作用是用来判断一个类中是否声明了 no_destroy 函数。我们先来看看它的具体用法：

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

#include <iostream>
using namespace std;

class A{
public:
    void no_destroy();
};

class B{
public:
    int no_destroy(int);
};

class C : A{};

class D{};

int main(){
    cout << "Whether A has no_destroy or not? " << (has_no_destroy<A>::value ? "yes" : "no") << endl;  
    cout << "Whether B has no_destroy or not? " << (has_no_destroy<B>::value ? "yes" : "no") << endl;   
    cout << "Whether C has no_destroy or not? " << (has_no_destroy<C>::value ? "yes" : "no") << endl;  
    cout << "Whether D has no_destroy or not? " << (has_no_destroy<D>::value ? "yes" : "no") << endl;  
}

执行结果：

Whether A has no_destroy or not? yes
Whether B has no_destroy or not? yes
Whether C has no_destroy or not? no
Whether D has no_destroy or not? no

在讲述 has_no_destroy 的原理前，我们先看下面的代码：

1
2
3
4
5
6
7
8
9
10

#include <iostream>
using namespace std;

int32_t foo1(int);
char foo2(void*);

int main(){
    cout << "sizeof foo1(0) is " << sizeof(foo1(0)) << endl;   
    cout << "sizeof foo2(0) is " << sizeof(foo2(0)) << endl;   
}

执行结果:

sizeof foo1(0) is 4
sizeof foo2(0) is 1

在上述代码中，我们声明了两个函数: foo1 和 foo2。注意这两个函数都是只声明未定义。当我们执行 sizeof(foo1(0)) 时，实际上是在检测 foo1 返回值类型的大小。这里简单提一下，编译器会在编译时使用 sizeof(int32_t) 代替 sizeof(foo1(0)) 进行求值。虽然 sizeof(foo1(0)) 看似产生了函数调用，实则不然。由于编译器没有编译出函数调用的命令，所以链接器并不会去查找 foo1 的定义，也就不会产生任何错误。

让我们重新看看 has_no_destroy 的实现：

1
2
3
4
5
6

template<typename T>
struct has_no_destroy{
  template <typename C> static char test(decltype(&C::no_destroy));
  template <typename C> static int32_t test(...);
  const static bool value = sizeof(test<T>(nullptr)) == 1;
};

在上述代码中，两个 test 函数都只是只声明未定义。当我们查看 has_no_destroy<A>::value 的值时，会先执行 has_no_destroy<A> 的实例化。由于 A 中声明了 no_destroy 函数，根据模板实例化的原则，函数 static char test(decltype(&C::no_destroy))是最佳匹配，因此会实例化该函数，此时 test<T>(nullptr) 的返回值便是 char 类型，大小为 1 ，故 value 的值为 true。当执行 has_no_destroy<D>::value，同样会执行 has_no_destroy<D> 的实例化。由于 D 中没有声明 no_destroy 函数，因此只能实例化 static int32_t test(...) 函数，其返回值为 int32_t, 故 value 的值为 false(…代表接受任意数量任意类型的参数)。这样我们就实现了一种能够判断类中是否具有成员函数 no_destroy 的方法。

has_no_destroy 的进阶玩法 —— 如何判断一个类的基类子类型中是否声明了某个函数

has_no_destroy 为何无法判断子类中基类方法

从前面的实例当中我们可以看出，has_no_destroy 不能用于判断具有子类中是否具有基类的 no_destroy 方法，例如前面例子中的 C 类型。有没有什么办法能够增强 has_no_destroy 的功能，使其既能保持当前的用法不变，同时又能自动判断子类中的基类子类型是否包含 no_destroy 函数。

我们先看看为什么 has_no_destroy 无法干这个活。has_no_destroy 的基本工作原理，是利用了模板的匹配原则，如果 C 中恰好声明了函数 no_destroy,那么函数 static char test(decltype(&C::no_destroy)) 将会得到实例化。但是当子类型中包含了基类函数时，以上述的 C 为例子，C 中虽然包含了从基类 A 中继承来的成员函数 no_destroy，但其函数签名应当是 A::no_destroy 而非　no_destroy。当我们对 C 实例化对象调用 no_destroy 函数时，编译器在 C 自身类型中找不到对应 no_destroy 函数，便会去基类子类型中查找 no_destroy 函数。为了便于理解，你可以将这个过程看成是一次隐式类型转换：编译器将 no_destroy 转换成了 A::no_destroy。不过由于模板自身有类型推导规则，因此编译器不会为 has_no_destroy 执行这个转换工作。我们需要自己来。
显然现在摆在我们面前的只有两条路，要么多增加一个模板类型参数，让用户把基类类型传进来，然后在 has_no_destroy 中做手动转换；要么反过来，让所有没有定义 no_destroy 的函数匹配成功，然后对 value 取反就可以。第一条路非常不好走，一方面是因为我之前说明了，我希望做一个 has_no_destroy 的增强版，因此我不希望增加多余的类型参数，另一方面，这种做法对于没有继承体系的类非常不友好，甚至来说是错误的存在。因此我选择了第二种做法，不仅能保持 has_no_destroy 的基本用法不变，而且对带继承或不带继承的类型等同视之，能够简化判断的策略。

从一个简单例子讲起 —— 从编译错误中得到的启示

既然明确了要采用反证的思想来解决这个问题，我们希望所有定义了 no_destroy 函数的类型均无法正确匹配。在这之前先用一个例子来说明一下我的思路：

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

#include <iostream>
using namespace std;
class A{
public:
    void no_destroy(){
        cout << "A::no_destroy()" << endl;
    }
};

class B{
public:
    void no_destroy(){
        cout << "B::no_destroy()" << endl;
    }
};

class C: public A{};

class D: public A, public B{};

class F: public C, public B{};

int main(){
    C c;
    c.no_destroy();
    D d;
    //d.no_destroy(): // error: member 'no_destroy' found in multiple base classes of different types
    F f;
    //f.no_destroy(): // error: member 'no_destroy' found in multiple base classes of different types
    return 0;
}

在上述代码中，D 由于同时继承 A 和 B，因此当我们执行 d.no_destroy()函数时，会产生二义性错误(f 亦同理)。反观 C，由于 C 只继承了 A，因此当执行 c.no_destroy()， 编译器在 C 的类型中找不到 no_destroy 的定义时，会自动到 C 的基类子类型中寻找。我们可以模仿这种做法，先在 has_no_destroy 中定义一个声明了 no_destroy 函数 Base 作为基类，然后让类型 T 也作为基类，并让 Derive 作为二者的联合派生类。接着在对 Derive 中的 no_destroy 进行模板类型推导。如果 T 中或 T 的基类子类型中包含了 no_destroy 类型，那么都会产生二义性错误从而导致相应的函数模板实例化失效。

进阶 has_no_destroy 的实现与测试

讲完了上述想法后，我们可以开始着手 has_no_destroy 进阶版的实现：

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

//SFINAE.h
template <typename T> 
class has_no_destroy
{ 
   using yes = char;
   using no = int32_t;
   struct Base 
   { 
     void no_destroy();
   }; 
   struct Derive : public T, public Base {}; 
   template <typename C, C>  class Helper{}; 
   template <typename U> 
   static no test(U*, Helper<decltype(&Base::no_destroy), &U::no_destroy>* = nullptr); 
   static yes test(...); 
public: 
   static const bool value = sizeof(yes) == sizeof(test(static_cast<Derive*>(nullptr))); 
}; 

在上述代码中，由于采用了反证的思想，逻辑比较绕，我采用了更有意义的类型别名 yes 和 no 来描述结果。其中 Helper 是用来辅助模板类型推断的辅助类模板。 不管是 U 还是 U 的基类子类型中，只要声明了 no_destroy，都会因产生二义性错误而导致 Helper 实例化失败，进而导致 static no test 实例化失败。 此时 value 中对 test 的调用将会匹配到 static yes test。如果 U 或者 U 的基类子类型中没有声明 no_destroy 函数，则 static no test 将会实例化成功，根据最佳匹配原则，value 中对 test 的调用将会匹配到 static no test,这样我们便实现了区分
以下是我对进阶版 has_no_destroy 的测试。
测试代码：

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

#include <iostream>
#include "SFINAE.h"
using namespace std;
class A {
    void no_destroy();
};

class B : A {};

class C {};

int main()
{
    cout << "Whether A has no_destroy or not? " << (has_no_destroy<A>::value ? "yes" : "no") << endl;  
    cout << "Whether B has no_destroy or not? " << (has_no_destroy<B>::value ? "yes" : "no") << endl;   
    cout << "Whether C has no_destroy or not? " << (has_no_destroy<C>::value ? "yes" : "no") << endl;  
}

测试结果：

Whether A has no_destroy or not? yes
Whether B has no_destroy or not? yes
Whether C has no_destroy or not? no

关于进阶版的 has_no_destroy 的实现代码我放在了 tmuduo/base/Singleton.h 当中，不过由于这个功能仅是兴趣，没有涉及到 tmuduo 本身的使用，我没有将测试代码添加到 tmuduo/test 当中，测试本身不复杂，有需要的可以自己实现。

本文是 muduo 网络库源码剖析系列文章的第七篇文章，主要涉及了对 muduo 网络库中单例模式的分析，以及 C++11 标准下一种更加简洁的单例模式实现，其中包含了以下内容：

• 对 muduo 网络库下单例模式的思考
  • 线程全局单例模式 Singleton 的实现
  • 线程局部单例模式 ThreadLocalSingleton 的实现
• tmuduo 中单例模式的实现

本文中所涉及的代码来源于我的个人项目：tmuduo。本着“纸上学来终觉浅，绝知此事要躬行”的想法，我将 muduo 网络库重新实现了一遍，并在上面验证了自己的不少猜想。项目的仓库地址为 git@github.com:Phoenix500526/Tmuduo.git, 欢迎各位fork + star，一起加入学习

对 muduo 网络库下单例模式的思考

Singleton 的实现

在 muduo 网络库的源代码中，单例模式分为两种，一种是线程全局单例模式，另一种是线程局部单例模式，相关的代码分别存放在 base/Singleton.h 和 base/ThreadLocalSingleton.h 文件中。我们先看下 Singleton 的实现

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

//Singleton.h
template<typename T>
class Singleton : noncopyable{
 public:
  Singleton() = delete;
  ~Singleton() = delete;
  static T& instance()
  {
    pthread_once(&ponce_, &Singleton::init);
    assert(value_ != NULL);
    return *value_;
  }

private:
  static void init()
  {
    value_ = new T();
    if (!detail::has_no_destroy<T>::value)
    {
      ::atexit(destroy);
    }
  }
  static void destroy()
  {
    // T_must_be_complete_type 的作用是检测 T 是不是不完全类型
    // 若 T 是不完全类型(仅有声明没有定义)，则 sizeof(T) = 0
    // 则此时 T_must_be_complete_type 相当于 char[-1]
    // 利用此类型定义了一个 dummy 对象会引发变异错误。
    typedef char T_must_be_complete_type[sizeof(T) == 0 ? -1 : 1];
    T_must_be_complete_type dummy; (void) dummy;

    delete value_;
    value_ = NULL;
  }
private:
  static pthread_once_t ponce_;
  static T*             value_;
};
template<typename T>
pthread_once_t Singleton<T>::ponce_ = PTHREAD_ONCE_INIT;
template<typename T>
T* Singleton<T>::value_ = NULL;

从上述代码可以看出，Singleton 是一个模板类，且用户只能调用该类的静态成员函数instance。当用户调用 Singleton<T>::instance() 时，muduo 调用 Singleton<T>::init 进行 T 的初始化，而 pthread_once 保证了这一过程仅会在首次调用 instance 方法时发生。对于其中 has_no_destroy 的具体实现，我们先按下不表，留到下一篇文章再回来讨论。现在只需要知道， has_no_destroy<T>::value 是用来判断类型 T 当中是否声明了函数 no_destroy 即可。因此，如果 T 中没有声明 no_destroy 函数，那么 init 会调用 atexit 将 destroy 注册到进程当中，这样当进程退出时就会自动执行后 destroy 进行对象的析构工作。心细的同学应该很容易发现，如果单例对象中声明了 no_destroy 函数，那毫无疑问地会导致内存的泄露。

ThreadLocalSingleton 的实现

在大体知道了 Singleton 的实现后，我们再来看看 ThreadLocalSingleton 的实现：

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

template<typename T>
class ThreadLocalSingleton : noncopyable{
public:
  ThreadLocalSingleton() = delete;
  ~ThreadLocalSingleton() = delete;
  static T& instance(){
    if (!t_value_)
    {
      t_value_ = new T();
      deleter_.set(t_value_);
    }
    return *t_value_;
  }

  static T* pointer(){
    return t_value_;
  }

private:
  static void destructor(void* obj){
    assert(obj == t_value_);
    typedef char T_must_be_complete_type[sizeof(T) == 0 ? -1 : 1];
    T_must_be_complete_type dummy; (void) dummy;
    delete t_value_;
    t_value_ = 0;
  }

  class Deleter{
   public:
    Deleter(){
      pthread_key_create(&pkey_, &ThreadLocalSingleton::destructor);
    }

    ~Deleter(){
      pthread_key_delete(pkey_);
    }

    void set(T* newObj){
      assert(pthread_getspecific(pkey_) == NULL);
      pthread_setspecific(pkey_, newObj);
    }

    pthread_key_t pkey_;
  };
  static __thread T* t_value_;
  static Deleter deleter_;
};
template<typename T>
__thread T* ThreadLocalSingleton<T>::t_value_ = 0;
template<typename T>
typename ThreadLocalSingleton<T>::Deleter ThreadLocalSingleton<T>::deleter_;

在上述代码中，我们可以看到，ThreadLocalSingleton 也是一个模板类，用户只能调用类中的静态方法 instance 以及 pointer。由于和 Singleton 的应用场景不同， ThreadLocalSingleton 只需要通过判断 t_value_ 是否为空，就可以实现仅在首次调用 instance 方法进行初始化。基本的流程和前面 Singleton 是差不多的，其中最大的不同在于 ThreadLocalSingleton 多了一个 Deleter class，这是因为 t_value_ 由 GCC 关键字 __thread 所修饰，因此不能自动调用析构函数，需要额外定义一个 Deleter 来完成这份工作。deleter_ 实际上相当于一个 RAII 对象，在调用 instance 时将 t_value_ 交由 deleter_ 保管，当线程退出时析构 deleter_ 时，会执行 ThreadLocalSingleton::destructor 来析构 t_value_

tmuduo 中单例模式的实现

在讨论 tmuduo 如何实现单例模式之前，我们需要先思考一个问题，一个单例对象需要符合哪些特质才能算得上是一个合格的单例？我想至少有以下几点：

• 该对象必定是不可拷贝的
• 用户只能够通过 instance 方法获得唯一的实例，且在若干次调用 instance() 方法中，仅会在首次调用时进行初始化
• 必须是资源安全的，在程序退出时必须能够正确地析构，不会造成任何的资源泄露
• 若是线程全局单例模式，则还需要考虑线程安全的问题。若是线程局部单例模式，则需要考虑线程局部存储的问题

第一个问题非常好解决，我们只需要继承 noncopyable 标签类即可。真正需要注意的其实是第二和第三个问题。
如果看过我之前的文章 《对 muduo 网络库中的线程模型的思考与实践》，应该还记得其中提到了三个变量存储期概念，分别是 static stroage duration，thread storage duration 以及 dynamic storage duration。任何被声明为 static 或 thread_local 的局部变量具有 static storage duration 或 thread storage duration(这里的或指的是互斥或而非逻辑或，以下或如未特殊声明，均代表互斥或)，且他们都不被分配在堆内存上。
另外，在 C++11 的标准中，关于被声明为 static 或 thread_local 的局部变量，有如下的规定：

Variables declared at block scope with the specifier static or thread_local (since C++11) have static or thread (since C++11) storage duration but are initialized the first time control passes through their declaration (unless their initialization is zero- or constant-initialization, which can be performed before the block is first entered). On all further calls, the declaration is skipped.

If the initialization throws an exception, the variable is not considered to be initialized, and initialization will be attempted again the next time control passes through the declaration.

If the initialization recursively enters the block in which the variable is being initialized, the behavior is undefined.

If multiple threads attempt to initialize the same static local variable concurrently, the initialization occurs exactly once (similar behavior can be obtained for arbitrary functions with std::call_once).

上述 C++11 标准保证了 static 或 thread_local 修饰局部变量只会在程序的控制流首次进入相应的块作用域才进行实例化工作，而且在实例化成功后，在程序或线程退出时能够自动调用相应的析构函数。另外，由于 static 或 thread_local 修饰的局部变量并不存储在堆内存当中，因此自然也不会造成任何的内存泄露。最后，对于线程全局单例模式，标准保证了 static local variable 的初始化是线程安全的，而 thread_local 本身就代表了线程局部存储。有了 C++11 标准的保驾护航，第二、第三和第四个问题将不再是问题，我们可以以一种非常简洁的方式来实现 tmuduo 中的单例模式

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

// Singleton.h 的实现
template <typename T>
class Singleton : noncopyable {
 public:
  Singleton() = delete;
  ~Singleton() = delete;
  static T& instance() {
    static T instance;
    return instance;
  }
};

// ThreadLocalSingleton.h 的实现
template <typename T>
class ThreadLocalSingleton : noncopyable {
 public:
  ThreadLocalSingleton() = delete;
  ~ThreadLocalSingleton() = delete;
  static T& instance() {
    thread_local T instance;
    return instance;
  }
};

为了验证 Singleton 以及 ThreadLocalSingleton 的正确性，我在自身代码的基础上运行 muduo 中的测试。与 muduo 本身的测试结果相当，具体测试代码可见:tmuduo/test/Singleton_test.cc 以及 tmuduo/test/ThreadLocalSingleton_test.cc

本文是 muduo 源码剖析系列的第六篇文章，主要探讨了 tmuduo 网络库的线程池模型，其中包含了以下内容：

• 为什么要重新设计 ThreadPool
• SyncQueue 的实现
• ThreadPool 的实现

本文中所涉及的代码来源于我的个人项目：tmuduo。本着“纸上学来终觉浅，绝知此事要躬行”的想法，我将 muduo 网络库重新实现了一遍，并在上面验证了自己的不少猜想。项目的仓库地址为 git@github.com:Phoenix500526/Tmuduo.git, 欢迎各位fork + star，一起加入学习

tmuduo 线程池的设计

如果你看过我之前的文章，那么很容易发现这篇文章和之前的文章不太一样。之前的文章大部分都是谈论 muduo 相应部分的设计，然后提出我自己的想法并实践，最终将实践结果,也就是 tmuduo 的代码，展示出来。而这篇文章跳过 muduo 网络库设计的部分，直接谈论了 tmuduo 网络库中的 ThreadPool 设计，主要原因有二：

• muduo 网络库中的线程池依赖于 Thread 的实现，而 tmuduo 中的 Thread 采用和 muduo 不一样的实现方式，在这样子的前提下去修改 ThreadPool 的代码，改出来的东西完全是四不像。
• muduo 网络库中的 ThreadPool 有点不太符合我的编程美学。muduo 网络库中 ThreadPool 采用 deque 作为任务队列，把任务队列的所有同步工作一起放到了 ThreadPool 中去完成。这种做法让我感到不太舒服，于是我在 tmuduo 网络库中实现了一个 SyncQueue，将同步工作移交给 SyncQueue，而 ThreadPool 只需要使用即可。

基于以上两个理由，我决定脱离 muduo 的 ThreadPool 限制，实现一个自己版本的 ThreadPool，但为了能融入 tmuduo 的整体框架之中，我还是保留了 muduo 的 ThreadPool 测试代码，并让 tmuduo 的 ThreadPool 通过了该测试。我自己对 tmuduo 的线程池部分有一个未实现的想法：那就是看看是否能引入类似于 skynet 网络框架的设计，为线程池中的不同线程分配不同的优先级，并让他们根据优先级来取出不同数量的任务(有点类似于操作系统的优先级队列轮转调度算法)，这样可以更好地利用到 CPU 的资源。不过由于时间和精力的原因，这个想法还没有明确的时间计划，以后有机会再补充吧。

线程池在实现上大概可分为两种，一种是半同步半异步线程池，而另一种则是领导者追随者线程池。tmuduo 的 ThreadPool 属于前者，本质上也就是个生产者消费者模型。大体可分两层：同步服务层和异步服务层。上层会调用线程池的相应接口，将任务添加到同步服务层中，而线程池中的线程则属于异步服务层，它们会在空闲的时候异步地从同步队列中取出任务来执行。

同步队列 SyncQueue 的实现

同步队列的代码主要放在 base/SyncQueue.h 当中

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

template <typename T>
class SyncQueue : noncopyable {
 public:
  SyncQueue(int maxsize)
      : mutex_(), full_(), empty_(), maxSize_(maxsize), running_(true) {}
  ~SyncQueue() = default;
  void put(const T& x) { add(x); }
  void put(T&& x) { add(std::forward<T>(x)); }
  void take(T& t) {
    UniqueLock lock(mutex_);
    while (queue_.empty() && running_) {
      empty_.wait(lock);
    }
    if (!running_) return;
    t = queue_.front();
    queue_.pop_front();
    full_.notify_one();
  }
  size_t size() const {
    UniqueLock lock(mutex_);
    return queue_.size();
  }

  void stop() NO_THREAD_SAFETY_ANALYSIS {
    {
      UniqueLock lock(mutex_);
      running_ = false;
    }
    full_.notify_all();
    empty_.notify_all();
  }

 private:
  template <typename F>
  void add(F&& x) {
    UniqueLock lock(mutex_);
    while (queue_.size() >= maxSize_ && running_) {
      full_.wait(lock);
    }
    if (!running_) return;
    queue_.push_back(std::forward<F>(x));
    empty_.notify_one();
  }

 private:
  std::list<T> queue_;
  mutable Mutex mutex_;
  Condition full_ GUARDED_BY(mutex_);   //同步队列已满
  Condition empty_ GUARDED_BY(mutex_);  //同步队列已空
  int maxSize_;
  bool running_;
};

SyncQueue 整体的实现也不复杂，如果看了之前的文章：《clang 的线程安全注解TSA》以及 《对 muduo 网络库中互斥量与条件变量的思考与实践》，理解上应该不会有什么太大的问题。
这里有个地方稍微提一下：出于效率的考虑，running_ 不需要是 atomic 类型。这主要是因在同步队列当中，只有在初始化队列和停止队列时才会修改到 running_ 而使用频繁的 take 和 put 函数会不断访问 running_ 的值，因此我将 running_ 设置为普通的 bool 类型，而在 stop 函数中采用上锁访问的方式来避免 data race.

ThreadPool 的实现

ThreadPool 的具体代码放在 tmuduo/base/ThreadPool.{h, cc} 当中，有需要的可以自行下下来研究。这里出于篇幅问题，只展示了一些关键代码。

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
73
74
75
76
77
78
79
80
81
82

//ThreadPool.h:
class ThreadPool : noncopyable {
 public:
  using Task = std::function<void()>;
  ThreadPool(int maxSize, const std::string& name = std::string("ThreadPool"));
  ~ThreadPool();
  void setThreadInitCallback(const Task& cb) { threadInitCallback_ = cb; }
  void start(int numThreads);
  void stop();
  void run(Task&& f);
  //一些其他的函数
 private:
  void runInThread();
  std::string name;
  Task threadInitCallback_;
  std::vector<std::unique_ptr<Thread>> threads_;
  SyncQueue<Task> queue_;
  std::atomic<bool> running_;
};

//ThreadPool.cc
ThreadPool::ThreadPool(int maxSize, const std::string& name)
    : name_(name), queue_(maxSize), running_(false) {
  assert(maxSize > 0);
}

ThreadPool::~ThreadPool() {
  if (running_) {
    stop();
  }
}

void ThreadPool::start(int numThreads) {
  assert(threads_.empty() && numThreads >= 0);
  running_ = true;
  for (int i = 0; i < numThreads; ++i) {
    threads_.emplace_back(
        new tmuduo::Thread(std::bind(&ThreadPool::runInThread, this),
                           name_ + std::to_string(i + 1)));
  }
  if (0 == numThreads && threadInitCallback_) {
    threadInitCallback_();
  }
}

void ThreadPool::stop() {
  queue_.stop();
  running_ = false;
  for (auto& thr : threads_) {
    thr->join();
  }
}

void ThreadPool::run(Task&& task) { queue_.put(std::forward<Task>(task)); }

void ThreadPool::runInThread() {
  try {
    if (threadInitCallback_) {
      threadInitCallback_();
    }
    while (running_) {
      Task task;
      queue_.take(task);
      if (task) {
        task();
      }
    }
  } catch (const Exception& ex) {
    fprintf(stderr, "exception caught in ThreadPool %s\n", name_.c_str());
    fprintf(stderr, "reasion: %s\n", ex.what());
    fprintf(stderr, "stack trace: %s\n", ex.stackTrace());
    abort();
  } catch (const std::exception& ex) {
    fprintf(stderr, "exception caught in ThreadPool %s\n", name_.c_str());
    fprintf(stderr, "reasion: %s\n", ex.what());
    abort();
  } catch (...) {
    fprintf(stderr, "unknown exception caught in ThreadPool %s\n",
            name_.c_str());
    throw;
  }
}

上述代码的实现也比较简单，如果看过之前的文章《对-muduo-网络库中的线程模型的思考与实践》 了解 tmuduo 的 Thread 实现，那么只要捋清线程的 start 以及 stop 基本就能够将这个 ThreadPool 实现出来。

回顾到之前提到的 ThreadPool 的双层结构，对应到代码上则是：

上层 ：创建 ThreadPool 的线程
同步层：ThreadPool 中的 SyncQueue
异步层：ThreadPool 的 threads_ 数组

上层通过调用 run 函数将任务添加到同步层中，异步层中的线程的 runInThread 则会在空闲的时候将任务取出并执行。

本文是 muduo 源码剖析系列文章的第五篇文章，主要探讨了如何设计异常类，使其携带尽可能多的有效信息。

• 异常到底要不要用 —— Google 到底怎么看异常
• C++ 的 mangle 与 demangle 过程
• 如何让异常携带友好的线程函数栈调用信息

本文中所涉及的代码来源于我的个人项目：tmuduo。本着“纸上学来终觉浅，绝知此事要躬行”的想法，我将 muduo 网络库重新实现了一遍，并在上面验证了自己的不少猜想。项目的仓库地址为 git@github.com:Phoenix500526/Tmuduo.git, 欢迎各位fork + star，一起加入学习

在前一篇文章《对 muduo 网络库中的线程模型的思考与实践》中，在 Thread 的 runInThread 函数中涉及到了对异常的一些处理，而这篇文章的目的便是探讨自己在muduo网络库中所学到的异常实现的一点经验

异常到底要不要用 —— Google 到底怎么看异常

在我最开始重新用自己的方式实现 tmuduo 的线程模型时，我并没有引入异常处理机制。在此之前，我对 Google 禁用异常的说法略有耳闻，而陈硕大佬作为 Google 的工程师，却在自己的开源项目中用到了异常！？带着好奇心，我去查看了《Google C++ Style Guide》_[1],在 Exception 的那章找到了如下内容：

Exception:
We do not use C++ exceptions.
…
Decision:
On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code. If exceptions can be propagated beyond a new project, it also becomes problematic to integrate the new project into existing exception-free code. Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions.
Given that Google’s existing code is not exception-tolerant, the costs of using exceptions are somewhat greater than the costs in a new project. The conversion process would be slow and error-prone. We don’t believe that the available alternatives to exceptions, such as error codes and assertions, introduce a significant burden.

这下就清楚了，Google 不用异常的原因是 Google 有很多旧代码并不是异常安全的，将这些代码中引入异常处理，其工作量之巨大远超过异常所能够带来的好处。**如果你所做的项目没有历史包袱，那么适当的使用异常是利大于弊的(关于异常的优缺点，可以直接查看Google C++ Style Guide中的 Pros and Cons，这里就不做搬运工了)**。

tmuduo 的异常实现

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

class Exception : public std::exception {
 public:
  Exception(std::string what): message_(std::move(msg)),
      stack_(CurrentThread::stackTrace(/*demangle = */ false)) {}
  ~Exception() noexcept override = default;

  const char* what() const noexcept override { return message_.c_str(); }

  const char* stackTrace() const noexcept { return stack_.c_str(); }

 private:
  std::string message_;
  std::string stack_;
};

注意：本节内容中所用的异常代码和 muduo 网络库中是高度类似的，我仅是对其做了一点点微小的调整以使其适应我自己编写的 Thread 类。为了能和之前的文章保持一致，此处还是用 tmuduo 的代码。
从上述代码来看，整个异常类的代码非常简单，重点还是在于 CurrentThread::stackTrace 函数的实现上。不过在展示 CurrentThread::stackTrace 的代码实现之前，需要先了解两个基本概念 mangle 与 demangle

C++ 的 mangle 与 demangle

先简单地解释一下一些相关的概念：

mangle : 将 C++ 的源程序标识符(original C++ source identifier)转换成C++ ABI 标识符(C++ ABI identifier)的过程
demangle : 将 C++ 的 ABI 标识符转换为源程序标识符的过程
ABI(Application Binary Interface): 从命名上来看，指的是程序二进制层面上的接口，包括如符号修饰标准、变量内存布局、函数调用方式等等这些所有跟可执行代码二进制兼容性相关的内容。
API(Application Programming Interface): 指的往往是源码级别的接口，例如 POSIX 是一个 API 标准，POSIX 线程库下的 pthread_create函数是一个 API。

由于历史原因，不同的编译器之间往往有各自的 C++ ABI 标准，所以同一份 C++ 代码使用不同的编译器，甚至是同一个编译器的不同版本所编译出来的程序都可能存在 ABI 不兼容问题。而 mangle 规则也算是 ABI 的一部分。我们可以先来看看在 Ubuntu-16.04 下的 clang 3.8.0-2 的 mangle 规则：

1
2
3
4
5
6
7
8

//mangle_test.cc
#include <iostream>
using namespace std;
void foo(int var){}
void foo(float var){}
int main(){
    return 0;
}

我们执行 clang++ -c mangle_test.cc && nm mangle_test.o 后可以看到如下结果：

可以看到我们所写的重载函数 foo 经过了 mangle 后转变成了 _Z3foof 和 _Z3fooi。

CurrentThread::stackTrace 的实现

CurrentThread::stackTrace 具体代码保存在 tmuduo/base/CurrentThread.cc 文件中

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

std::string stackTrace(bool demangle) {
  std::string stack;
  const int max_frames = 200;
  void* frame[max_frames];
 
  int nptrs = ::backtrace(frame, max_frames);
  char** strings = ::backtrace_symbols(frame, nptrs);
  if (strings) {
    size_t len = 256;
    char* demangled = demangle ? static_cast<char*>(::malloc(len)) : nullptr;
    for (int i = 1; i < nptrs; ++i) {
      if (demangle) {
        char* left_par = nullptr;
        char* plus = nullptr;
        for (char* p = strings[i]; *p; ++p) {
          if (*p == '(')
            left_par = p;
          else if (*p == '+')
            plus = p;
        }
        if (left_par && plus) {
          *plus = '\0';
          int status = 0;
          char* ret =
              abi::__cxa_demangle(left_par + 1, demangled, &len, &status);
          *plus = '+';
          if (status == 0) {
            demangled = ret;
            stack.append(strings[i], left_par + 1);
            stack.append(demangled);
            stack.append(plus);
            stack.push_back('\n');
            continue;
          }
        }
      }
      stack.append(strings[i]);
      stack.push_back('\n');
    }
    free(demangled);
    free(strings);
  }
  return stack;
}

其中涉及到了三个新的函数：backtrace， backtrace_symbols 以及 abi::__cxa_demangle。其中 backtrace 和 backtrace_symbols 用于获得线程的函数调用栈信息，其具体用法可以在 linux 下的 man 手册中查看，这里不多展开。而 abi::__cxa_demangle 是 libstdc++ 库中的函数，具体的用法可以在 GNU 网站的《abi Namespace Reference》_[2]中找到

这里再额外补充点：

• 某些编译器的优化选项对获取正确的函数调用栈有干扰
• 内联函数的调用信息也不会出现在函数调用栈当中
• 如果使用 abi::__cxa_demangle 函数，则在连接时需要加上选项 -rdynamic，　注意这是一个　linker option 而非 compiler option，如果你使用 cmake-3.13 或以上的版本，可以使用 add_link_options(-rdynamic)

Exception 的测试结果

tmuduo 当中有关于 Exception 的测试，代码路径为 test/Exception_test.cc。由于调用栈信息比较长，以下只贴一部分的执行结果，有需要的可以自己把代码下下来跑一下
经 demangle 处理的异常信息

未经 demangle 处理的异常信息

从上述结果可以看出，同一个函数 Bar::test 在经过 demangle 处理的异常信息中显示为 Bar::test(...)， 在没有经过 demangle 处理的异常信息中显示为 _ZN3Bar4testEbSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS6_EE+0x1c

参考资料

[1]. Google C++ Style Guide
[2]. abi Namespace Reference
[3].C++ Code Snippet - Print Stack Backtrace Programmatically with Demangled Function Names

本文是 muduo 网络库源码剖析系列文章的第四篇文章，主要涉及了 muduo 网络库中对线程模型的一些设计亮点，以及我如何使用标准线程库来对其进行重新实现，其中包含了以下内容：

• 变量存储期的概念
• pthread_t、pid_t 以及 thread::id 的比较及它们各自的问题
• 如何更加简单方便地封装线程上下文
• 用标准线程库实现 tmuduo 的线程模型

本文中所涉及的代码来源于我的个人项目：tmuduo。本着“纸上学来终觉浅，绝知此事要躬行”的想法，我将 muduo 网络库重新实现了一遍，并在上面验证了自己的不少猜想。项目的仓库地址为 git@github.com:Phoenix500526/Tmuduo.git, 欢迎各位fork + star，一起加入学习

一、变量存储期的概念

C++ 标准中，变量一共有四种不同的存储周期(storage duration)，分别是：

• automatic storage duration: 拥有此生命周期的对象会在代码块的开始处分配内存，并在代码块的结尾处回收内存。
  • 任何没有被声明为 static, extern 或者 thread_local 的局部变量都具备此生命周期
• static storage duration: 拥有此生命周期的对象会在程序开始时分配内存，并在程序结束时回收内存。
  • 任何声明在命名空间中的对象以及被修饰为 static 和 extern 的对象均具有此生命周期
  • 在整个程序运行过程中始终只有一个实例
• thread storage duration: 拥有此生命周期的对象会在线程开始时分配内存，并在线程结束时回收内存。
  • thread_local 可以和 static 以及 extern 连用，此时 static 和 extern 都只表示链接性。
  • 每个线程都有自己的一份 thread_local 对象实例。
• dynamic storage duration：拥有此生命周期的对象会在动态申请内存处分配内存，并在析构时回收内存。

thread_local 与 __thread 的比较

thread_local 关键字总是很容易让人联想到另一个和它非常类似的关键字__thread，二者之间究竟有何区别？
先来看看__thread关键字，__thread 是 GCC 内置的线程局部存储设施，它的实现非常高效，其存储效率可以媲美全局变量。然而使用起来却有以下限制：

• 只能修饰 POD 类型，不能修饰 class 类型(因为 __thread 不会自动调用构造和析构函数)
• 只能使用编译期常量进行初始化
• __thread 只能修饰全局变量和静态变量，但是不能修饰局部变量或者 class 的普通成员变量
  __thread 变量在每个线程中都有一份独立实体，各个线程中的变量值互不干扰。利用这个特点，__thread关键字常常被用来修饰那些“值可能会变，带有全局性，但是又不值得用全局锁保护的变量”。
  而 C++11 的 thread_local 在使用限制上则要宽松不少：
• thread_local 可以修饰非 POD 类型的变量，它会自动调用构造函数和析构函数
• thread_local 除了全局变量以外，还可以修饰局部变量，并且只会在线程生命周期中只会有一个实例。

综上所述，如果你使用 C++11 标准进行开发，使用 thread_local 会比使用 __thread 要好用不少。实际上在 muduo 网络库的源代码中，陈硕使用了 ThreadLocal 类来绕开了 __thread 无法自动调用构造函数和析构函数的限制，而在我的 tmuduo 中，由于使用 thread_local, 因此不在需要实现 ThreadLocal 类。在 tmuduo 的 test/ThreadLocal_test.cc 文件中，我对 thread_local 代替 ThreadLocal 进行了测试，效果还是不错的，有兴趣的可以自行查看代码。另外，由于 C++11 标准的保证，使用 thread_local 实现线程局部单例模式很非常的方便，不过由于脱离本篇内容范畴，因此我将其放在后面和单例模式一起探讨。

二、一种更好的标识线程的方法

如果阅读过 Linux 内核源码实现的朋友应该知道，其实在 Linux 系统下，进程和线程之间并无本质区别：二者实际上都是用同一个结构体 task_struct 来表示一个执行任务的实体。虽然二者的创建方式各不相同，进程创建调用 fork 系统调用，而线程创建主要通过 pthread_create 函数，但这两个方法最终都会调用到 do_fork 来完成具体的创建操作，最大的区别仅在于传进的参数不同。换句话讲，Linux 系统中所谓的线程，只不过是看起来像线程，其本质是和其他进程共享部分资源(虚拟内存、文件描述符以及页表等)的进程。

既然在 Linux 系统下，进程和线程在本质上没有区别，那么是否可以使用用来描述进程的 pid_t 类型来实现 Linux 系统下的线程标识呢？答案是肯定的。但在这之前，我们先来看看为何要如此大费周章地完成这一事情。在 Linux 系统下, 我们想要去标识一个线程,可供选择的有 pthread_t, pid_t 以及 thread::id. 我们先来看看 pthread_t 类型.POSIX 线程库中提供了 pthread_self 函数来获得一个线程的线程 id. 不过由于某些原因, pthread_t 的类型是不确定的,可能是整数、指针或是结构体, 这取决于你使用的具体系统。由于类型的不确定，POSIX 提供了 pthread_equal 函数来比较两个线程标识是否相同，这带来很多问题：

• 如果不知道具体类型，自然也就难以打印输出。对于 printf 函数，不确定类型自然无法打印。对于 C++ 的流，虽然使用时可以不考虑类型差异，但你也很难对输出的结果有合理的预期。
• 无法进行大小和相等性的比较，因此不能过作为 hash 的 key 进行存储
• POSIX 没有提供一个专门用来表示非法线程的专属ID.
• pthread_t 只能保证在当前进程内唯一，并不能保证全局唯一，甚至连在同一个进程内先后创建的不同线程都可能拥有相同的线程ID

接下来再来看看 pid_t, 和 pthread_t 相比，它具有以下特点：

• 类型明确，pid_t 就是一个小整数类型，这也就意味着你可以很方便地将其打印到日志中，同时可以对其值有合理的预期(不必去猜测这个打印出来的 id 到底是数字还是指针)
• 在现代 linux 系统中，pid_t 代表了任务调度 id，而线程是任务的基本调度单位，因此可以很方便地将它们对应起来，这样就可以利用 linux 的 /proc 系统来获取相应的信息
• linux 对 pid_t 的分配采用了轮回递增的方法，因此任何时刻都是全局唯一的，短时间内也不会有重复
• 0 代表非法值，因为 linux 中的第一个进程的 pid 是 1；
  虽然使用 pid_t 来标识线程有上述的好处，不过 linux 并没有提供相应的系统调用来完成这一工作，不过我们依然可以利用间接系统调用 syscall 来绕开这一限制，这在接下来的 一种封装线程上下文的简单尝试** 中会展示。

最后来看看thread::id。在 thread 标准库中也提供了 thread::id 来为进程提供唯一标识。thread::id 相对于 pthread_t 有以下特点:

• thread::id 类型明确，一方面重载了流操作运算符，可以使用流进行输出，也可以利用流将其转换为字符串类型，另一方面标准库也提供了 std::hash 来对 thread::id 进行散列，这样也可以得到一个类型为 std::size_t 的值，两种转换方法如下：

  1 2 3 4 5 6 7

  // thread::id 转换为字符串类型 auto myid = this_thread.get_id(); stringstream ss; ss << myid; string mystring = ss.str(); // thread::id 转换为 std::size_t 类型 std::hash<std::thread::id>()(std::this_thread::get_id())

• 标准库提供了一个 id() 方法，能够获得一个可以用来标记 non-joinable 的线程，也就相当于有了判定非法线程的方法。
• 标准库提供了比较运算符，可以对 thread::id 进行比较

在了解了上述三种标识线程的方法后，我们也很容易根据自己的需求挑选出合适的线程标识类型。如果只考虑 linux 系统开发而不考虑可移植性，那么首选 pid_t 作为线程
ID 的类型。如果有移植性的需要，那么可以考虑使用 thread::id。由于 muduo 网络库本身只考虑 linux 系统，因此采用了 pthread + pid_t 的方式来实现其线程模型。接下来，我会使用 thread + pid_t 的方式重新实现对应的线程模型。

三、一种封装线程上下文的简单尝试

我曾经分析过 skynet 框架中的多线程模型(见《skynet 源码阅读笔记 —— 消息调度机制》一文）。skynet 与 muduo 类似，都是采用了基于回调的 Reactor 模型。由于 skynet 采用 C 语言实现。C 语言中没有闭包的概念，无法方便地实现可调用对象，因此只能定义回调接口，然后定义业务逻辑处理函数来实现接口，并通过回调函数的参数传递上下文(如 skynet 中的 skynet_context)。本来我是想要按照这种方式，利用类来封装线程上下文，并通过传参的方式来传递上下文。但是我在看到了 muduo 网络库的 CurrentThread.{cc,h} 的实现后，感觉又学到了一种新的封装线程上下文的方法：利用 thread_local 来存储相关的上下文(在这里主要是线程id和线程名称)，而利用命名空间来”封装”操作上下文的方法。这种做法非常巧妙，相当于构造了一个生命周期贯穿于线程始末的闭包，它有以下的好处：

• 函数无需传参亦可访问到自身线程上下文信息。如果采用类的方式进行封装，那么在线程中的低阶函数就必须要以传参的方式去获得上下文。
• 使用 thread_local + 命名空间的方法，可以将变量声明为全局变量而无需担心命名污染。全局变量往往存取效率更高
• 比起类的封装，命名空间封装函数的方式在结构上更加松散， 松散的结构虽然降低一定的安全性，但是也带来了灵活性的大大提升。

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

//CurrentThread.h
namespace tmuduo {
namespace detail {
//利用间接系统调用获得线程 id
inline pid_t gettid() { return static_cast<pid_t>(::syscall(SYS_gettid)); }

}  // namespace detail

namespace CurrentThread {

extern thread_local pid_t t_cachedTid;
extern thread_local const char* t_threadName;

// cacheTid、isMainTHread、sleepUsec均定义在 Thread.cc 文件中，
// 因为需要拿到对应线程的 ID
void cacheTid();
bool isMainThread();
void sleepUsec(int64_t usec);  // for testing

inline pid_t tid() {
  if (__builtin_expect(t_cachedTid == 0, 0)) {
    cacheTid();
  }
  return t_cachedTid;
}

inline const char* name() { return t_threadName; }
}  // namespace CurrentThread
}  // namespace tmuduo

//CurrentThread.cc
namespace tmuduo {
namespace CurrentThread {

thread_local pid_t t_cachedTid = 0;
thread_local const char* t_threadName = "unknown";

void cacheTid() {
  if (t_cachedTid == 0) {
    //获取线程的 pid_t
    t_cachedTid = detail::gettid();
  }
}

bool isMainThread() { return tid() == ::getpid(); }

void sleepUsec(int64_t usec) {
  static const int kMicroSecondsPerSecond = 1000 * 1000;
  struct timespec ts = {0, 0};
  ts.tv_sec = static_cast<time_t>(usec / kMicroSecondsPerSecond);
  ts.tv_nsec = static_cast<long>(usec % kMicroSecondsPerSecond * 1000);
  ::nanosleep(&ts, NULL);
}

}  // namespace CurrentThread
}  // namespace tmuduo

在上述代码中，gettid展示了使用 syscall 来获取线程的一般方法(这也是 linux 中 man 关于 syscall 的一个示例用法)。另外，为了避免反复调用系统调用带来的开销，CurrentThread 采用 t_cachedTid 缓存 gettid 的执行结果，因此性能无忧。另外，__builtin_expect 是 GCC 的一个内置函数，其作用是供程序员将分支信息提供给编译器，以方便编译器调整取指令的顺序进行优化，这样可以减少 cache 产生控制冒险。

四、tmuduo 线程类 Thread 的实现

在讨论 tmuduo 如何使用标准线程库来封装线程之前，我们需要先明确几个问题：

• 为什么要封装线程对象？thread 不好用吗？
• 标准线程库比起 POSIX 线程库好在哪？
  对于第一个问题，之所以要封装线程，是因为我们希望让线程在初始化的过程当中去执行一些簿记工作，这样有利于我们进行后期调试。由于标准库不会假定你要做何种工作，因此我们需要自己为 thread 对象做一层薄薄的封装
  对于第二个问题：标准线程库参照了 java 中线程库的设计，历史包袱远远少于 POSIX 线程库，淘汰掉了相当一部分不合理的接口。其次标准库本身与系统无关，具有良好的移植性。最后，标准线程库中的许多函数实现是有语言标准保证的，我们无需做过多额外工作，因此能够减少不少编码工作。

举个例子，在 muduo 网络库中，Thread 采用了 pthread 进行设计，将 Thread 的构造函数和启动函数分离开。这主要是因为当执行 pthread_create 函数创建线程后，线程并不一定是马上开始运行的，尽管当 CPU 低负载的大部分情况下，线程是马上开始运行的。但是当 CPU 负载提高，并发度增加时，有可能会出现线程创建完成后返回，但是线程函数并为开始执行，而此时主线程去访问新线程时就会产生错误。因此，muduo 网络库中的 Thread 对象为了杜绝这种情况，将构造和启动函数分离，并在启动函数中使用了 CountDownLatch 进行同步，只有当创建好的线程开始运行时，start 函数才会返回。而标准库则保证在 thread 的构造函数返回时，线程函数已经开始运行。(具体可见我在 stackoverflow 上的一个讨论：Is that the thread object can be moved in C++ 11 reasonable?)
在明确了构造即启动的语义后，Thread 中可以减少很多用于同步变量以及函数，例如不再需要 start 函数，只需要实现构造函数即可，又例如不再需要用于标识线程运行状态的 started_，因为我们可通过 joinable 来判断一个线程的状态。下面我们来看代码实现：

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
73
74
75
76
77
78
79
80
81
82