【译】使用可重入函数进行更安全的信号处理

 

使用可重入函数进行更安全的信号处理

何时及如何利用可重入性避免代码缺陷

Dipak Jha (mailto:dipakjha@in.ibm.com?subject=Use reentrant functions for safer signal handling&cc=dipakjha@yahoo.com), Software Engineer, IBM

Date: 20 Jan 2005 

 

摘要：若对函数进行并发访问(无论通过线程或进程)，可能会遇到函数不可重入所导致的问题。在本文中，通过代码示例可了解若可重入性不能保证时如何导致异常，尤其是有关信号(signals)方面。本文包含五条推荐的编程实践，并提出和讨论一个编译器模型，该模型中可重入性由编译器前端处理。

 

     在早期编程中，不可重入性对程序员并未构成威胁；函数不会有并发访问，也没有中断存在。在很多较老的C 语言实现中，函数被认为是在单线程进程的环境中运行。 

     然而，如今并发编程已普遍使用，您需要意识到(可重入性)这一陷阱。本文将描述在并行和并发编程中函数不可重入性导致的一些潜在问题。信号的生成和处理尤其增加了额外的复杂性。由于信号在本质上是异步的，因此难以找出当信号处理函数触发某个不可重入函数时导致的缺陷。 

     本文包含如下内容：

• Ÿ   定义可重入性，并包含一个可重入函数的POSIX清单
• Ÿ   给出示例以说明不可重入性所导致的问题
• Ÿ   指出确保底层函数的可重入性的方法
• Ÿ   讨论在编译器层面上处理可重入性

 

什么是可重入性

     可重入函数可以由多于一个任务并发使用，而不必担心数据错误。相反，不可重入函数不能由超过一个任务所共享，除非通过使用信号量或者在代码关键部分禁用中断以确保函数的互斥。可重入函数可在任意时刻被中断，稍后再继续恢复运行，而不会丢失数据。可重入函数要么使用本地变量，要么在使用全局变量时保护自己的数据。

     可重入函数：

• Ÿ   不为连续的调用保持静态数据
• Ÿ   不返回指向静态数据的指针；所有数据都由函数的调用者提供
• Ÿ   使用本地数据，或制作全局数据的本地拷贝来保护全局数据
• Ÿ   绝不调用任何不可重入函数

     不要混淆可重入与线程安全。在程序员看来，这是两个独立的概念：函数可以是可重入的，线程安全的，二者皆是或二者皆非。不可重入的函数不能由多个线程使用。此外，也许不可能让某个不可重入的函数是线程安全的。

     IEEE Std 1003.1列出了118个可重入的 UNIX®函数，在此不予赘述。

     其余函数出于以下任意原因而不可重入：

• Ÿ   调用malloc或free(之类的函数)
• Ÿ   已知使用静态数据结构
• Ÿ   标准I/O库的一部分(该库很多实现使用全局数据结构)

 

信号与不可重入函数

     信号是软件中断，它使得程序员可以处理异步事件。为了向进程发送一个信号，内核在进程表项的信号域中设置一个比特位，对应于接收信号的类型。信号函数的ANSI C原型是：

void (*signal (int sigNum, void (*sigHandler)(int))) (int);

     或另一种描述形式：

typedef void sigHandler(int);

SigHandler *signal(int, sigHandler *);

     当进程处理所捕获的信号时，正在执行的正常指令序列被信号处理器临时中断。然后进程继续执行，但现在执行的是信号处理器中的指令。若信号处理器返回，则进程继续执行信号被捕获时正在执行的正常指令序列。 

     此时，在信号处理器中您并不知道信号被捕获时进程正在执行什么内容。若进程正在使用malloc在其堆(heap)上分配额外内存，您通过信号处理器调用malloc，那会怎样？或者，调用正在操作全局数据结构的某个函数，而在信号处理器中又调用同一个函数。若是调用malloc，则进程会被严重破坏，因为malloc通常会为所有它所分配的所有内存区域维持一个链表，而它可能正在修改该链表。 

     甚至可在需要多个指令的C操作符开始和结束之间发送中断。在程序员看来，指令似乎是原子的(即不能被分割为更小的操作)，但它实际上可能需要不止一个处理器指令才能完成该操作。以这段C代码为例：

temp += 1;

     在x86处理器上，该语句可能被编译为：

mov ax,[temp]

inc ax

mov [temp],ax

     这显然不是一个原子操作。

 

     该例(清单1)展示了在修改某个变量的过程中运行信号处理器可能会发生什么事情：

#include <signal.h>
#include <stdio.h>

struct two_int{ int a, b; }data;

void signal_handler(int signum){
    printf ("%d, %d\n", data.a, data.b);
    alarm (1);
}

int main (void){
    static struct two_int zeros = { 0, 0 }, ones = { 1, 1 };

    signal(SIGALRM, signal_handler);

    data = zeros;

    alarm (1);

    while (1)
        {data = zeros; data = ones;}
}

     该程序向data填充0，1，0，1，一直交替进行。同时，alarm信号处理器每秒打印一次当前内容(该程序在处理器中调用printf是安全的，因为当信号发生时它在处理器外部确实没有正被调用）。您预期该程序会输出什么？它应该打印0,0或1,1。但实际输出如下：

0, 0

1, 1 

(Skipping some output...) 

0, 1

1, 1

1, 0

1, 0

...

     在大部分机器上，data中存储一个新值需要若干指令，每次存储一个字。若在这些指令期间发出信号，则处理器可能发现data.a为0而 data.b为1，或者反之。另一方面，若我们编译和运行代码的机器能在一个不可中断的指令内存储一个对象值，那么处理器将总是打印0,0 或 1,1。

     信号带来的另一问题是，仅凭运行测试用例无法确保代码没有信号缺陷。该问题原因在于信号生成的异步本质。

 

不可重入函数与静态变量

     假定信号处理器使用不可重入的gethostbyname。该函数将值返回到一个静态对象中：

static struct hostent host; /* result stored here*/

     它每次都重新使用同一个对象。在下面的例子中，若信号刚好在main中调用gethostbyname期间到达，或甚至在调用之后到达，而程序仍然在使用那个(对象)值，则信号将破坏程序请求的值。

main(){
    struct hostent *hostPtr;
    //...
    signal(SIGALRM, sig_handler);
    //...
    hostPtr = gethostbyname(hostNameOne);
    //...
}

void sig_handler(){
    struct hostent *hostPtr;
    //...
    /* call to gethostbyname may clobber the value stored during the call inside the main() */
    hostPtr = gethostbyname(hostNameTwo);
    //...
}

     不过，若程序不使用 gethostbyname或任何其他在同一对象中返回信息的函数，或者每次使用时它都会阻塞信号，那么就是安全的。

     很多库函数在固定的对象中返回值，总是反复使用同一对象，它们都会导致相同的问题。若某个函数使用并修改您提供的某个对象，那它可能就是不可重入的；若两个调用使用同一对象，那么它们会相互干扰。

     当使用流(stream)进行I/O操作时会出现类似情况。假定信号处理器使用fprintf打印一条消息，而当信号发出时程序正在使用同一个流进行fprintf调用。信号处理器的消息和程序的数据都会被破坏，因为两个调用操作同一数据结构：流本身。

     当使用第三方程序库时，事情会变得更为复杂，因为您永远不知道哪部分程序库是可重入的，哪部分是不可重入的。对标准程序库而言，很多库函数在固定的对象中返回值，总是重复使用同一对象，这就使得那些函数不可重入。

     好消息是，近来很多提供商已经开始提供标准C程序库的可重入版本。对于任何给定程序库，您需要通读它所提供的文档，以了解其原型和标准库函数的用法是否有所变化。

 

确保可重入性的实践

     遵守这五条最佳实践将帮助您保持程序的可重入性。

实践1

     返回指向静态数据的指针可能导致函数不可重入。例如，将字符串转换为大写的strToUpper函数实现可能如下：

char *strToUpper(char *str)
{
    /*Returning pointer to static data makes it non-reentrant */
    static char buffer[STRING_SIZE_LIMIT];
    int index;

    for (index = 0; str[index]; index++)
        buffer[index] = toupper(str[index]);
    buffer[index] = '\0';
    return buffer;
}

     通过修改函数原型，可实现该函数的可重入版本。下面的清单为输出字符串提供存储空间：

char *strToUpper_r(char *in_str, char *out_str)
{
    int index;

    for (index = 0; in_str[index] != '\0'; index++)
        out_str[index] = toupper(in_str[index]);
    out_str[index] = '\0';

    return out_str;
}

     由调用方(caller)函数提供输出存储空间可保证函数可重入性。注意，此处遵循标准惯例，通过向函数名添加"_r"后缀来命名可重入函数。

 

实践2

     记忆数据的状态会使函数不可重入。不同线程可能会相继调用该函数，且修改那些数据时不会通知其他正在使用此数据的线程。若函数需要在连续调用期间维持某些数据的状态，如工作缓存或指针，则调用者应该提供该数据。 

     在以下示例中，函数返回字符串中的连续小写字母。该字符串仅在第一次调用时提供，类似strtok子例程。当遍历至字符串末尾时，函数返回'\0'。函数可能实现如下：

char getLowercaseChar(char *str)
{
    static char *buffer;
    static int index;
    char c = '\0';
    /* stores the working string on first call only */
    if (string != NULL) {
        buffer = str;
        index = 0;
    }

    /* searches a lowercase character */
    while(c= buffer[index]){
    if(islower(c)) {
        index++;
        break;
     }
     index++;
    }
    return c;
}

     该函数不可重入，因为它保存变量状态。为使它可重入，静态数据(即index)，需由调用者来维护。该函数的可重入版本可能实现如下：

char getLowercaseChar_r(char *str, int *pIndex)
{
    char c = '\0';

    /* no initialization - the caller should have done it */

    /* searches a lowercase character */
    while(c = str[*pIndex]){
        if(islower(c)){
           (*pIndex)++; break;
        }
        (*pIndex)++;
    }
    return c;
}

 

实践3

     在大部分系统中，malloc和free都不是可重入的，因为它们使用静态数据结构来记录哪些内存块是空闲的。因此，任何分配或释放内存的库函数都是不可重入的。这也包括分配空间以存储结果的函数。 

     避免在处理器中分配内存的最好方法是，预先分配信号处理器要使用的内存。避免在处理器中释放内存的最好方法是，标记或记录将要释放的对象，让程序不时地检查是否有等待被释放的内存。但这必须小心进行，因为将一个对象添加到一个链并不是原子操作，若它被另一个做同样动作的信号处理器中断，则会"丢失"一个对象。然而，若知道当信号可能到达时，程序不可能使用处理器此刻所使用的流，那么就是安全的。若程序使用的是某些其他流，那么也不会有任何问题。

 

实践4

     为编写无缺陷代码，要小心处理进程范围内的全局变量，如errno和h_errno。考虑下面的代码：

if (close(fd) < 0) {
    fprintf(stderr, "Error in close, errno: %d", errno);
    exit(1);
}

     假定信号在close系统调用设置errno变量到其返回之前这一极小的时间空隙内产生。该信号可能会改变errno的值，程序的行为会无法预料。 

     如下，在信号处理器内保存和恢复errno的值，可解决这一问题：

void signalHandler(int signo){
    int errno_saved;

    /* Save the error no. */
    errno_saved = errno;

    /* Let the signal handler complete its job */
    //...
    //...

    /* Restore the errno*/
    errno = errno_saved;
}

 

实践5

     若底层函数正处于关键部分，且生成并处理信号，则可能导致函数不可重入。通过使用信号集和信号掩码，代码的关键区域可被保护起来不受一组特定信号的影响，如下：

1. 保存当前信号集。
2. 屏蔽信号集中不需要的信号。
3. 使代码的关键部分完成其工作。
4. 最后，重置信号集。

     以下是该实践的概要：

sigset_t newmask, oldmask, zeromask;
...
/* Register the signal handler */
signal(SIGALRM, sig_handler);

/* Initialize the signal sets */
sigemtyset(&newmask); sigemtyset(&zeromask);

/* Add the signal to the set */
sigaddset(&newmask, SIGALRM);

/* Block SIGALRM and save current signal mask in set variable 'oldmask'
*/
sigprocmask(SIG_BLOCK, &newmask, &oldmask);

/* The protected code goes here
...
...
*/

/* Now allow all signals and pause */
sigsuspend(&zeromask);

/* Resume to the original signal mask */
sigprocmask(SIG_SETMASK, &oldmask, NULL);

/* Continue with other parts of the code */

     跳过sigsuspend(&zeromask);语句可能会引发问题。从消除信号阻塞到进程执行下条指令之间需要一些时钟周期间隙，任何在此时间窗内发生的信号都会丢失。函数调用sigsuspend通过重置信号掩码并使进程休眠一个单一原子操作来解决该问题。若能确保在此时间窗内生成信号不会有任何负面影响，则可跳过sigsuspend直接重设信号。

 

编译器层次处理可重入性

     我将提出一个在编译器层次处理可重入函数的模型。可为高级语言引入一个新的关键字reentrant，函数可被指定一个reentrant 标识符，以确保函数可重入，比如：

reentrant int foo();

     该指示符告知编译器对特定函数进行特殊处理。编译器可将该指示符存储在它的符号表中，并在中间代码生成阶段使用该指示符。为达到该目的，编译器的前端设计需要有一些改变。可重入指示符遵循这些准则：

1. 不为连续的调用保持静态数据
2. 通过制作全局数据的本地拷贝来保护全局数据
3. 绝不调用不可重入的函数
4. 不返回对静态数据的引用，所有数据均由函数调用者提供

     准则1可通过类型检查得到保证，若函数中有任何静态存储声明，则抛出错误消息。这可在编译的语法分析阶段完成。

     准则2，全局数据的保护可通过两种方式得到保证。基本方法是，若函数修改全局数据，则抛出一个错误消息。更为复杂的技术是以全局数据不被破坏的方式生成中间代码。可在编译器层面实现类似于前面实践4的方法。在进入函数时，编译器可使用其生成的临时名称存储待操作的全局数据，然后在退出函数时恢复该数据。使用编译器生成的临时名称存储数据对编译器而言是普遍的做法。 

     确保准则3要求编译器预先知道所有可重入函数，包括应用程序所使用的程序库。这些关于函数的额外信息可存储在符号表中。 

     最后，准则4已得到准则1的保证。若函数没有静态数据，也就不存在返回静态数据引用的问题。 

     所提出的这个模型将简化程序员遵循可重入函数准则的工作，而且使用该模型可以预防代码出现无意的可重入性缺陷。