竞态（race condition）

软件层面上，竞态是指多个线程或进程读写一个共享资源 (或共享设备) 时的输出结果依赖于线程或进程的先后执行顺序或者时间；
（ 更权威的介绍可以看 wiki )

至于为什么会发生竞态呢？很简单，因为并发，并发使多线程，多进程环境变成可能。

竞态具体场景：假如我们有 2 个进程会对一个全局变量进行 ++ 操作，理想时，程序会这样执行：

然而，由于并发的普遍存在，使得情况有时” 不受控制”（不如工程师预期那样工作），可能会变成这样：

并发（concurrency）

并发 (concurrency) 指的是多个执行单元同时、并行被执行。而并发的执行单元对共享资源 (硬件资源和软件上的全局、静态变量) 的访问则容易导致竞态 (race conditions), 可能导致并发 (即竞态?) 的情况有：

• SMP（Symmetric Multi-Processing），对称多处理结构。SMP 是一种紧耦合、共享存储的系统模型，它的特点是多个 CPU 使用共同的系统总线，因此可访问共同的外设和存储器。

• 中断. 中断可以打断正在执行的进程 (哪怕是在中断上下文)，若中断处理程序对共享资源进程访问，则竞态也会发生.

• 内核抢占.2.6 以后内核提供了内核可抢占特性，虽然是作为一个配置选项，但我们写程序时还是要考虑周全，故内核抢占也是作为伪并发的表现，也可能发生竞态；

临界区（critical section）

多个线程进程对共享资源进行访问在软件表现为一个程序片段，如何避免竞态的发生呢？

一个执行路径在对共享资源进行访问时禁止其他执行路径进行访问，当有一个执行路径（A）对共享资源进行访问时，如有其他执行路径想访问共享资源，须睡眠等待 A 执行路径退出。

那么这时这个程序片段就是临界区。那么具体如何来实现临界区呢？linux 内核提供了多种同步互斥机制.（如信号量，互斥量，自旋锁，RCU，原子操作等）.

什么是RAII技术

我们在C++中经常使用new申请了内存空间，但是却也经常忘记delete回收申请的空间，容易造成内存溢出，于是RAII技术就诞生了，来解决这样的问题。

RAII（Resource Acquisition Is Initialization）机制是Bjarne Stroustrup首先提出的，是一种利用对象生命周期来控制程序资源（如内存、文件句柄、网络连接、互斥量等等）的简单技术。 我们知道在函数内部的一些成员是放置在栈空间上的，当函数返回时，这些栈上的局部变量就会立即释放空间，于是Bjarne Stroustrup就想到确保能运行资源释放代码的地方就是在这个程序段（栈）中放置的对象的析构函数了，因为stack winding会保证它们的析构函数都会被执行。RAII就利用了栈里面的变量的这一特点。

RAII 的一般做法是这样的：在对象构造时获取资源，接着控制对资源的访问使之在对象的生命周期内始终保持有效，最后在对象析构的时候释放资源。

借此，我们实际上把管理一份资源的责任托管给了一个存放在栈空间上的局部对象。
这种做法有两大好处：

• (1)不需要显式地释放资源。
• (2)采用这种方式，对象所需的资源在其生命期内始终保持有效。

SQL GROUP BY 实例

我们拥有下面这个 “Orders” 表：

现在，我们希望查找每个客户的总金额（总订单）。
我们想要使用 GROUP BY 语句对客户进行组合。
我们使用下列 SQL 语句：

SELECT Customer,SUM(OrderPrice) FROM Orders GROUP BY Customer

结果集类似这样：

很棒吧，对不对？
让我们看一下如果省略 GROUP BY 会出现什么情况：

SELECT Customer,SUM(OrderPrice) FROM Orders

结果集类似这样：

上面的结果集不是我们需要的。
那么为什么不能使用上面这条 SELECT 语句呢？

解释如下：
上面的 SELECT 语句指定了两列（Customer 和 SUM(OrderPrice)）。
“SUM(OrderPrice)” 返回一个单独的值（”OrderPrice” 列的总计），而 “Customer” 返回 6 个值（每个值对应 “Orders” 表中的每一行）。
因此，我们得不到正确的结果。不过，您已经看到了，GROUP BY 语句解决了这个问题。

本文不讨论类的虚函数, 请参考 C++对象模型之虚函数讲解

内存对齐规则

首先我们明确内存对齐规则

我们设

A = #pragma pack()指定的数
B = 这个数据成员的自身长度
C = 结构(或联合)中最大数据成员长度

在解释内存对齐的作用前，先来看下内存对齐的规则：

1. 对于结构的各个成员，第一个成员位于偏移为0的位置，
以后每个数据成员的偏移量必须是 min( A，B ) 的倍数。

2. 在数据成员完成各自对齐之后，结构(或联合)本身也要进行对齐，对齐将按照 min( A, C) 进行。

问题

32位机器上, 下列代码的sizeof(a)的值是多少?

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

#pragma pack(2)

class A
{
    int i;

    union U
    {

        char buff[13];

        int i;

    }u;

    void foo() {    }

    typedef char* (*f)(void*);

    enum{ red, green, blue } color;
}a;
#pragma pack()

答案

答案是sizeof(a)的值为22.

• void foo() { } ，typedef char* (f)(void);不占字节，
• 枚举占4个字节，
• union按最大的变量所占字节算，占14个字节，
• int占4个字节，

4+14+4=22。

如果把#pragma pack(2)改为 #pragma pack(4)， sizeof(a)的值就为 24。

解析

分为三部分来解析:

• 枚举所占内存计算方法
• #pragma pack用法
• 共用体(union)所占内存计算方法

枚举所占内存计算方法

枚举变量，由枚举类型定义的变量。枚举变量的大小，即枚举类型所占内存的大小。

由于枚举变量的赋值，一次只能存放枚举结构中的某个常数。

所以枚举变量的大小，实质是常数所占内存空间的大小（常数为int类型，当前主流的编译器中一般是32位机器和64位机器中int型都是4个字节），枚举类型所占内存大小也是这样。

#pragma pack用法

#pragma pack(a)规定的对齐长度（a可选值为1，2，4，8，16），实际使用的规则是：
结构，联合，或者类的数据成员，第一个放在偏移为0的地方，以后每个数据成员的对齐，按照#pragma pack指定的数值和这个数据成员自身长度中，比较小的那个进行。
也就是说，当#pragma pack的值等于或超过所有数据成员长度的时候，这个值的大小将不产生任何效果。
而结构整体的对齐，则按照结构体中最大的数据成员 和 #pragma pack指定值 之间，较小的那个进行。
而 #pragma pack() 表示恢复默认的内存对齐（与#pragma pack(a)指令配对使用）

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

#pragma pack(4)

class TestB
{
public:

    int aa; //第一个成员，放在[0,3]偏移的位置，

    char a; //第二个成员，自身长为1，#pragma pack(4),取小值，也就是1，所以这个成员按一字节对齐，放在偏移[4]的位置。

    short b; //第三个成员，自身长2，#pragma pack(4)，取2，按2字节对齐，所以放在偏移[6,7]的位置。

    char c; //第四个，自身长为1，放在[8]的位置。

};
#pragma pack()

这个类实际占据的内存空间是9字节
类之间的对齐，是按照类内部最大的成员的长度，和#pragma pack规定的值之中较小的一个对齐的。
所以这个例子中，类之间对齐的长度是min(sizeof(int),4)，也就是4。
9按照4字节圆整的结果是12，所以sizeof(TestB)是12。

如果

1
2
3
4
5
6
7
8
9
10

#pragma pack(2)
class TestB
{
public:
    int aa; //第一个成员，放在[0,3]偏移的位置，
    char a; //第二个成员，自身长为1，#pragma pack(2),取小值，也就是1，所以这个成员按一字节对齐，放在偏移[4]的位置。
    short b; //第三个成员，自身长2，#pragma pack(2)，取2，按2字节对齐，所以放在偏移[6,7]的位置。
    char c; //第四个，自身长为1，放在[8]的位置。
};
#pragma pack()

可以看出，上面的位置完全没有变化，只是类之间改为按2字节对齐，9按2圆整的结果是10。
所以 sizeof(TestB)是10。

现在去掉第一个成员变量为如下代码：

1
2
3
4
5
6
7
8
9

#pragma pack(4)
class TestC
{
public:
　　char a;//第一个成员，放在[0]偏移的位置，
　　short b;//第二个成员，自身长2，#pragma pack(4)，取2，按2字节对齐，所以放在偏移[2,3]的位置。
　　char c;//第三个，自身长为1，放在[4]的位置。
};
#pragma pack()

整个类的大小是5字节，按照min(sizeof(short),4)字节对齐，也就是2字节对齐，结果是6，所以sizeof(TestC)是6。

共用体(union)所占内存计算方法

共用体又名”联合体”, 英文名为union.

当多个数据需要共享内存或者多个数据每次只取其一时，可以利用联合体(union)。在C Programming Language 一书中对于联合体是这么描述的：

• 联合体是一个结构；
• 它的所有成员相对于基地址的偏移量都为0；
• 此结构空间要大到足够容纳最”宽”的成员；
• 其对齐方式要适合其中所有的成员；

下面解释这四条描述：

由于联合体中的所有成员是共享一段内存的，因此每个成员的存放首地址相对于于联合体变量的基地址的偏移量为0，即所有成员的首地址都是一样的。为了使得所有成员能够共享一段内存，因此该空间必须足够容纳这些成员中最宽的成员。对于这句“对齐方式要适合其中所有的成员”是指其必须符合所有成员的自身对齐方式。

下面举例说明：

1
2
3
4
5
6

union U
{
    char s[9];
    int n;
    double d;
};

s占9字节，n占4字节，d占8字节，因此其至少需9字节的空间。然而其实际大小并不是9，用运算符sizeof测试其大小为16.这是因为这里存在字节对齐的问题，9既不能被4整除，也不能被8整除。

因此补充字节到16，这样就符合所有成员的自身对齐了。从这里可以看出联合体所占的空间不仅取决于最宽成员，还跟所有成员有关系，即其大小必须满足两个条件：

• 大小足够容纳最宽的成员；
• 大小能被其包含的所有基本数据类型的大小所整除。

若问题为#pragma pack(4)的情况

• void foo() { } ，typedef char* (f)(void);不占字节，
• 枚举占4个字节，
• union按最大的变量buff[13]所占字节算为13, 在#pragma pack(2)的情况, 得补齐1个字节变为14才能被2整除, 而#pragma pack(4)的情况得补齐3个字节, 总占16个字节，才可以被4整除,
• int占4个字节

所以#pragma pack(4)的情况, sizeof(A)为4+16+4=24。

练习

注意有陷阱, 32位环境下

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

# pragma pack(2)
class test_class
{
public:
	static float i;

	union test_union
	{
		int bb;
		char aa[13];
		short cc;
	};
	
	enum test_enum
	{
		monday,
		tuesday,
		sunday
	};

	virtual void testFunc() {}
	
	char xmly;
};

# pragma pack()

int main()
{
	cout << "sizeof(test_class) : " << sizeof(test_class) << endl; 
	return 0;
}

请问打印结果?

sizeof(test_class) : 6

为什么呢?
注意看共用体 test_union 和枚举 test_enum其实并没有声明变量, 如果写成

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

#include <iostream>

using namespace std;

# pragma pack(2)
class test_class
{
public:
	static float i;

	union test_union
	{
		int bb;
		char aa[13];
		short cc;
	}uVar;

	enum test_enum
	{
		monday,
		tuesday,
		sunday
	}eVar;

	virtual void testFunc() {}

	char xmly;
};
# pragma pack()

enum enum_x 
{ 
	x1=5, 
	x2, 
	x3, 
	x4, 
}; 
enum enum_x x=x3; 

int main()
{
	cout << "sizeof(test_class) : " << sizeof(test_class) << endl; 

	cout << "x : " << x << endl;

	test_class::test_enum i;
	i = test_class::monday;
	cout << "i : " << i << endl;

	test_class test_obj;
	test_obj.eVar = test_class::sunday;
	cout << test_obj.monday << endl;

	cout << test_class::sunday << endl;
	return 0;
}

打印结果就为

1
2
3
4
5

sizeof(test_class) : 24
x : 7
i : 0
0
2

1. 为什么需要分支预测优化

将流水线引入cpu，可以提高cpu的效率。更简单的说，让cpu可以预先取出下一条指令，可以提供cpu的效率。如下图所示：

可见，cpu流水钱可以减少cpu等待取指令的耗时，从而提高cpu的效率。
如果存在跳转指令，那么预先取出的指令就无用了。cpu在执行当前指令时，从内存中取出了当前指令的下一条指令。执行完当前指令后，cpu发现不是要执行下一条指令,而是执行offset偏移处的指令。cpu只能重新从内存中取出offset偏移处的指令。因此，跳转指令会降低流水线的效率，也就是降低cpu的效率。

综上，在写程序时应该尽量避免跳转语句。那么如何避免跳转语句呢？答案就是使用__builtin_expect。

这个指令是gcc引入的，作用是”允许程序员将最有可能执行的分支告诉编译器”。

这个指令的写法为：builtin_expect(EXP, N)。意思是：EXP==N的概率很大。一般的使用方法是将builtin_expect指令封装为LIKELY和UNLIKELY宏。这两个宏的写法如下。

1
2

#define LIKELY(x) __builtin_expect(!!(x), 1) //x很可能为真
#define UNLIKELY(x) __builtin_expect(!!(x), 0) //x很可能为假

在很多源码如Linux内核、Glib等,我们都能看到likely()和unlikely()这两个宏,通常这两个宏定义是下面这样的形式。
可以看出这2个宏都是使用函数 builtin_expect()实现的, builtin_expect()函数是GCC的一个内建函数(build-in function).

2. 函数声明

函数__builtin_expect()是GCC v2.96版本引入的, 其声明如下:

long __builtin_expect(long exp, long c);

2.1. 功能描述

由于大部分程序员在分支预测方面做得很糟糕，所以GCC 提供了这个内建函数来帮助程序员处理分支预测.

你期望 exp 表达式的值等于常量 c, 看 c 的值, 如果 c 的值为0(即期望的函数返回值), 那么 执行 if 分支的的可能性小, 否则执行 else 分支的可能性小(函数的返回值等于第一个参数 exp).

GCC在编译过程中，会将可能性更大的代码紧跟着前面的代码，从而减少指令跳转带来的性能上的下降, 达到优化程序的目的.

通常，你也许会更喜欢使用 gcc 的一个参数 ‘-fprofile-arcs’ 来收集程序运行的关于执行流程和分支走向的实际反馈信息,但是对于很多程序来说,数据是很难收集的。

2.2. 参数详解

• exp
  exp 为一个整型表达式, 例如: (ptr != NULL)

• c
  c 必须是一个编译期常量, 不能使用变量

2.3. 返回值

　　返回值等于 第一个参数 exp

2.4. 使用方法

与关键字if一起使用.首先要明确一点就是 if (value) 等价于 if (__builtin_expert(value, x)), 与x的值无关.

例子如下:

例子1 : 期望 x == 0, 所以执行func()的可能性小

1
2
3
4
5
6
7
8

if (__builtin_expect(x, 0))
{
    func();
}
else
{
　　//do someting
}

例子2 : 期望 ptr !=NULL这个条件成立(1), 所以执行func()的可能性小

1
2
3
4
5
6
7
8

if (__builtin_expect(ptr != NULL, 1))
{　　
　　//do something
}
else
{
　　func();
}

例子3 : 引言中的likely()和unlikely()宏

首先,看第一个参数!!(x), 他的作用是把(x)转变成”布尔值”, 无论(x)的值是多少 !(x)得到的是true或false, !!(x)就得到了原值的”布尔值”

使用 likely() ，执行 if 后面的语句 的机会更大，使用 unlikely()，执行 else 后面的语句的机会更大。

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

#define likely(x)    __builtin_expect(!!(x), 1)
#define unlikely(x)  __builtin_expect(!!(x), 0)

int main(char *argv[], int argc)
{
   int a;

   /* Get the value from somewhere GCC can't optimize */
   a = atoi (argv[1]);

   if (unlikely (a == 2))
　 {
      a++;
   }
   else
　 {
　　  a--;
　 }
   printf ("%d\n", a);

   return 0;
}

3. RATIONALE(原理)

if else 句型编译后, 一个分支的汇编代码紧随前面的代码,而另一个分支的汇编代码需要使用JMP指令才能访问到.

很明显通过JMP访问需要更多的时间, 在复杂的程序中,有很多的if else句型,又或者是一个有if else句型的库函数,每秒钟被调用几万次,

通常程序员在分支预测方面做得很糟糕, 编译器又不能精准的预测每一个分支,这时JMP产生的时间浪费就会很大,

函数 __builtin_expert() 就是用来解决这个问题的.

有些错误是编译器查不到的, 这种错误是最可怕的, 当项目大了之后,
即使用 Valgrind 也很难定位,
因为裸指针在团队合作中使用很容易导致其他成员忘记释放或多次释放, 所以在团队合作中一般使用智能指针.

而智能指针用的不好, 结果可能适得其反.

所以我们聊一下智能指针的几点注意事项.

总结自 C++ Primer.

一个简单的包含删除器的例子演示

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

#include<iostream>
#include<functional>
#include<memory>

using std::cout;
using std::endl;
using std::bind;
using namespace std::placeholders;

int testBind( int* a, int b, int c )
{
	cout << *a + b + c << endl;
	return *a;
}

struct Foo
{
	Foo() = default;
	Foo( const Foo & a )
	{
		data = a.data;
		std::cout << "复制构造" << std::endl;
	}
	void print_sum( int n1, int n2 )
	{
		std::cout << n1 + n2 << '\n';
	}
	int data = 10;
};

int main()
{
	//绑定类成员函数用对象的指针
	Foo foo;
	auto f3 = std::bind( &Foo::print_sum, &foo, 95, _1 );
	f3( 5 );

	auto check_testBind = std::bind( testBind, std::placeholders::_1, 3, 9 );
	int * p = new int( 7 );
	cout << check_testBind( p ) << endl;

	shared_ptr<int> pi( new int(),
		check_testBind );
	*pi = 88;

	shared_ptr<int> pii( new int( 12 ),
		std::bind( testBind, std::placeholders::_1, 32, 19 ) );

	std::function< int( int* ) > test_function_bind =
		std::bind( testBind, std::placeholders::_1, 331, 9 );

	cout << "test_function_bind( p, 331, 9 ) = " << test_function_bind( p ) << endl;;

	shared_ptr<int> piii( new int( 112 ),
		test_function_bind );

	return 0;
}

打印结果 :

100
119
7
347
test_function_bind( p, 331, 9 ) = 7
452
63
100
请按任意键继续. . .

智能指针陷阱

智能指针可以提供对动态分配的内存安全而又方便的管理，但这建立在正确使用的
前提下 。 为了正确使用智能指针，我们必须坚持一些基本规范 :

• 不使用相同的内置指针值初始化(或 reset) 多个智能指针 。
• 不 delete get ( ) 返 回的指针 。
• 不使用 get () 初始化或 reset 另 一 个智能指针 。
• 如果你使用 get () 返 回的指针，记住当最后一个对应的智能指针销 毁 后， 你 的
  指 针就 变为无 效 了 。
• 如果你使用智能指针管理的资源不是 new 分配的内存 ， 记住传递给它一个删除
  器( 参见 12. 1.4 节 ， 第 415 页和 12. 1.5 节 ， 第 419 页)。

尽量用make_shared而非new

shared_ptr 可以协调对象的析构 ， 但这仅限于其自身的拷贝 ( 也 是 shared_ptr)
之间。

这也是为什么我们推荐使用 make_shared 而不是 new 的原因 。

这样 ， 我们就能在分配对象的同时就将 shared_ptr 与之绑定，
从而避免了无意中将同一块内存绑定到多个独立创建的 shared_ptr 上 。(这是最容易犯的错)

总结 : 所以我们要尽量一开始就用make_shared来分配动态内存, 而不是先new一个出来, 再找机会将它转为智能指针.

考虑下面对 shared_ptr 进行操作的函数 :

1
2
3
4
5

// 在函数被调用时 ptr 被创建并初始化
void process(shared_ptr<int> ptr)
{
  // 使用 ptr
} // ptr 离 开作用域，被销毁

process 的参数是传值方式传递的，因此实参会被拷贝到 ptr 巾 。 拷贝 一 个 shared_ptr
会递增其引用讨数，因此， 在 process 运行过程中，引用七| 数值至少为 2 。 当 process
结束时， ptr 的引用计数会边喊，但不会变为 0 。 因此，当用音11变 11 ptr 被销毁时， ptr
指向的内存不会被释放 。

使用此函数的正确方法是传递给它一个 shared_ptr :

1
2
3

shared_ptr<int> p(new int(42)) ; // 引用计数为 1
process(p); // 拷贝 p 会递增它的引用计数 ;在 process 中引用计数位为 2
int i = *p; // 正确:引用计数位为 1

虽然不能传递给 process 一 个内置指针，但可以传递 给它 一 个(临时的)
shared_ptr ， 这个 shared_ptr 是用 一个内 置指针显式构造的 。 但是，这样做很可能
会导致错误 :

1
2
3
4

int *x(new int(1024)); // 危险 x 是一个普通指针，不是一个智能指针
process(x) ; // 错误 : 不能将 int* 转换为 一个 shared_ptr<int>
process(shared_ptr<int>(x)); // 合法的，但内存会被释放!
int j = *x ; //未定义的 x 是一个空悬指针!

在上面的调用中 ， 我们将一个临时 shared_ptr 传递给 process 。 当这个调用所在的表
达式结束时，这个临时对象就被销毁了 。 销毁这个临时变量会递减引用计数，此时引用计
数就变为 0 了 。 因此，当临时对象被销毁时 ， 它所指向的内存会被释放 。
但 x 继续指 向 (已经释放的)内存，从而变成一个空悬指针。如果试图使用 x 的值，
其行为是未定义的 。

当将一个 shared_ptr 绑定到一个普通指针时 ， 我们就将内存的管理责任交给了这
个 shared_ptr 一旦这样做 了 ， 我们就不应该再使用内置指针来访问 shared_ptr 所
指向的内存了

不要使用 get 初始化另一个智能指针或为智能指针赋值

智能指针类型定义了 一个名为 get 的函数(参见表 1 2. J )，它返回一个内置指针，
指向智能指针管理的对象 。 此函数是为了这样一种情况而设计的 : 我们需要向不能使用智
能指针的代码传递一个内置指针。使用 get 返回的指告| 的代码不能 delete 此指针 。
虽然编译器不会给出错误信息 ， 但将另一个智能指针也绑定到 get 返回的指针上是
错误的 :

1
2
3
4
5
6
7

shared_ptr<int> p(new int(42)) ; // 引 用计数为 1
int *q = p . get() ; // 正确 · 但使用 q 时妥注意，不要让它管理的指针被释放
{ // 新程序块
// 未定义:两个独立的 shared_ptr 指 向 相同的内存
    shared ptr<int> (q) ;
} // 程序块结束， q 被销毁 ， 它指向的内存被待放
int foo = *p ; // 未定义 p 指向的内存 已 经被释放了

在本例中， p 和 q 指 向相同的内存。由于它们是相互独立创建的，因此各自的引用计数都
是 1。 当 q 所在的程序块结束时 ， q 被销毁 ， 这会导致 q 指向的内存被释放 。 从而 p 变成
一个空悬指针，意味着当我们试图使用 p 时，将发生未定义的行为 。 而且 ， 当 p 被销毁时 ，
这块内存会被第二次 delete 。

get 用来将指针的访问权限传递给代码，你只有在确定代码不会 get.
特别是，永远不要用 get 初始化另一个智能指针 del ete 指针或者为另一个智能指针赋值.