【问题标题】:Issue with timer with long signal handler (SIGALARM)带有长信号处理程序的计时器问题 (SIGALARM)
【发布时间】:2011-09-02 01:30:36
【问题描述】:

有一个定时器每 1 秒发出一次信号 SIGALARM。休眠的信号处理程序 注册 2 秒。发生什么了?具体来说,我有以下代码,其中进程运行多个线程。有趣的是,使用这个长信号处理程序,看起来其他线程被阻止执行......谁能解释为什么会这样?

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h> //rand
#include <sys/wait.h>
#include <time.h>
#include <sys/time.h>
#include <pthread.h>
#define NUM_THREADS 2

int init_timer(int real_time, int msec) {
    struct itimerval timeslice;
    timeslice.it_interval.tv_sec = msec / 1000;
    timeslice.it_interval.tv_usec = (msec % 1000) * 1000;
    timeslice.it_value.tv_sec = msec / 1000;
    timeslice.it_value.tv_usec = (msec % 1000) * 1000;
    setitimer(real_time ? ITIMER_REAL : ITIMER_VIRTUAL, &timeslice, NULL);
    return 0;
}

void install_handler(int signo, void(*handler)(int)) {
    sigset_t set;
    struct sigaction act;

    /* Setup the handler */
    act.sa_handler = handler;
    act.sa_flags = SA_RESTART;
    sigaction(signo, &act, 0);

    /* Unblock the signal */
    sigemptyset(&set);
    sigaddset(&set, signo);
    sigprocmask(SIG_UNBLOCK, &set, NULL);
    return;
}

void timerTest(int signo)
{
    printf("000\n");
    sleep(1);
    printf("111\n");
}

void * threadTest(void * threadId)
{
    while(true)
    {
        printf("222\n");
    }
}

int main(int argc, char *argv[]) {
    int real_time = 1;
    int tick_msec = 10;
    init_timer(real_time, tick_msec);
    install_handler(real_time ? SIGALRM : SIGVTALRM, &timerTest);

    pthread_t threads[NUM_THREADS];
    int rc;
    long t;
    for (t = 0; t < NUM_THREADS; t++) {
        rc = pthread_create(&threads[t], NULL, threadTest, (void *) t);
        if (rc) {
            exit(-1);
        }
    }

    void * status;
    for (t = 0; t < NUM_THREADS; t++) {
        rc = pthread_join(threads[t], &status);
        if (rc) {
            exit(-1);
        }
    }
    pthread_exit(NULL);
}

打印输出:

222
222
222
222
...
222
000
111
000
111
...

第一个 111 出现后不会有 222 吗?为什么会这样?

【问题讨论】:

  • 在帖子中包含操作系统也可能相关。

标签: c multithreading posix handler signals


【解决方案1】:

信号被传递到特定线程,因此信号处理程序在特定线程(信号被传递到的线程)中运行。如果信号被传递给写出222\n 的线程,那么该线程必须停止写出222\n 并运行信号处理程序。您的示例信号处理程序需要一整秒才能运行,因此该线程可能不会写出 222\n。

此外,由于您使用printf 写出所有这些字节,因此在 libc 中进行了一些锁定。由于printf 不是“异步信号安全”函数,因此实际上未定义在信号处理程序中使用它会发生什么。您观察到的行为的一种可能解释是这样的。如果在该线程持有 stdout 锁的情况下将信号传递给该线程,则在处理程序返回并且该线程中运行的“正常”代码可以释放锁之前,其他线程将无法写入 stdout。但是,在这种情况下,信号处理程序仍然可以写入标准输出,因为锁是一个 rlock,可以在任何特定线程中重复获取。不过,这可能因特定平台、C 库、线程库或月相而异。不过,您的示例很容易转换为使用 write(2),它演示了或多或少相同的问题行为,具有或多或少相同的修复,并且不依赖于未定义的行为。

如果您在222\n 线程中SIG_BLOCK 定时器信号,则信号处理程序将始终在主线程中运行,并且您将在信号处理程序休眠时继续获得222\n 输出。

Seth 还提出了一个很好的观点,即仅在信号处理程序中使用安全函数。使用任何其他意味着您的程序的行为是未定义的。

【讨论】:

  • stdio 锁定是递归的这一事实并不意味着当调用线程中已经持有锁时它会从信号处理程序中工作。递归是比可重入弱得多的要求,事实上,stdio 和它使用的锁定通常都不是可重入的。
  • 谢谢,很好。我已经编辑了答案,以明确在这种情况下 printf 行为是未定义的,并指出了一个在某种程度上等效但避免未定义行为的替代方案。
  • 观察到的行为实际上是由于printf的锁定。将printf 更改为write,您会得到孩子们正在编写222 和偶尔000、111 的更理智的行为,直到所有三个线程最终都在信号处理程序上休眠(进一步的信号被阻塞)并且没有再写222。
【解决方案2】:

通常,当您在信号处理程序中时,信号(或至少该信号)会被阻塞。在信号处理程序中做很多事情也是一个坏主意。通常你应该设置一个变量或类似的东西,然后在你正常的代码路径中处理信号。

查看 sigaction 的 SA_NODEFER 标志,了解允许或拒绝在信号处理程序中接收信号的方法。

还有数量有限的函数可以安全地从信号处理程序内部调用。 signal(7) 手册页对此进行了描述。 “信号处理函数必须非常小心,因为其他地方的处理可能会在程序执行的某个任意点被中断。POSIX 有“安全函数”的概念。如果信号中断了不安全函数的执行,则处理程序调用一个不安全的函数,那么程序的行为是未定义的"

从信号处理程序内部调用不安全函数的程序损坏。在某些机器上它会 “工作”;在其他人它将核心转储。允许做任何事情或 什么都没有,包括重新格式化磁盘,使用户受到 沙哑的 Barry Manilow 唱片倒放,或丢下 tacnuke 在达拉斯。试图调用一个不安全的函数会使程序进入未定义行为的模糊地带。

向老鼠道歉。

【讨论】:

  • 从信号处理程序调用一个不安全的函数有时是有效的,如果你能保证它没有中断一个不安全的函数。例如,如果线程只是在执行for (;;) pause();,那么你可以在信号处理程序中做任何你想做的事情。
  • 要是我这么说就好了。等一下!我做到了!
  • 我在回复这句话:“从信号处理程序内部调用不安全函数的程序已损坏。”这是一种过度简化。大多数这样做的天真编写的程序被破坏了,但这是由于程序员犯了错误,没有检查其他函数可能被中断,而不是在信号中使用异步信号不安全函数的固有结果处理程序。
【解决方案3】:

在信号处理程序中使用printf 是不正确的。

关于将要处理 SIGALARM 的线程,您可能会发现一些关于信号阻塞 here 的有用信息。这篇文章包含启发性的 Linux 内核代码。本质上,如果要接收信号,则信号由主线程处理。如果没有,它将由任何其他需要它的线程处理。您可以使用 pthread_sigmask(3)

屏蔽线程中的特定信号

【讨论】:

  • 虽然此链接可能会回答问题,但最好在此处包含答案的基本部分并提供链接以供参考。如果链接页面发生更改,仅链接的答案可能会失效。
  • 感谢您的评论,从现在开始我会这样做
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-08-23
  • 1970-01-01
  • 2013-06-19
  • 1970-01-01
  • 2017-12-07
相关资源
最近更新 更多