可重入、异步信号安全和线程安全 .

来源： http://blog.csdn.net/digu/article/details/5859870

 

转贴：http://hi.baidu.com/lbxthinker/blog/item/b5a133f2362da659342acc31.html

 

（一）

一个可重入的函数简单来说就是可以被中断的函数，也就是说，可以在这个函数执行的任何时刻中断它，转入OS 调度下去执行另外一段代码，而返回控制时不会出现什么错误。
《多线程编程指南》中定义，可以被信号控制器安全调用的函数被称为" 异步信号安全" 函数。
因此，我认为可重入与异步信号安全是一个概念 。

有人将可重入函数与线程安全函数混为一谈，我认为是不正确的。

这里引用CSAPP 中的描述来说明一下：
--------------------------------------------------
CSAPP
13.7.1 线程安全
一个函数被称为线程安全的，当且仅当被多个并发线程反复的调用时，它会一直产生正确的结果。
13.7.2 可重入性
有一类重要的线程安全函数，叫做可重入函数，其特点在于它们具有一种属性：当它们被多个线程调用时，不会引用任何共享的数据。

尽管线程安全和可重入有时会（ 不正确的 ）被用做同义词，但是它们之间还是有清晰的技术差别的。可重入函数是线程安全函数的一个真子集。
--------------------------------------------------

重入即表示重复进入，首先它意味着这个函数可以被中断，其次意味着它除了使用自己栈上的变量以外不依赖于任何环境（包括static ），这样的函数就是purecode （纯代码）可重入，可以允许有该函数的多个副本在运行，由于它们使用的是分离的栈，所以不会互相干扰。
可重入函数是线程安全函数，但是反过来，线程安全函数未必是可重入函数。
实际上，可重入函数很少，APUE 10.6 节中描述了Single UNIX Specification 说明的可重入的函数，只有115 个；APUE 12.5 节中描述了POSIX.1 中不能保证线程安全的函数，只有89 个。

信号就像硬件中断一样，会打断正在执行的指令序列。信号处理函数无法判断捕获到信号的时候，进程在何处运行。如果信号处理函数中的操作与打断的函数的操作相同，而且这个操作中有静态数据结构等，当信号处理函数返回的时候（当然这里讨论的是信号处理函数可以返回），恢复原先的执行序列，可能会导致信号处理函数中的操作覆盖了之前正常操作中的数据。
不可重入函数的原因在于：
1> 已知它们使用静态数据结构
2> 它们调用malloc 和free.
因为malloc 通常会为所分配的存储区维护一个链接表，而插入执行信号处理函数的时候，进程可能正在修改此链接表。
3> 它们是标准IO 函数.
因为标准IO 库的很多实现都使用了全局数据结构

即 使对于可重入函数，在信号处理函数中使用也需要注意一个问题就是errno 。一个线程中只有一个errno 变量，信号处理函数中使用的可重入函数也有可能 会修改errno 。例如，read 函数是可重入的，但是它也有可能会修改errno 。因此，正确的做法是在信号处理函数开始，先保存errno ；在信号处 理函数退出的时候，再恢复errno 。

例如，程序正在调用printf 输出，但是在调用printf 时，出现了信号，对应的信号处理函数也有printf 语句，就会导致两个printf 的输出混杂在一起。
如果是给printf 加锁的话，同样是上面的情况就会导致死锁。对于这种情况，采用的方法一般是在特定的区域屏蔽一定的信号。
屏蔽信号的方法：
1> signal(SIGPIPE, SIG_IGN); // 忽略一些信号
2> sigprocmask()
sigprocmask 只为单线程定义的
3> pthread_sigmask()
pthread_sigmasks 可以在多线程中使用

现在看来信号异步安全和可重入的限制似乎是一样的，所以这里把它们等同看待;-)

线程安全
线程安全：如果一个函数在同一时刻可以被多个线程安全的调用，就称该函数是线程安全的。Malloc函数是线程安全的。

不需要共享时，请为每个线程提供一个专用的数据副本。如果共享非常重要，则提供显式同步，以确保程序以确定的方式操作。通过将过程包含在语句中来锁定和解除锁定互斥，可以使不安全过程变成线程安全过程，而且可以进行串行化。

很多函数并不是线程安全的，因为他们返回的数据是存放在静态的内存缓冲区中的。通过修改接口，由调用者自行提供缓冲区就可以使这些函数变为线程安全的。
操作系统实现支持线程安全函数的时候，会对POSIX.1 中的一些非线程安全的函数提供一些可替换的线程安全版本。
例如,gethostbyname() 是线程不安全的，在Linux 中提供了gethostbyname_r() 的线程安全实现。
函数名字后面加上"_r" ，以表明这个版本是可重入的（对于线程可重入，也就是说是线程安全的，但并不是说对于信号处理函数也是可重入的，或者是异步信号安全的）。

多线程程序中常见的疏忽性问题
1> 将指针作为新线程的参数传递给调用方栈。
2> 在没有同步机制保护的情况下访问全局内存的共享可更改状态。
3> 两个线程尝试轮流获取对同一对全局资源的权限时导致死锁。其中一个线程控制第一种资源，另一个线程控制第二种资源。其中一个线程放弃之前，任何一个线程都无法继续
操作。
4> 尝试重新获取已持有的锁（递归死锁）。
5> 在同步保护中创建隐藏的间隔。如果受保护的代码段包含的函数释放了同步机制，而又在返回调用方之前重新获取了该同步机制，则将在保护中出现此间隔。结果具有误导性。对于调用方，表面上看全局数据已受到保护，而实际上未受到保护。
6> 将UNIX 信号与线程混合时，使用sigwait(2) 模型来处理异步信号。
7> 调用setjmp(3C) 和longjmp(3C) ，然后长时间跳跃，而不释放互斥锁。
8> 从对*_cond_wait() 或*_cond_timedwait() 的调用中返回后无法重新评估条件。


总结
判断一个函数是不是可重入函数，在于判断其能否可以被打断，打断后恢复运行能够得到正确的结果。（打断执行的指令序列并不改变函数的数据）
判断一个函数是不是线程安全的，在于判断其能否在多个线程同时执行其指令序列的时候，保证每个线程都能够得到正确的结果。

如果一个函数对多个线程来说是可重入的，则说这个函数是线程安全的，但这并不能说明对信号处理程序来说该函数也是可重入的。
如果函数对异步信号处理程序的重入是安全的，那 么就可以说函数是" 异步- 信号安全 " 的。

 

 

 

（二）

可重入与线程安全是两个独立的概念， 都与函数处理资源的方式有关。

• 首先，可重入和线程安全是两个并不等同的概念，一个函数可以是可重入的，也可以是线程安全的，可以两者均满足，可以两者皆不满组( 该描述严格的说存在漏洞，参见第二条) 。
• 其次，从集合和逻辑的角度看，可重入是线程安全的子集，可重入是线程安全的充分非必要条件。可重入的函数一定是线程安全的，然过来则不成立。
• 第三，POSIX 中对可重入和线程安全这两个概念的定义：

        Reentrant Function :A function whose effect, when called by two or more threads,is guaranteed to be as if the threads each executed thefunction one after another in an undefined order, even ifthe actual execution is interleaved.

        Thread-Safe Function：A function that may be safely invoked concurrently by multiple threads.

         Async-Signal-Safe Function：A function that may be invoked, without restriction fromsignal-catching functions. No function is async-signal -safe unless explicitly described as such.

       以上三者的关系为：可重入函数 必然 是 线程安全函数 和 异步信号安全函数；

                        线程安全函数不一定是可重入函数。
     可重入与线程安全的区别体现在能否在signal 处理函数中被调用的问题上，可重入函数在signal 处理函数中可以被安全调用，因此同时也是Async-Signal-Safe Function；而线程安全函数不保证可以在signal 处理函数中被安全调用，如果通过设置信号阻塞集合等方法保证一个非可重入函数不被信号中断，那么它也是Async-Signal-Safe Function 。

     值得一提的是POSIX 1003.1 的System Interface 缺省是Thread-Safe 的，但不是Async-Signal-Safe 的。Async-Signal-Safe 的需要明确表示，比如fork () 和signal() 。

    一个非可重入函数通常( 尽管不是所有情况下) 由它的外部接口和使用方法即可进行判断。例如：strtok() 是非可重入的，因为它在内部存储了被标记分割的字符串；ctime() 函数也是非可重入的，它返回一个指向静态数据的指针，而该静态数据在每次调用中都被覆盖重写。

    一个线程安全的函数通过加锁的方式来实现多线程对共享数据的安全访问。线程安全这个概念，只与函数的内部实现有关，而不影响函数的外部接口。在C语言中，局部变量是在栈上分配的。因此，任何未使用静态数据或其他共享资源的函数都是线程安全的。

   目前的AIX版本中，以下函数库是线程安全的：

         * C标准函数库

         * 与BSD 兼容的函数库

    使用全局变量( 的函数) 是非线程安全的。这样的信息应该以线程为单位进行存储，这样对数据的访问就可以串行化。一个线程可能会读取由另外一个线程生成的错误代码。在AIX 中，每个线程有独立的errno 变量。

最后让我们来构想一个线程安全但不可重入的函数:

     假设函数func() 在执行过程中需要访问某个共享资源，因此为了实现线程安全，在使用该资源前加锁，在不需要资源解锁。

    假设该函数在某次执行过程中，在已经获得资源锁之后，有异步信号发生，程序的执行流转交给对应的信号处理函数；再假设在该信号处理函数中也需要调用函数 func() ，那么func() 在这次执行中仍会在访问共享资源前试图获得资源锁，然而我们知道前一个func() 实例已然获得该锁，因此信号处理函数阻 塞—— 另一方面，信号处理函数结束前被信号中断的线程是无法恢复执行的，当然也没有释放资源的机会，这样就出现了线程和信号处理函数之间的死锁局面。

     因此，func() 尽管通过加锁的方式能保证线程安全，但是由于函数体对共享资源的访问，因此是非可重入。

改写函数库

下面强调了将现存函数库改写为可重入和线程安全版本的主要步骤，只适用于C 语言的函数库。

    * 识别出由函数库导出的所有全局变量。这些全局变量通常是在头文件中由export 关键字定义的。

      导出的全局变量应该被封装起来。每个变量应该被设为函数库所私有的( 通过static 关键字实现) ，然后创建全局变量的访问函数来执行对全局变量的访问。

    * 识别出所有静态变量和其他共享资源。静态变量通常是由static 关键字定义的。

       每个共享资源都应该与一个锁关联起来，锁的粒度( 也就是锁的数量) ，影响着函数库的性能。为了初始化所有锁，可能需要一个仅被调用一次的初始化函数。

    * 识别所有非可重入函数，并将其转化为可重入。参见函数可重入化

    * 识别所有非线程安全函数，并将其转化为线程安全。参见函数线程安全化。

使用非线程安全函数的解决方法

    通过某种解决方法，非线程安全函数是可以被多个线程调用的。这在某些情况下或许是有用的，特别是当在多线程程序中使用一个非线程安全函数库的时候——或者是出于测试的目的，或者是由于没有相应的线程安全版本可用。这种解决方法会增加开销，因为它需要将对某个或一组函数的调用进行串行化。

• 使用作用于整个函数库的锁，在每次使用该函数库( 调用库中的某个函数或是访问库中的全局变量) 时加锁，如下面的伪代码所示：

              /* this is pseudo-code! */

             lock(library_lock);

              library_call();

              unlock(library_lock);

      

              lock(library_lock);

              x = library_var;

             unlock(library_lock);

      该解决方法有可能会造成性能瓶颈，因为在任意时刻，只有一个线程能任意的访问或是用该库。只有在该库很少被使用的情况下，或是作为一种快速的实现方式，该方法才是可接受的。

• 使用作用于单个库组件( 函数或是全局变量) 或是一组组件的锁，如下面的伪代码所示

            /* this is pseudo-code! */

            lock(library_moduleA_lock);

            library_moduleA_call();

            unlock(library_moduleA_lock);

            lock(library_moduleB_lock);

            x = library_moduleB_var;

            unlock(library_moduleB_lock);

      这种方法与前者相比要复杂一些，但是能提高性能

    由于该类解决方式只应该在应用程序而不是函数库中使用，可以使用互斥锁(mutex) 来为整个库加锁。