编译和链接

这章比较笼统，都是概念，熟悉基本流程的人，建议不看。

 

记录一些基本流程

 

拿GCC来说

用GCC编译链接生成可执行文件的过程分为下面4个步骤

Prepressing，Compilation，Assembly，Linking

 

Prepressing 预处理

从.c -> .i (gcc -E)

主要是处理，前缀为‘#’的语句

 

define的直接替换

对define这种，从我观察应该是这样

对源文件类似.c直接扫描 看到define的符号直接加到表中

然后在替换的时候会做递归检查，直到符号是最终定义。

 

所以这个与define的顺序没有太大关系了，只要不循环嵌套

 

类似这种

#define M (N + 1)

#define N 2

 

这种在用到M的时候，会先替换成 （N + 1）但是发现替换的表达式中还有未决symbol，那么

就再进行替换 （2 + 1）

 

表中并不会直接写成 M （2 + 1），至少我看到的GCC行为是这样。

 

include的也是直接导入

 

另外预编译选项 #ifdef 之类的会处理掉，删掉所有注释

 

#pragma是要被保留给编译器的，这是编译器选项，例如 pragma pack是用来指定字节对齐标准的

 

Compilation 编译

从 .i -> .s (gcc -S)

现在的GCC版本都把预编译和编译做到了一个可执行程序中 -> ccl

 

编译的主要过程

扫描，语法分析，语义分析，源代码优化，代码生成，目标代码优化

Source code --Scanner--> Tokens --Parser--> Syntax Tree

--Semantic Analyzer--> Commented Syntax Tree --Source code Optimizer--> Intermediate Representation

--Code Generator--> Target Code --Code Optimizer-->Final Target Code

Torres 2013-10-21 17:01 发表评论

印象:

硬件PCI/ISA的架构

North Bridge相当于人的心脏，连接所有高速设备，CPU ->大脑

南桥芯片则负责低速设备连接
  

SMP
 

中间层 是解决很多问题的大方向

Any problem in computer science can be resolved by another layer of indirection
 
CPU密集型 IO密集型

这两种类型的Process，理论上优先级高的，也就是说最应该先得到CPU的是IO密集型

通俗的理解应该是IO密集型做完事情花的CPU时间最少，然后就会等待IO设备的反应，这样可以让设备性能最大化
 

Memory

分段分页 MMU
 

其中线程安全有两件事情要注意

Semaphore

Mutex

上面这两个可以做成全局的，并不一定是By Process的，例如POSIX pthread在

对Mutex做attr设定的时候就可以指定为 shared process

也就是说一个Process可以加锁，另外一个可以释放他。

另外这种Mutex必须处在共享内存中，否则没办法访问。有亲缘关系的Process可以通过mmap一个匿名映射做到

anyway有很多方式了。
 

Critical Section

这个是Inter Process的东西。
 

关于线程互斥的lock的问题

RW lock就是对普通lock记录两个状态来供read or write操作选择
 
属于线程本身的东西 TLS/Stack/Register
 

有时候编译器会为了做优化

内存和寄存器的数据会出现不sync的状态。

即使你用lock来做保护,也不一定能OK。然后volatile就出现了。 
 

volatile最主要的作用就是thread内保证编译器不要做优化，防止这种不sync带来的问题。

一般是这样例如x变量，thread_1读到x变量放到了寄存器中，因为可能马上会再访问它，那么对x进行操作后就不会写回内存

这样即使你加了lock，这个时候lock也被释放掉了（操作完成），但是结果未能Sync，那么thread 2来访问x的时候，在内存

中拿到的值就变成dirty状态了。
 

另外一种过度优化就是CPU做的优化，有些上下语义无关的指令，CPU有可能会调整运行顺序。

书中有个经典样例

一段 Singleton pattern的double-check的代码

volatile T* pInst = NULL;

T* getInstance()

{

if (pInst == NULL)

{

lock();

if (pInst == NULL)

pInst = new T();

unlock();

}

return pInst;

}

 

这里有两点

第一，double-check 也就是双if能避免过多的无用的get lock，降低消耗

对临界区需要做保护的资源，可以提前去取状态，如果符合自己的预期，而且短时间不会有变化，那么就不用去拿锁了

不知道为啥我想到了unlikely，但仔细想一下，功能完全不同。
 

第二点也就是要说的CPU的过度优化

这里已经是声明volatile了，所以没有寄存器和内存不sync的问题

但是由于这里new需要先 malloc出空间，然后call T的constructor。

所以有可能会发生这种情况，malloc出空间后，把地址付给pInst，然后去做初始化；

这样就有可能另外一个线程取得的object是没有被完全初始化好的，是否会出问题depend on T的具体实现了。

许多CPU提供了barrier指令用来解决上面提到的问题。
 

线程模型

这个东西，我看了下，开始没看明白，这边书这个东西没讲清楚，后来去网上找了些资料。用户线程和内核线程的对应关系取决于调度单位。

也就是说内核把什么东西当做一个调度单位
 

拿Linux来说吧，Process是线程集和资源集
 

调度的时候，那些共享资源的Task（thread）之间的调度肯定比那些跨Process不共享资源的thread做context switch消耗的资源

多得多。
 

基于调度消耗之类的考量

模型分为下面几种
 

一对一，也就是说 user space create出来的线程就是和kernel的调度单位相同，称一一对应
 

一对多，应该是这样一种情况，kernel看到的是Process，userspace自己实现出来自己的thread，这个thread，kernel是不知道的

调度的时候kernel负责分批CPU给他能看到的Process，上层userspace自己来调度分配这个Process获得的CPU time给这个process中的

各个线程。

这样的分配就可以保证在一定的时间内只需要做一些register和stack的切换，不会有memory等等的switch。

坏处是上面的thread只要一个被suspend，那么这个Process里面的其他thread也就被suspend住了，一般上层调度程序

不会假定其他的thread能run，所以一般会是kernel把CPU time给其他process
 

多对多，就是一种混合的情况了，我想到了Android，但是Android是一对一模型，dalvik会保证Java thread对应下面一个

native thread，想说的是，这种虚拟机架构可以做成多对多的样子，一个native thread run一个JVM，JVM开出来很多Java Thread，

JVM负责调度这些Java Thread，Native负责调度JVM所在的Thread。

不知道我有没有讲错。

Torres 2013-10-18 19:42 发表评论

Torres 2013-10-14 17:07 发表评论