0. 背景

原子操作就是不可再分的操作。在多线程程序中原子操作是一个非常重要的概念，它常常用来实现一些同步机制，同时也是一些常见的多线程Bug的源头。本文主要讨论了三个问题：1. 多线程程序中对变量的读写操作是否是原子的？2. 多线程程序中对Bit field（位域）的读写操作是否是线程安全的？3. 程序员该如何使用原子操作？

1. 多线程环境下对变量的读写操作是否是原子的？

我们先从一道很热门的百度笔试题讲起。很多人讲不清楚其背后的原理，下面我们就来对它进行一下剖析（其实这个题目有点歧义，后面我们会讲到）：

以下多线程对int型变量x的操作，哪几个需要进行同步：（ ）
A. x=y; B. x++; C. ++x; D. x=1;

要彻底理解这个问题，我们首先需要从硬件讲起。以常见的X86 CPU来说，根据Intel的参考手册，它基于以下三种机制保证了多核中加锁的原子操作（8.1节）：
（1）Guaranteed atomic operations （注：8.1.1节有详细介绍）
（2）Bus locking, using the LOCK# signal and the LOCK instruction prefix
（3）Cache coherency protocols that ensure that atomic operations can be carried out on cached data structures (cache lock); this mechanism is present in the Pentium 4, Intel Xeon, and P6 family processors

这三个机制相互独立，相辅相承。简单的理解起来就是
（1）一些基本的内存读写操作是本身已经被硬件提供了原子性保证（例如读写单个字节的操作）；
（2）一些需要保证原子性但是没有被第（1）条机制提供支持的操作（例如read-modify-write）可以通过使用”LOCK#”来锁定总线，从而保证操作的原子性
（3）因为很多内存数据是已经存放在L1/L2 cache中了，对这些数据的原子操作只需要与本地的cache打交道，而不需要与总线打交道，所以CPU就提供了cache coherency机制来保证其它的那些也cache了这些数据的processor能读到最新的值（关于cache coherency可以参加我的一篇博文）。

那么CPU对哪些（1）中的基本的操作提供了原子性支持呢？根据Intel手册8.1.1节的介绍：

从Intel486 processor开始，以下的基本内存操作是原子的：
• Reading or writing a byte（一个字节的读写）
• Reading or writing a word aligned on a 16-bit boundary（对齐到16位边界的字的读写）
• Reading or writing a doubleword aligned on a 32-bit boundary（对齐到32位边界的双字的读写）

从Pentium processor开始，除了之前支持的原子操作外又新增了以下原子操作：
• Reading or writing a quadword aligned on a 64-bit boundary（对齐到64位边界的四字的读写）
• 16-bit accesses to uncached memory locations that fit within a 32-bit data bus（未缓存且在32位数据总线范围之内的内存地址的访问）

从P6 family processors开始，除了之前支持的原子操作又新增了以下原子操作：
• Unaligned 16-, 32-, and 64-bit accesses to cached memory that fit within a cache line（对单个cache line中缓存地址的未对齐的16/32/64位访问）

那么哪些操作是非原子的呢？
Accesses to cacheable memory that are split across bus widths, cache lines, and
page boundaries are not guaranteed to be atomic by the Intel Core 2 Duo, Intel®
Atom™, Intel Core Duo, Pentium M, Pentium 4, Intel Xeon, P6 family, Pentium, and
Intel486 processors.（说点简单点，那些被总线带宽、cache line以及page大小给分隔开了的内存地址的访问不是原子的，你如果想保证这些操作是原子的，你就得求助于机制（2），对总线发出相应的控制信号才行）。

需要注意的是尽管从P6 family开始对一些非对齐的读写操作已经提供了原子性保障，但是非对齐访问是非常影响性能的，需要尽量避免。当然了，对于一般的程序员来说不需要太担心这个，因为大部分编译器会自动帮你完成内存对齐。

回到最开始那个笔试题。我们先反汇编一下看看它们到底执行了什么操作：

（1）很显然，x=1是原子操作。
因为x是int类型，32位CPU上int占32位，在X86上由硬件直接提供了原子性支持。实际上不管有多少个线程同时执行类似x=1这样的赋值语句，x的值最终还是被赋的值（而不会出现例如某个线程只更新了x的低16位然后被阻塞，另一个线程紧接着又更新了x的低24位然后又被阻塞，从而出现x的值被损坏了的情况）。

（2）再来看x++和++x。
其实类似x++, x+=2, ++x这样的操作在多线程环境下是需要同步的。因为X86会按三条指令的形式来处理这种语句：从内存中读x的值到寄存器中，对寄存器加1，再把新值写回x所处的内存地址（见上面的反汇编代码）。

例如有两个线程，它们按照如下顺序执行（注意读x和写回x是原子操作，两个线程不能同时执行）：

time    Thread 1         Thread 2
0      load eax, x
1                            load eax, x
2      add eax, 1        add eax, 1
3      store x, eax
4                            store x, eax

我们会发现最终x的值会是1而不是2，因为Thread 1的结果被覆盖掉了。这种情况下我们就需要对x++这样的操作加锁（例如Pthread中的mutex）以保证同步，或者使用一些提供了atomic operations的库（例如Windows API中的atomic库，Linux内核中的atomic.h，Java concurrent库中的Atomic Integer，C++0x中即将支持的atomic_int等等，这些库会利用CPU提供的硬件机制做一层封装，提供一些保证了原子性的API）。

（3）最后来看看x=y。
在X86上它包含两个操作：读取y至寄存器，再把该值写入x。读y的值这个操作本身是原子的，把值写入x也是原子的，但是两者合起来是不是原子操作呢？我个人认为x=y不是原子操作，因为它不是不可再分的操作。但是它需要不需要同步呢？其实问题的关键在于程序的上下文。

例如有两个线程，线程1要执行{y = 1; x = y;}，线程2要执行{y = 2; y = 3;}，假设它们按如下时间顺序执行：

time    Thread 1        Thread 2
0        store y, 1
1                            store y, 2
2        load eax, y
3                            store y, 3
4        store x, eax

那么最终线程1中x的值为2，而不是它原本想要的1。我们需要加上相应的同步语句确保y = 2不会在线程1的两条语句之间发生。y = 3那条语句尽管在load y和store x之间执行，但是却不影响x=y这条语句本身的语义。所以你可以说x=y需要同步，也可以说x=y不需要同步，看你怎么理解题意了。x=1是否需要同步也是一样的道理，虽然它本身是原子操作，但是如果有另一个线程要读x=1之后的值，那肯定也需要同步，否则另一个线程读到的就是x的旧值而不是1了。

2. 对Bit field（位域）的读写操作是否是线程安全的？

Bit field常用来高效的存储有限位数的变量，多用于内核/底层开发中。一般来说，对同一个结构体内的不同bit成员的多线程访问是无法保证线程安全的。

例如Wikipedia中的如下例子：

两个线程分别对my_foo.flag和my_foo.counter进行读写操作，但是即使有上面的加锁方式仍然不能保证它是线程安全的。原因在于不同的成员在内存中的具体排列方式“跟Byte Order、Bit Order、对齐等问题都有关，不同的平台和编译器可能会排列得很不一样，要编写可移植的代码就不能假定Bit-field是按某一种固定方式排列的”[3]。而且一般来讲CPU对内存操作的最小单位是word（X86的word是16bits），而不是1bit。这就是说，如果my_foo.flag和my_foo.counter存储在同一个word里，CPU在读写任何一个bit member的时候会同时把两个值一起读进寄存器，从而造成读写冲突。这个例子正确的处理方式是用一个mutex同时保护my_foo.flag和my_foo.counter，这样才能确保读写是线程安全的。

在C++0x草案中对bit field是这样定义的：
连续的多个非0bit的bit fields是属于同一个memory location的；长度为0bit的bit field会把占单独的一个memory location。对同一个memory location的读写不是线程安全的；对不同memory location的读写是线程安全的。
例如在下图的例子中bf1和bf2是同一个memory location，bf3是一个单独的memory location，bf4是一个单独的memory location：

这里有一个因为Bit field不是线程安全所导致的一个Linux内核中的Bug。

引用一下Pongba的总结：

所以，如果你的多个bitfields是连续的，同时又想要无冲突的读取它们，有两种做法，一是在中间用0大小bitfield隔开，但这种做法实际上就消除了bitfield的节省内存的初衷，因为为了使它们不冲突，至少被隔开的两个bitfield肯定不可能共享byte了。另一种做法当然就是用锁了。

3. 程序员该怎么用Atomic操作？

一般情况下程序员不需要跟CPU提供的原子操作直接打交道，所以只需要选择语言或者平台提供的atomic API即可。而且使用封装好了的API还有一个好处是它们常常还提供了诸如compare_and_swap，fetch_and_add这样既有读又有写的较复杂操作的封装。

常见的API如下：

Windows上InterlockedXXXX的API
GNU/Linux上linux kernel中atomic_32.h
GCC中的Atomic Builtins (__sync_fetch_and_add()等)
Java中的java.util.concurrent.atomic
C++0x中的atomic operation
Intel TBB中的atomic operation

4. 参考文献：

[1] 关于变量操作的原子性(atomicity)FAQ
[2] http://en.wikipedia.org/wiki/Atomic_operation
[3] 关于内存对齐、bit field等 –《Linux C编程一站式学习》
[4] Do you need mutex to protect an ‘int’?
[5] C++ Concurrency in Action
[6] Multithreaded simple data type access and atomic variables
[6] http://www.newsmth.net/bbscon.php?bid=335&id=236629
[7] http://www.newsmth.net/bbscon.php?bid=335&id=209239
[8] http://www.newsmth.net/bbscon.php?bid=335&id=186723
转载请注明来自parallellabs.com

 
可以同样看到ABC都是写简单数据类型 并且操作的结果与初值相关。所以需要加锁。即要求同步

文章出处：飞诺网(www.firnow.com):http://dev.firnow.com/course/3_program/c++/cppjs/2008717/133440.html
 
可以同样看到ABC都是写简单数据类型 并且操作的结果与初值相关。所以需要加锁。即要求同步

第2种情况的典型代表是“i++;”，需要对它加锁是因为它表面上虽然只有一条语句，却要执行至少两个操作，一是读出i的初始, 二是把加一后的结果写回去，两个操作就没有“原子性”了，所以需要加锁.

文章出处：飞诺网(www.firnow.com):http://dev.firnow.com/course/3_program/c++/cppjs/2008717/133440.html

1、static_cast

用法：static_cast<type-id>(expression)

该运算符把expression转换为type-id类型，但没有运行时类型检查来保证转换的安全性。它主要有如下几种用法：

①用于类层次结构中基类和子类之间指针或引用的转换。进行上行转换（把子类的指针或引用转换成基类表示）是安全的；进行下行转换（把基类指针或引用转换成子类表示）时，由于没有动态类型检查，所以是不安全的。

②用于基本数据类型之间的转换，如把int转换成char，把int转换成enum。这种转换的安全性也要开发人员来保证。

③把空指针转换成目标类型的空指针。

④把任何类型的表达式转换成void类型。

注意：static_cast不能转换掉expression的const、volitale、或者__unaligned属性。

2、const_cast

用法：const_cast<type_id>(expression)

该运算符用来修改类型的const或volatile属性。除了const 或volatile修饰之外，type_id和expression的类型是一样的。常量指针被转化成非常量指针，并且仍然指向原来的对象；常量引用被转 换成非常量引用，并且仍然指向原来的对象；常量对象被转换成非常量对象。

3、dynamic_cast

用法：dynamic_cast<type-id>(expression)

该运算符把expression转换成type-id类型的对象。Type-id必须是类的指针、类的引用或者void *；如果type-id是类指针类型，那么expression也必须是一个指针，如果type-id是一个引用，那么expression也必须是一个 引用。

dynamic_cast主要用于类层次间的上行转换和下行转换，还可以用于类之间的交叉转换。在类层次间进行上行转换 时，dynamic_cast和static_cast的效果是一样的；在进行下行转换时，dynamic_cast具有类型检查的功能，比 static_cast更安全。

4、reinterpret_cast

用法：reinterpret_cast<type-id>(expression)

reinterpret_cast是C++里的强制类型转换符。操作符修改了操作数类型，但仅仅是重新解释了给出的对象的比特模型而没有进行二进制转换。

使用注意：

1、static_cast转换的类型有限制，例如不能把int转成指针等。static_cast不能从表达式中去除const、volatile等属性。进行下行转换（把基类指针或引用转换成子类表示）时，由于没有动态类型检查，所以是不安全的。

2、const_cast只用来修改类型的const或volatile属性。

3、dynamic_cast主要用于类层次间的上行转换和下行转换，还可以用于类之间的交叉转换。有类型检查，失败的转换将返回空指针（当对指针进行类型转换时）或者抛出异常（当对引用进行类型转换时）。

4、reinterpret_cast不进行任何意义的二进制转换。reinterpret_cast只能在指针之间转换。

模板

       模板(template)是一个将数据类型参化的工具,它提供了一种将代码与数据类相脱离的机制,即代码不受具体的数据类型的影响。模板分为函数模板和类模板两种。

      (1)函数模板

      函数模板是一种不说明某些参数的数据类型的函数。例如，下面定义了一个可对任何类型变量进行操作（求绝对值）的函数模板。

 template <class T> //或写成:template <typename T>
T abs(T val)
{
return val<0 ? -val : val;
}

   在函数模板被调用时，编译器根据实际参数的类型确定模板参数T的类型，并自动生成一个对应的函数，即模板函数。模板参数的类型不同，生成的模板函数也不同。

     例 1 函数模板的定义和使用

#include <iostream.h>
template <class T>			//定义模板
T abs(T val)				//定义函数模板
{
return val<0 ? -val : val;
}
void main()
{
int i=100;
cout <<abs(i)<<endl;	//类型参数T替换为int
long l=-12345L;
cout <<abs(l)<<endl;	//类型参数T替换为long
float f=-125.78F;
cout <<abs(f)<<endl;	//类型参数T替换为float
}

     定义函数模板时也可以使用多个类型参数，这时每个类型参数前面都要加上关键字class或typename，其间用逗分隔，其形式如下所示。

      template <class T1,class T2,class T3>

     例 2 使用多个类型参数的函数模板

#include <iostream.h>
template <class T1,class T2>
T1 Max(T1 x,T2 y)
{
return x>y ? x: (T1)y;
}
void main()
{
int i=100;
float f=-125.78F;
cout <<Max(i,f)<<endl;			//类型参数T1替换为int,T2替换为float
}

   (2)类模板

         使用多个类型参数的类模板

#include <iostream.h>
template <class T1,class T2>			//使用2个类型参数
class MyTemClass						//定义类模板
{
private:
T1 x;
T2 y;
public:
MyTemClass(T1 a,T2 b) { x=a;y=b; }	//构造函数
void ShowMax()						//输出最大的数据成员
{
cout <<"MaxMember="<<(x>y?x:y)<<endl;
}
};
void main()
{
int a=100;
float b=123.45F;
MyTemClass<int,float> mt(a,b);	//声明类模板的对象
mt.ShowMax();
}

[zz]http://itrock.blog.ccidnet.com/blog-htm-do-showone-uid-255426-type-blog-itemid-717920.html

前几日用C编写DSP程序时，遇到一个问题：如何向C函数中传递指向二维数组的指针参数。初 接触以为很简单，直接声明一个二维数组，然后把数组名传进去。但是一经编译便报错。后来仔细想了一下，并查找了一些相关资料，发现二维数组在概念上远比一 维数组复杂，或者说二维数组以一种晦涩的方式构建在一维数组之上。

先来回顾一下一维数组。一维数组的数组名即为指向该数组的指针，该指针值保存了数组存放在内 存中的一块连续区域的起始地址；数组的下标表示了这片内存区域的某存储区相对于起始地址的偏移量。简单来讲就是：指向一维数组的指针，指向数据存放区域的 起始位置。

事实上，计算机系统的多维数组其实最终还是以一维数组的形式实现的。就N x M的二维数组来讲，设其数组名为array。指针array指向一个数组，该数组存放的是一系列指针，这些指针分别指向相应的一维数组，而这些数组中存放 的才是我们的数据。

array -> [一维数组指针1] ->   [ 一维数组，M长]

    [一维数组指针2] ->   [ 一维数组，M长]

        ……           ……

    [一维数组指针N] ->   [ 一维数组，M长]

由此array是第i个指针变量地址，array[j]则表示相对于第i个指针变量偏移 j*sizeof(数组类型)。系统通过这种机制访问了该二维数组的第i行，第j列的内容。

有上述可知，指向二维数组的指针其实是指向“指针变量地址”的指针变量。所以在声明指向二维 数组的指针时，用 int ** array的形式。

    有以下两种方式来对二维数组分配内存：

///// 方法一

    #include <stdlib.h>   // 必须包含该头文件，里面定义了malloc的实现

    int ** array = malloc( N * sizeof(int *) );

    for (int k=0;k<N;k++)

      array[k] = malloc( M * sizeof(int) );  

///// 方法二

    #include <stdlib.h>

    int ** array = malloc( N * sizeof(int *) );

    array[0] = malloc( M * sizeof(int) );

    for (int k=1;k<N;k++)

      array[k] = array[0]+M*k;

    上述两种方法的区别在于：前者在内存中分配的区域有可能是不连续的；而后者则在内存中的一片连续区域为该数组分配空间。

    我们还可以通过一维数组模拟二维数组。在这中间要进行下标转换。如对于模拟的NxM数组，访问其第i行，第j列元素时，在一维数组中对应的位置是 i*M+j。当然为了更简捷，我们可以把这个数组下标转换过程定义为一个宏，交由编译系统来处理。

    #define Arr2 ( array_name, row,col )   array_name[row*M+col]

    定义该宏后，访问Arr2( array, i, j)等价于访问 array[i*M+j]。

pthread_kill：

别被名字吓到，pthread_kill可不是kill，而是向线程发送signal。还记得signal吗，大部分signal的默认动作是终止进程的运行，所以，我们才要用signal()去抓信号并加上处理函数。

int pthread_kill(pthread_t thread, int sig);

向指定ID的线程发送sig信号，如果线程代码内不做处理，则按照信号默认的行为影响整个进程，也就是说，如果你给一个线程发送了SIGQUIT，但线程却没有实现signal处理函数，则整个进程退出。

pthread_kill(threadid, SIGKILL)也一样，杀死整个进程。
如果要获得正确的行为，就需要在线程内实现signal(SIGKILL,sig_handler)了。

所以，如果int sig的参数不是0，那一定要清楚到底要干什么，而且一定要实现线程的信号处理函数，否则，就会影响整个进程。

OK，如果int sig是0呢，这是一个保留信号，一个作用是用来判断线程是不是还活着。

我们来看一下pthread_kill的返回值：
成功:0
线程不存在：ESRCH
信号不合法：EINVAL

所以，pthread_kill(threadid,0)就很有用啦。

int kill_rc = pthread_kill(thread_id,0);

if(kill_rc == ESRCH)
printf("the specified thread did not exists or already quit\n");
else if(kill_rc == EINVAL)
printf("signal is invalid\n");
else
printf("the specified thread is alive\n");

上述的代码就可以判断线程是不是还活着了。

本文中我们针对 Linux 上多线程编程的主要特性总结出 5 条经验，用以改善 Linux 多线程编程的习惯和避免其中的开发陷阱。在本文中，我们穿插一些 Windows 的编程用例用以对比 Linux 特性，以加深读者印象。

背景

Linux 平台上的多线程程序开发相对应其他平台（比如 Windows）的多线程 API 有一些细微和隐晦的差别。不注意这些 Linux 上的一些开发陷阱，常常会导致程序问题不穷，死锁不断。本文中我们从 5 个方面总结出 Linux 多线程编程上的问题，并分别引出相关改善的开发经验，用以避免这些的陷阱。我们希望这些经验可以帮助读者们能更好更快的熟悉 Linux 平台的多线程编程。

我们假设读者都已经很熟悉 Linux 平台上基本的线程编程的 Pthread 库 API 。其他的第三方用以线程编程的库，如 boost，将不会在本文中提及。本文中主要涉及的题材包括线程开发中的线程管理，互斥变量，条件变量等。进程概念将不会在本文中涉及。

回页首

Linux 上线程开发 API 的概要介绍

多线程开发在 Linux 平台上已经有成熟的 Pthread 库支持。其涉及的多线程开发的最基本概念主要包含三点：线程，互斥锁，条件。其中，线程操作又分线程的创建，退出，等待 3 种。互斥锁则包括 4 种操作，分别是创建，销毁，加锁和解锁。条件操作有 5 种操作：创建，销毁，触发，广播和等待。其他的一些线程扩展概念，如信号灯等，都可以通过上面的三个基本元素的基本操作封装出来。

线程，互斥锁，条件在 Linux 平台上对应的 API 可以用表 1 归纳。为了方便熟悉 Windows 线程编程的读者熟悉 Linux 多线程开发的 API，我们在表中同时也列出 Windows SDK 库中所对应的 API 名称。

多线程开发在 Linux 平台上已经有成熟的 Pthread 库支持。其涉及的多线程开发的最基本概念主要包含三点：线程，互斥锁，条件。其中，线程操作又分线程的创建，退出，等待 3 种。互斥锁则包括 4 种操作，分别是创建，销毁，加锁和解锁。条件操作有 5 种操作：创建，销毁，触发，广播和等待。其他的一些线程扩展概念，如信号灯等，都可以通过上面的三个基本元素的基本操作封装出来。

回页首

Linux 线程编程中的 5 条经验

尽量设置 recursive 属性以初始化 Linux 的互斥变量

互斥锁是多线程编程中基本的概念，在开发中被广泛使用。其调用次序层次清晰简单：建锁，加锁，解锁，销毁锁。但是需要注意的是，与诸如 Windows 平台的互斥变量不同，在默认情况下，Linux 下的同一线程无法对同一互斥锁进行递归加速，否则将发生死锁。

所谓递归加锁，就是在同一线程中试图对互斥锁进行两次或两次以上的行为。其场景在 Linux 平台上的代码可由清单 1 所示。

// 通过默认条件建锁
    pthread_mutex_t *theMutex = new pthread_mutex_t; 
    pthread_mutexattr_t attr; 
    pthread_mutexattr_init(&attr); 
    pthread_mutex_init(theMutex,&attr); 
    pthread_mutexattr_destroy(&attr); 

    // 递归加锁
    pthread_mutex_lock (theMutex); 
    pthread_mutex_lock (theMutex); 
    pthread_mutex_unlock (theMutex); 
    pthread_mutex_unlock (theMutex);

在以上代码场景中，问题将出现在第二次加锁操作。由于在默认情况下，Linux 不允许同一线程递归加锁，因此在第二次加锁操作时线程将出现死锁。

Linux 互斥变量这种奇怪的行为或许对于特定的某些场景会所有用处，但是对于大多数情况下看起来更像是程序的一个 bug 。毕竟，在同一线程中对同一互斥锁进行递归加锁在尤其是二次开发中经常会需要。

这个问题与互斥锁的中的默认 recursive 属性有关。解决问题的方法就是显式地在互斥变量初始化时将设置起 recursive 属性。基于此，以上代码其实稍作修改就可以很好的运行，只需要在初始化锁的时候加设置一个属性。请看清单 2 。

pthread_mutexattr_init(&attr); 
    // 设置 recursive 属性
    pthread_mutexattr_settype(&attr,PTHREAD_MUTEX_RECURSIVE_NP); 
    pthread_mutex_init(theMutex,&attr);

因此，建议尽量设置 recursive 属性以初始化 Linux 的互斥锁，这样既可以解决同一线程递归加锁的问题，又可以避免很多情况下死锁的发生。这样做还有一个额外的好处，就是可以让 Windows 和 Linux 下让锁的表现统一。

注意 Linux 平台上触发条件变量的自动复位问题

条件变量的置位和复位有两种常用模型：第一种模型是当条件变量置位（signaled）以后，如果当前没有线程在等待，其状态会保持为置位 （signaled），直到有等待的线程进入被触发，其状态才会变为复位（unsignaled），这种模型的采用以 Windows 平台上的 Auto-set Event 为代表。其状态变化如图 1 所示：

第二种模型则是 Linux 平台的 Pthread 所采用的模型，当条件变量置位（signaled）以后，即使当前没有任何线程在等待，其状态也会恢复为复位（unsignaled）状态。其状态变化如图 2 所示：

具体来说，Linux 平台上 Pthread 下的条件变量状态变化模型是这样工作的：调用 pthread_cond_signal() 释放被条件阻塞的线程时，无论存不存在被阻塞的线程，条件都将被重新复位，下一个被条件阻塞的线程将不受影响。而对于 Windows，当调用 SetEvent 触发 Auto-reset 的 Event 条件时，如果没有被条件阻塞的线程，那么条件将维持在触发状态，直到有新的线程被条件阻塞并被释放为止。

这种差异性对于那些熟悉 Windows 平台上的条件变量状态模型而要开发 Linux 平台上多线程的程序员来说可能会造成意想不到的尴尬结果。试想要实现一个旅客坐出租车的程序：旅客在路边等出租车，调用条件等待。出租车来了，将触发条 件，旅客停止等待并上车。一个出租车只能搭载一波乘客，于是我们使用单一触发的条件变量。这个实现逻辑在第一个模型下即使出租车先到，也不会有什么问题， 其过程如图 3 所示：

然而如果按照这个思路来在 Linux 上来实现，代码看起来可能是清单 3 这样。

……
 // 提示出租车到达的条件变量
 pthread_cond_t taxiCond; 

 // 同步锁
 pthread_mutex_t taxiMutex; 

 // 旅客到达等待出租车
 void * traveler_arrive(void * name) { 
    cout<< ” Traveler: ” <<(char *)name<< ” needs a taxi now! ” <<endl; 
    pthread_mutex_lock(&taxiMutex); 
    pthread_cond_wait (&taxiCond, &taxtMutex); 
    pthread_mutex_unlock (&taxtMutex); 
    cout<< ” Traveler: ” << (char *)name << ” now got a taxi! ” <<endl; 
    pthread_exit( (void *)0 ); 
 } 

 // 出租车到达
 void * taxi_arrive(void *name) { 
    cout<< ” Taxi ” <<(char *)name<< ” arrives. ” <<endl; 
    pthread_cond_signal(&taxtCond); 
    pthread_exit( (void *)0 ); 
 } 

 void main() {  
    // 初始化
    taxtCond= PTHREAD_COND_INITIALIZER; 
    taxtMutex= PTHREAD_MUTEX_INITIALIZER; 
    pthread_t thread; 
    pthread_attr_t threadAttr; 
    pthread_attr_init(&threadAttr); 

    pthread_create(&thread, & threadAttr, taxt_arrive, (void *)( ” Jack ” )); 
    sleep(1); 
    pthread_create(&thread, &threadAttr, traveler_arrive, (void *)( ” Susan ” )); 
    sleep(1); 
    pthread_create(&thread, &threadAttr, taxi_arrive, (void *)( ” Mike ” )); 
    sleep(1); 

    return 0; 
 }

好的，运行一下，看看结果如清单 4 。

Taxi Jack arrives. 
    Traveler Susan needs a taxi now! 
    Taxi Mike arrives. 
    Traveler Susan now got a taxi.

其过程如图 4 所示：

通过对比结果，你会发现同样的逻辑，在 Linux 平台上运行的结果却完全是两样。对于在 Windows 平台上的模型一， Jack 开着出租车到了站台，触发条件变量。如果没顾客，条件变量将维持触发状态，也就是说 Jack 停下车在那里等着。直到 Susan 小姐来了站台，执行等待条件来找出租车。 Susan 搭上 Jack 的出租车离开，同时条件变量被自动复位。

但是到了 Linux 平台，问题就来了，Jack 到了站台一看没人，触发的条件变量被直接复位，于是 Jack 排在等待队列里面。来迟一秒的 Susan 小姐到了站台却看不到在那里等待的 Jack，只能等待，直到 Mike 开车赶到，重新触发条件变量，Susan 才上了 Mike 的车。这对于在排队系统前面的 Jack 是不公平的，而问题症结是在于 Linux 平台上条件变量触发的自动复位引起的一个 Bug 。

条件变量在 Linux 平台上的这种模型很难说好坏。但是在实际开发中，我们可以对代码稍加改进就可以避免这种差异的发生。由于这种差异只发生在触发没有被线程等待在条件变量的 时刻，因此我们只需要掌握好触发的时机即可。最简单的做法是增加一个计数器记录等待线程的个数，在决定触发条件变量前检查下该变量即可。改进后 Linux 函数如清单 5 所示。

……
 // 提示出租车到达的条件变量
 pthread_cond_t taxiCond; 

 // 同步锁
 pthread_mutex_t taxiMutex; 

 // 旅客人数，初始为 0 
 int travelerCount=0; 

 // 旅客到达等待出租车
 void * traveler_arrive(void * name) { 
    cout<< ” Traveler: ” <<(char *)name<< ” needs a taxi now! ” <<endl; 
    pthread_mutex_lock(&taxiMutex); 

    // 提示旅客人数增加
    travelerCount++; 
    pthread_cond_wait (&taxiCond, &taxiMutex); 
    pthread_mutex_unlock (&taxiMutex); 
    cout<< ” Traveler: ” << (char *)name << ” now got a taxi! ” <<endl; 
    pthread_exit( (void *)0 ); 
 } 

 // 出租车到达
 void * taxi_arrive(void *name) 
 { 
    cout<< ” Taxi ” <<(char *)name<< ” arrives. ” <<endl; 

 while(true) 
 { 
        pthread_mutex_lock(&taxiMutex); 

        // 当发现已经有旅客在等待时，才触发条件变量
        if(travelerCount>0) 
        { 
            pthread_cond_signal(&taxtCond); 
            pthread_mutex_unlock (&taxiMutex); 
            break; 
        } 
        pthread_mutex_unlock (&taxiMutex); 
    } 

    pthread_exit( (void *)0 ); 
 }

因此我们建议在 Linux 平台上要出发条件变量之前要检查是否有等待的线程，只有当有线程在等待时才对条件变量进行触发。

注意条件返回时互斥锁的解锁问题

在 Linux 调用 pthread_cond_wait 进行条件变量等待操作时，我们增加一个互斥变量参数是必要的，这是为了避免线程间的竞争和饥饿情况。但是当条件等待返回时候，需要注意的是一定不要遗漏对互斥变量进行解锁。

Linux 平台上的 pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex) 函数返回时，互斥锁 mutex 将处于锁定状态。因此之后如果需要对临界区数据进行重新访问，则没有必要对 mutex 就行重新加锁。但是，随之而来的问题是，每次条件等待以后需要加入一步手动的解锁操作。正如前文中乘客等待出租车的 Linux 代码如清单 6 所示：

void * traveler_arrive(void * name) { 
    cout<< ” Traveler: ” <<(char *)name<< ” needs a taxi now! ” <<endl; 
    pthread_mutex_lock(&taxiMutex); 
    pthread_cond_wait (&taxiCond, &taxtMutex); 
    pthread_mutex_unlock (&taxtMutex); 
    cout<< ” Traveler: ” << (char *)name << ” now got a taxi! ” <<endl; 
    pthread_exit( (void *)0 ); 
 }

这一点对于熟悉 Windows 平台多线程开发的开发者来说尤为重要。 Windows 上的 SignalObjectAndWait() 函数是常与 Linux 平台上的 pthread_cond_wait() 函数被看作是跨平台编程时的一对等价函数。但是需要注意的是，两个函数退出时的状态是不一样的。在 Windows 平台上，SignalObjectAndWait(HANDLE a, HANDLE b, …… ) 方法在调用结束返回时的状态是 a 和 b 都是置位（signaled）状态，在普遍的使用方法中，a 经常是一个 Mutex 变量，在这种情况下，当返回时，Mutex a 处于解锁状态（signaled），Event b 处于置位状态（signaled）, 因此，对于 Mutex a 而言，我们不需要考虑解锁的问题。而且，在 SignalObjectAndWait() 之后，如果需要对临界区数据进行重新访问，都需要调用 WaitForSingleObject() 重新加锁。这一点刚好与 Linux 下的 pthread_cond_wait() 完全相反。

Linux 对于 Windows 的这一点额外解锁的操作区别很重要，一定得牢记。否则从 Windows 移植到 Linux 上的条件等待操作一旦忘了结束后的解锁操作，程序将肯定会发生死锁。

等待的绝对时间问题

超时是多线程编程中一个常见的概念。例如，当你在 Linux 平台下使用 pthread_cond_timedwait() 时就需要指定超时这个参数，以便这个 API 的调用者最多只被阻塞指定的时间间隔。但是如果你是第一次使用这个 API 时，首先你需要了解的就是这个 API 当中超时参数的特殊性（就如本节标题所提示的那样）。我们首先来看一下这个 API 的定义。 pthread_cond_timedwait() 定义请看清单 7 。

int pthread_cond_timedwait(pthread_cond_t *restrict cond, 
              pthread_mutex_t *restrict mutex, 
              const struct timespec *restrict abstime);

参数 abstime 在这里用来表示和超时时间相关的一个参数，但是需要注意的是它所表示的是一个绝对时间，而不是一个时间间隔数值，只有当系统的当前时间达到或者超过 abstime 所表示的时间时，才会触发超时事件。这对于拥有 Windows 平台线程开发经验的人来说可能尤为困惑。因为 Windows 平台下所有的 API 等待参数（如 SignalObjectAndWait，等）都是相对时间，

假设我们指定相对的超时时间参数如 dwMilliseconds （单位毫秒）来调用和超时相关的函数，这样就需要将 dwMilliseconds 转化为 Linux 下的绝对时间参数 abstime 使用。常用的转换方法如清单 8 所示：

/* get the current time */ 
    struct timeval now; 
    gettimeofday(&now, NULL); 
	
    /* add the offset to get timeout value */ 
    abstime ->tv_nsec = now.tv_usec * 1000 + (dwMilliseconds % 1000) * 1000000; 
    abstime ->tv_sec = now.tv_sec + dwMilliseconds / 1000;

Linux 的绝对时间看似简单明了，却是开发中一个非常隐晦的陷阱。而且一旦你忘了时间转换，可以想象，等待你的错误将是多么的令人头疼：如果忘了把相对时间转换成 绝对时间，相当于你告诉系统你所等待的超时时间是过去式的 1970 年 1 月 1 号某个时间段，于是操作系统毫不犹豫马上送给你一个 timeout 的返回值，然后你会举着拳头抱怨为什么另外一个同步线程耗时居然如此之久，并一头扎进寻找耗时原因的深渊里。

正确处理 Linux 平台下的线程结束问题

在 Linux 平台下，当处理线程结束时需要注意的一个问题就是如何让一个线程善始善终，让其所占资源得到正确释放。在 Linux 平台默认情况下，虽然各个线程之间是相互独立的，一个线程的终止不会去通知或影响其他的线程。但是已经终止的线程的资源并不会随着线程的终止而得到释放， 我们需要调用 pthread_join() 来获得另一个线程的终止状态并且释放该线程所占的资源。 Pthread_join() 函数的定义如清单 9 。

int pthread_join(pthread_t th, void **thread_return);

调用该函数的线程将挂起，等待 th 所表示的线程的结束。 thread_return 是指向线程 th 返回值的指针。需要注意的是 th 所表示的线程必须是 joinable 的，即处于非 detached（游离）状态；并且只可以有唯一的一个线程对 th 调用 pthread_join() 。如果 th 处于 detached 状态，那么对 th 的 pthread_join() 调用将返回错误。

如果你压根儿不关心一个线程的结束状态，那么也可以将一个线程设置为 detached 状态，从而来让操作系统在该线程结束时来回收它所占的资源。将一个线程设置为 detached 状态可以通过两种方式来实现。一种是调用 pthread_detach() 函数，可以将线程 th 设置为 detached 状态。其申明如清单 10 。

int pthread_detach(pthread_t th);

另一种方法是在创建线程时就将它设置为 detached 状态，首先初始化一个线程属性变量，然后将其设置为 detached 状态，最后将它作为参数传入线程创建函数 pthread_create()，这样所创建出来的线程就直接处于 detached 状态。方法如清单 11 。

………………………………… .. 
    pthread_t       tid; 
    pthread_attr_t  attr; 
    pthread_attr_init(&attr); 
    pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED); 
    pthread_create(&tid, &attr, THREAD_FUNCTION, arg);

总之为了在使用 Pthread 时避免线程的资源在线程结束时不能得到正确释放，从而避免产生潜在的内存泄漏问题，在对待线程结束时，要确保该线程处于 detached 状态，否着就需要调用 pthread_join() 函数来对其进行资源回收。

回页首

总结与补充

本文以上部分详细介绍了 Linux 的多线程编程的 5 条高效开发经验。另外你也可以考虑尝试其他一些开源类库来进行线程开发。

1. Boost 库

Boost 库来自于由 C++ 标准委员会类库工作组成员发起，致力于为 C++ 开发新的类库的 Boost 组织。虽然该库本身并不是针对多线程而产生，但是发展至今，其已提供了比较全面的多线程编程的 API 支持。 Boost 库对于多线程支持的 API 风格上更类似于 Linux 的 Pthread 库，差别在于其将线程，互斥锁，条件等线程开发概念都封装成了 C++ 类，以方便开发调用。 Boost 库目前对跨平台支持的很不错，不仅支持 Windows 和 Linux ，还支持各种商用的 Unix 版本。如果开发者想使用高稳定性的统一线程编程接口减轻跨平台开发的难度， Boost 库将是首选。

2. ACE

ACE 全称是 ADAPTIVE Communication Environment，它是一个免费的，开源的，面向对象的工具框架，用以开发并发访问的软件。由于 ACE 最初是面向网络服务端的编程开发，因此对于线程开发的工具库它也能提供很全面的支持。其支持的平台也很全面，包括 Windows，Linux 和各种版本 Unix 。 ACE 的唯一问题是如果仅仅是用于线程编程，其似乎显得有些过于重量级。而且其较复杂的配置也让其部署对初学者而言并非易事。

2.6 调试

% gdb progname

M-x gdb RET progname RET

... (no debugging symbols found) ...

#include <stdio.h>

int bazz(int anint);

main() {
    int i;

    printf("This is my program\n");
    bazz(i);
    return 0;
}

int bazz(int anint) {
    printf("You gave me %d\n", anint);
    return anint;
}

% cc -g -o temp temp.c
% ./temp
This is my program
anint = 4231

% gdb temp
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.13 (i386-unknown-freebsd), Copyright 1994 Free Software Foundation, Inc.
(gdb) break main               Skip the set-up code
Breakpoint 1 at 0x160f: file temp.c, line 9.    gdb puts breakpoint at main()
(gdb) run                   Run as far as main()
Starting program: /home/james/tmp/temp      Program starts running

Breakpoint 1, main () at temp.c:9       gdb stops at main()
(gdb) n                       Go to next line
This is my program              Program prints out
(gdb) s                       step into bazz()
bazz (anint=4231) at temp.c:17          gdb displays stack frame
(gdb)

(gdb) up                   Move up call stack
#1  0x1625 in main () at temp.c:11      gdb displays stack frame
(gdb) p i                   Show us the value of i
$1 = 4231                   gdb displays 4231

...
main() {
    int i;

    i = 5;
    printf("This is my program\n");
...

(gdb) core progname.core

% gdb a.out
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.13 (i386-unknown-freebsd), Copyright 1994 Free Software Foundation, Inc.
(gdb) core a.out.core
Core was generated by `a.out'.
Program terminated with signal 11, Segmentation fault.
Cannot access memory at address 0x7020796d.
#0  0x164a in bazz (anint=0x5) at temp.c:17
(gdb)

(gdb) bt
#0  0x164a in bazz (anint=0x5) at temp.c:17
#1  0xefbfd888 in end ()
#2  0x162c in main () at temp.c:11
(gdb)

(gdb) attach pid

...
if ((pid = fork()) < 0)      /* _Always_ check this */
    error();
else if (pid == 0) {        /* child */
    int PauseMode = 1;

    while (PauseMode)
        sleep(10);  /* Wait until someone attaches to us */
    ...
} else {            /* parent */
    ...

1、GDB对于基于GNU系统开发的程序员来说是最基本的东西，必须的。所以这篇学习总结中，不打算包括GDB的一般使用方法。因为这些东西必须是随手拈来的。所以也就不花时间来整理，我只把一些比较高级的应用在这里作一个整理。
 
2、在编译链接程序时需要使用"-ggdb"选项来生成可供GDB调试用的信息，否则GDB将失去作用，因此GDB和GCC联系的非常紧密。并且当-g和-O开关同时打开时，调试和优化可能会产生冲突，经常会发现所见和事实不合的情况，所以要选择性地开启优化开关。
 
3、GDB的一些使用技巧：
 1）设置断点的方法包括：函数，行号，if条件断点express，这些前面都可以跟上文件名。另外还可以设置地址断点：b *0x8048424.
 2）GDB用来分析core文件，启动格式：gdb debugme core.xyz
 3）开启core文件生成的方法是: ulimit -c unlimited
 4）在不同函数的调用栈上切换及查看当前信息：bt/frame XX/up/down/info frame/args/locals
 5）调试一正运行的进程：gdb debugme pid或者gdb debugme + attach pid + detach，类似的应用还有：strace/ltrace/truss
 6）如果某个线程/进程处于死锁状态，还可以通过gcore pid来手动生成core文件来分析当前线程/进程的状态，然后利用GDB来分析, gcore使用方法：gcore pid，注意被调试的进程会临时性停止去生成core文件
 7）查看函数的反汇编指令：disassemble fun_name
 8）汇编指令级别的单步执行：ni/si,显示当前执行的汇编指令： x/i $pc
 9）查看寄存器的内容：info registers/all-registers
 10）查看某地址开始的内容：x/num 0xYYYYYYY 查看从0xYYYYYYY开始的num个单元内容；p 输出数组内容
 11）在函数调试中途强制返回：return  <expression>;
 12）向被调试程序发送指定信号：在任意一点ctrl+C进入gdb调试命令行，然后：signal 1-15
 
4、用GDB来调试多线程程序：
 1）显示当前可调试的所有线程：info threads，GDB按照线程启动顺序重新安排了一个线程ID，这个ID是供GDB使用的
 2）在调试多线程的程序时，默认调试的是主线程，其他线程也同时处于暂停状态，如果想切换调试其他的线程，则只需要:thread id
 3）在对某一线程进行next/step执行的时候，其他线程也同时在执行，如果要限制其他线程执行，则可以使用：set scheduler-locking on
 4）对指定线程或者所有线程执行同样的操作，比如查看调用栈信息：thread apply ID1 ID2/all bt
 5）另外你也可以利用strace -p pid来显示某个线程当前的系统调用情况。或者利用gdb debugme pid来调试某个线程，但注意该方法会暂停整个进程的执行。对于多线程的程序gdb ./debugme相当于默认调试主线程，而gdb ./debugme pid则相当于默认调试pid线程。
 
5、用GDB来调试多进程程序：
 1）当fork子进程后，继续调试父进程或者调试刚产生的子进程：set follow-fork-mode parent/child，注意调试的时候其他的进程仍然在运行。
 2）如果父进程fork了多个子进程，上面的这种方法也只能跟踪调试到第一个子进程，并且不影响其他子进程的运行。
 3）如果想在调试一个进程的时候，其他进程处于暂停状态，则可以利用：set detach-on-fork off来做到
 4）利用attach来调试子进程。因为父进程fork子进程后，子进程会马上得到执行，如果恰好执行过了你要调试的地方，则来不及查询pid并且attach，所以为了支持直接attach调试，一般会在子进程的代码开始处加上一个sleep，以使得你有时间来查询pid，然后attach进入来调试。
   attach pid + stop + break XXX + continue + n + n ...+ s + s + ....
 5）利用gdb ./debugme pid都可以用来调试进程和线程，但不同的是GDB控制的范围不一样，前者不影响其他的并行单元（进程），而后则会使真个进程暂停。 
 
6、调试动态链接库函数：
 我们可能要调试动态库的函数，或者通过调试来学习动态库函数的实现。这个时候，则需要GDB包括该动态库的debug版本，否则在GDB下面只会打印:0xXXXXXX: ??
 比如包括：glibc debug version，如下是一些glibc的debug版本的下载地址：
 http://linux.maruhn.com/sec/glibc-debug.html
 
注：GDB的远端调试功能，暂时还没有接触过，现不做学习和总结.
 GDB对于多线程，多进程的调试支持并不强大，但可以利用其他专用调试器，比如TotalView：
 参考地址：http://www.totalviewtech.com/
         http://www.total-view.com.cn/
    
   
7、一些辅助的诊断及调试工具：
 1）strace：跟踪系统调用情况
 2）ltrace：跟踪动态库的调用情况
 3）mtrace，pmalloc：跟踪内存使用情况，需要嵌入代码，打印内存使用记录。
 4）Binuitls：Toolchain的工具，参考我的上一篇总结。
 5）Valgrind：非常好的内存泄露检测工具，限于i386
 6）oprofile， NPTL Trace Tool等
 7）ald：汇编语言调试器
 8）Dude：另一个运行linux上的调试器，未使用ptrace实现
 9）Linice（http://www.linice.com/）是SoftIce在Linux中的模拟软件，用于调试没有源代码的二进制文件的内核级调试器。
 10）其他
关于调试及诊断工具包括许多，估计可以写一系列的文章来说明。

其他参考资料：
0）GDB官方网站：http://www.gnu.org/software/gdb/gdb.html
1）快速参考GDB支持的所有调试命令：《GDB QUICK REFERENCE》
2）GDB的使用手册：《Debugging with gdb--The gnu Source-Level Debugger》
3）《Embedded linux prime》的第13/14/15章可以作为参考。
http://book.opensourceproject.org.cn/embedded/embeddedprime/index.html?page=opensource/0136130550/ch13lev1sec1.html
文章出处：飞诺网(www.firnow.com):http://dev.firnow.com/course/6_system/linux/Linuxjs/20091209/184488.html

***********************************************************************************************

1、GDB基本组成：
   GDB由三个部分组成：
 （1）用户接口user interface，除支持传统的CLI接口还支持mi接口（ddd等工具使用）
 （2）符号处理层symbol handling，当gdb ./debugme后GDB会读取文件的符号信息，之后的原代码，变量/函数/类型的显示都由该部分进行(everything you can do without live process)。
 （3）目标系统处理层target system handling。包括执行控制，断点设置，单步执行，堆栈分析等操作都有该部分来进行。
 
2、GDB各部分的实现：
 （1）用户接口层(CLI)的实现很显然要用到readline/history库，而图形界面mi则需要用到:GNU ncurses库。
   参考资料： http://www.gnu.org/software/ncurses/
          http://tiswww.case.edu/php/chet/readline/rltop.html
         
 （2）符号处理层则需要使用到：BFD/Opcodes库，分别用来读取分析ELF/Core文件，反汇编.
  参考资料： http://www.xfocus.net/articles/200109/265.html
     http://sourceware.org/binutils/docs/bfd/index.html#Top
     http://www.linuxselfhelp.com/gnu/bfd/html_chapter/bfd_toc.html
    
 （3）目标系统控制层：用ptrace系统调用来实现对其他进程的执行控制，检查和改变其核心映像以及寄存器等操作。
 
  
3、后端（目标系统控制层）实现：
 （1）内核在执行用户请求的系统调用之前回检查当前进程是否处于被“跟踪”状态，如果是的话内核暂停当前进程并将控制权交给调试进程，使跟踪调试进程可以查看甚至修改被调试进程的内存，寄存器等数据。而ptrace函数的作用就是告诉内核在执行子进程的系统调用之前做的动作。所有的动作都可以通过request进行传入。
 （2）设置断点原理：通过查找输入的断点和具体代码位置对应起来，并在该位置替换为一条断点指令，并且保存以前的指令，到目标程序运行到该断点处时，产生SIGTRAP信号，该信号被GDB捕获，GDB查找断点列表来确定是否命中断点。继续执行的时候则会把保存的指令重新放回并执行。n/s/ni/si/finish/uitil也会自动设置断点。
 （3）内核传递给被调试进程所有的信号，都会先传递给GDB再由gdb采取定义的动作来和被调试进程之间进行相互协调操作。gdb暂停目标程序运行的方法是向其发送SIGSTOP信号，GDB对于随机信号（非GDB产生的）的处理包括，可以通过handle signals命令来预定义
 
4、 ptrace函数简单介绍：long ptrace(enum __ptrace_request request, pid_t pid, void *addr, void *data);其中第一个参数代表告诉给kernel要做的动作。
 PTRACE_ME：设置自己的被跟踪标志，在被调试进程中使用。
 PTRACE_PEEKUSER：可以得到系统调用号及参数信息
 PTRACE_CONT：使被跟踪进程继续执行
 PRACE_GETREGS：一次性得到所有寄存器相关的值，提供输出参数
 PTRACE_POKEDATA：可用来改变子进程中变量的值
 PTRACE_SINGLESTEP：会使内核在子进程的每一条指令执行前先将其阻塞，然后将控制权交给父进程
 PTRACE_ATTACH：向运行着的子进程置上跟踪标志为。
 PTRACE_DETACH：和上面的行为相反。
很多工具strace/ltrace/stuss等工具都用到了ptrace，学习ptrace的最好的资料是这些工具的原代码和kernel相关代码。
 
其他参考资料：
1）Ptrace相关资料: http://linuxgazette.net/issue81/sandeep.html
       http://blog.chinaunix.net/u/19651/showart_362901.html //玩转ptrace系列
       http://blog.chinaunix.net/u/19651/showart_362921.html
      
2）GDB的实现说明： 《gdb Internals》 

内存分配 知识,全局，局部，静态变量

预备知识—程序的内存分配 
一个由C/C++编译的程序占用的内存分为以下几个部分 
1、栈区（stack）— 由编译器自动分配释放 ，存放函数的参数值，局部变量的值等。其操作方式类似于数据结构中的栈。 
2、堆区（heap） — 一般由程序员分配释放， 若程序员不释放，程序结束时可能由OS回收 。注意它与数据结构中的堆是两回事，分配方式倒是类似于链表，呵呵。
3、全局区（静态区）（static）—，全局变量和静态变量的存储是放在一块的，初始化的全局变量和静态变量在一块区域， 未初始化的全局变量和未初始化的静态变量在相邻的另一块区域。 - 程序结束后有系统释放 
4、文字常量区 —常量字符串就是放在这里的。 程序结束后由系统释放 
5、程序代码区—存放函数体的二进制代码。

一个正常的程序在内存中通常分为程序段，数据端和堆栈三部分。程序段里放着程序的机器码和只读数据，这个段通常是只读，对它的写操作是非法的。数据段放的是程序中的静态数据。动态数据则通过堆栈来存放。在内存中，它们的位置如下： 
+------------------+ 内存低端 
| 程序段 | 
|------------------| 
| 数据段 | 
|------------------| 
| 堆栈 | 
+------------------+ 内存高端 
堆栈是内存中的一个连续的块。一个叫堆栈指针的寄存器（SP）指向堆栈的栈顶。堆栈的底部是一个固定地址。堆栈有一个特点就是，后进先出。也就是说，后放入的数据第一个取出。它支持两个操作，PUSH和POP。PUSH是将数据放到栈的顶端，POP是将栈顶的数据取出。
在高级语言中，程序函数调用和函数中的临时变量都用到堆栈。为什么呢？因为在调用一个函数时，我们需要对当前的操作进行保护，也为了函数执行后，程序可以正确的找到地方继续执行，所以参数的传递和返回值也用到了堆栈。通常对局部变量的引用是通过给出它们对SP的偏移量来实现的。另外还有一个基址指针（FP，在Intel芯片中是BP），许多编译器实际上是用它来引用本地变量和参数的。通常，参数的相对FP的偏移是正的，局部变量是负的。 
当程序中发生函数调用时，计算机做如下操作：首先把参数压入堆栈；然后保存指令寄存器(IP)中的内容，做为返回地址(RET)；第三个放入堆栈的是基址寄存器(FP)；然后把当前的栈指针(SP)拷贝到FP，做为新的基地址；最后为本地变量留出一定空间，把SP减去适当的数值。 

在函数体中定义的变量通常是在栈上，用malloc, calloc, realloc等分配内存的函数分配得到的就是在堆上。在所有函数体外定义的是全局量，加了static修饰符后不管在哪里都存放在全局区（静态区）,在所有函数体外定义的static变量表示在该文件中有效，不能extern到别的文件用，在函数体内定义的static表示只在该函数体内有效。另外，函数中的"adgfdf"这样的字符串存放在常量区。

对比：
1 性能
栈：栈存在于RAM中。栈是动态的，它的存储速度是第二快的。stack
堆：堆位于RAM中，是一个通用的内存池。所有的对象都存储在堆中。heap

2 申请方式
stack: 由系统自动分配。 例如，声明在函数中一个局部变量 int b; 系统自动在栈中为b开辟空间 
heap: 需要程序员自己申请，并指明大小，在c中malloc函数 如p1 = (char *)malloc(10); 
在C++中用new运算符 如p2 = (char *)malloc(10); 但是注意p1、p2本身是在栈中的。

3 申请后系统的响应
栈：只要栈的剩余空间大于所申请空间，系统将为程序提供内存，否则将报异常提示栈溢出。 
堆：首先应该知道操作系统有一个记录空闲内存地址的链表，当系统收到程序的申请时， 
会遍历该链表，寻找第一个空间大于所申请空间的堆结点，然后将该结点从空闲结点链表中删除，并将该结点的空间分配给程序，另外，对于大多数系统，会在这块内存空间中的首地址处记录本次分配的大小，这样，代码中的delete语句才能正确的释放本内存空间。另外，由于找到的堆结点的大小不一定正好等于申请的大小，系统会自动的将多余的那部分重新放入空闲链表中。

4 申请大小的限制
栈：在Windows下,栈是向低地址扩展的数据结构，是一块连续的内存的区域。这句话的意思是栈顶的地址和栈的最大容量是系统预先规定好的，在WINDOWS下，栈的大小是2M（也有的说是1M，总之是一个编译时就确定的常数），如果申请的空间超过栈的剩余空间时，将提示overflow。因此，能从栈获得的空间较小。 
堆：堆是向高地址扩展的数据结构，是不连续的内存区域。这是由于系统是用链表来存储的空闲内存地址的，自然是不连续的，而链表的遍历方向是由低地址向高地址。堆的大小受限于计算机系统中有效的虚拟内存。由此可见，堆获得的空间比较灵活，也比较大。

5 申请效率的比较
栈由系统自动分配，速度较快。但程序员是无法控制的。 
堆是由new分配的内存，一般速度比较慢，而且容易产生内存碎片,不过用起来最方便. 
另外，在WINDOWS下，最好的方式是用VirtualAlloc分配内存，他不是在堆，也不是在栈是直接在进程的地址空间中保留一快内存，虽然用起来最不方便。但是速度快，也最灵活。

6 堆和栈中的存储内容
栈：在函数调用时，第一个进栈的是主函数中后的下一条指令（函数调用语句的下一条可执行语句）的地址，然后是函数的各个参数，在大多数的C编译器中，参数是由右往左入栈的，然后是函数中的局部变量。注意静态变量是不入栈的。 
当本次函数调用结束后，局部变量先出栈，然后是参数，最后栈顶指针指向最开始存的地址，也就是主函数中的下一条指令，程序由该点继续运行。 
堆：一般是在堆的头部用一个字节存放堆的大小。堆中的具体内容有程序员安排。

7 存取效率的比较
char s1[] = "aaaaaaaaaaaaaaa"; 
char *s2 = "bbbbbbbbbbbbbbbbb"; 
aaaaaaaaaaa是在运行时刻赋值的； 
而bbbbbbbbbbb是在编译时就确定的； 
但是，在以后的存取中，在栈上的数组比指针所指向的字符串(例如堆)快。 
比如： 
#include 
void main() 
{ 
char a = 1; 
char c[] = "1234567890"; 
char *p ="1234567890"; 
a = c[1]; 
a = p[1]; 
return; 
} 
对应的汇编代码 
10: a = c[1]; 
00401067 8A 4D F1 mov cl,byte ptr [ebp-0Fh] 
0040106A 88 4D FC mov byte ptr [ebp-4],cl 
11: a = p[1]; 
0040106D 8B 55 EC mov edx,dword ptr [ebp-14h] 
00401070 8A 42 01 mov al,byte ptr [edx+1] 
00401073 88 45 FC mov byte ptr [ebp-4],al 
第一种在读取时直接就把字符串中的元素读到寄存器cl中，而第二种则要先把指针值读到edx中，在根据edx读取字符，显然慢了。 

小结： 
堆和栈的区别可以用如下的比喻来看出： 
使用栈就象我们去饭馆里吃饭，只管点菜（发出申请）、付钱、和吃（使用），吃饱了就走，不必理会切菜、洗菜等准备工作和洗碗、刷锅等扫尾工作，他的好处是快捷，但是自由度小。 
使用堆就象是自己动手做喜欢吃的菜肴，比较麻烦，但是比较符合自己的口味，而且自由度大。

全局变量、静态数据、常量存放在全局数据区，所有函数的代码存放在代码区，为运行函数而分配的局部变量、函数参数、返回数据、返回地址等存放在栈区。   
所以在同一个进程里，多个任务（线程）的全局变量和静态变量都应该是共享同一块内存（全局数据区）   
而在不同的进程里，重新加载了代码，各个进程间的全局变量和静态变量当然不是拥有同一块内存。   
在psos下，各个任务是不同的线程，所以各个任务的全局变量和静态变量是在同一块内存。而我的另一个程序中（在sco unix），是每次运行都是一个新的进程，所以各个进程的全局变量和静态变量拥有不同的内存

ECHO="echo"

导致脚本引用小写echo的时候错误，不知为何导致这种问题，

终于查到解决办法：

I think I have a workaround to fix this problem:

First I've copied the directory "/usr/share/apps/kdevappwizard/" to "$HOME/.kde/share/apps/". Next I've extract the archive "$HOME/.kde/share/apps/kdevappwizard/template-common/incadmin.tar.gz" and I've replaced the old file "ltmain.sh" with the new one from "/usr/share/libtool/config/ltmain.sh". Then I've packed them again to a new file named "incadmin.tar.gz" and replaced the old archive with the new one. Now the script ltmain.sh creates a current libtool while compilation and my source code compiles without any error.

I have attached my new archive "incadmin.tar.gz" with the new file "ltmain.sh" included. Hope this will help.、

版本:可能换低版本也可以解决，问题版本是：

qian@qian:~/work/sdf/debug/src$ libtool --version
ltmain.sh (GNU libtool) 2.2.6
Written by Gordon Matzigkeit <gord@gnu.ai.mit.edu>, 1996

Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
低

   if (fabs(a)<fabs(b)) return ( fabs((a-b)/a)    >     relError ) ? true     :    false;   
     return ( fabs((a-b)/b)     >     relError ) ? true     :    false;
};

使用相对误差就很完善吗？
也不是， 在某些特殊情况下， 相对误差也不能代表全部
比如在判断空间三点是否共线的时候，使用判断点到另外两个点形成的线段的距离的方法的时候
只用相对误差是不够的，应为线段距离可能很段，也可能很长，点到线段的距离，以及线段的长度做综合比较的时候，需要相对误差和绝对误差结合的方式才可以
相对完整的比较算法应该如下：
bool IsEqual(float a, float b, float absError, float relError )
{   
                                   if (a==b) return true;
if (fabs(a-b)<absError ) return true;
if (fabs(a>b) return (fabs((a-b)/a>relError ) ? true : false;
return (fabs((a-b)/b>relError ) ? true : false;
}
这样才相对完整  

参照MSDN定义：

/* Compile options needed: none. Value of c is printed with a decimal
point precision of 10 and 6 (printf rounded value by default) to
show the difference
*/
#include 
// Define your own tolerance

const double EPSILON = 1.00e-07;

const float   FLT_EPSILON  = 1.192092896e-07F;

const double  DBL_EPSILON  = 2.2204460492503131e-016;


 
#define FLOAT_EQ(x,v) (((v - EPSILON) < x) && (x <( v + EPSILON)))
int main()
{
float a, b, c;
a = 1.345f;
b = 1.123f;
c = a + b;
// if (FLOAT_EQ(c, 2.468))   // Remove comment for correct result
if (c == 2.468)              // Comment this line for correct result
printf("They are equal.\n");
else
printf("They are not equal! The value of c is %13.10f,or %f",c,c);
}