linux 多线程 信号

　　一个老系统的问题，用的system v消息队列同步等响应，通过alarm信号来进行超时控制。现在系统进行升级改造（所谓云化），原来进程处理的逻辑全部改成了线程框架，问题就出现了。alarm信号发出的时候，到底哪个线程会接收到这个信号呢？

　　于是赶忙问了下百度，有些地方说随机的，有些地方解答说随机的；另外有些人推荐用pthread_sigmask和sgwait之类，云者颇多。还有些同仁推荐改用异步消息队列，在没有消息的时候进行usleep、nanosleep，posix消息队列等等。

　　最后用了usleep，之所以不用另外的，我一个一个说个大概：

　　pthread_sigmask，这个方式试了下，我们提供的是客户端，也就是给别人的lib。这些依赖于调用进程主动做一些事情，出了问题排查比较难。试了一段时间发现，对宿主进程的改造比较多，定位也没玩没了，因为别人也是一个经历了十几年没有重构的老系统了。

　　posix消息队列，这个是支持异步的。但是整个团队都是延续着system v的使用习惯，在核心流程里面直接改成posix会影响维护的压力

　　消息队列nowait，然后usleep。网上很多文章说usleep有着这样那样的问题（不准确，线程不安全，影响信号一堆啥的）

　　所以我还测试了下（代码就不贴了，比较多），如下：　　　　OS版本Linux 2.6.32-358.el6.x86_64

function time(usec) realTime reduce
-------------------------------------------------------------------
usleep 500000 500138 138
nanosleep 500000 500139 139
select 500000 500591 591
usleep 100000 100133 133
nanosleep 100000 100129 129
select 100000 100147 147
usleep 50000 50132 132
nanosleep 50000 50128 128
select 50000 50130 130
usleep 10000 10130 130
nanosleep 10000 10107 107
select 10000 10129 129
usleep 1000 1077 77
nanosleep 1000 1064 64
select 1000 1079 79
usleep 900 971 71
nanosleep 900 973 73
select 900 971 71
usleep 500 570 70
nanosleep 500 563 63
select 500 571 71
usleep 100 168 68
nanosleep 100 168 68
select 100 158 58
usleep 10 68 58
nanosleep 10 67 57
select 10 67 57
usleep 1 60 59
nanosleep 1 57 56
select 1 58 57

　　结果显示，usleep500网上，基本误差还是很小的，往下的话就很不精确了。

　　扯了这多和主题无关的，这里是分割线=============================================

　　上面也提到了，我中间经历了使用pthread_sigmask，但是有问题，基于对线程信号的陌生。我写了一个测试程序看看，代码如下：

#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
#include <signal.h>
#include <errno.h>
#include <string.h>

#define TH_NUM 10

volatile int signflag = 0;
volatile pthread_t pid = 0;
volatile int num = 3;
pthread_t t_id[TH_NUM];

void sigalarm(int sign)
{
signflag = sign;
pid = pthread_self();
return;
}

void sigmaskhandleset(int sign, void (*handle)(int))
{
struct sigaction new_sigaction;
struct sigaction old_sigaction;

memset(&new_sigaction, 0x00, sizeof(new_sigaction));
memset(&old_sigaction, 0x00, sizeof(old_sigaction));

sigemptyset(&new_sigaction.sa_mask);
sigfillset(&new_sigaction.sa_mask);
new_sigaction.sa_handler = handle;

sigaction(sign, &new_sigaction, &old_sigaction);
return ;
}

void* thread_proc_1(void* pMgr)
{
// usleep(200);
printf("thread_proc_1() my self thread_id : %ld\n", pthread_self());
sigset_t set;
sigemptyset(&set);
sigaddset(&set, SIGALRM);
pthread_sigmask(SIG_UNBLOCK, &set, NULL);

sigmaskhandleset(SIGALRM, sigalarm);

// usleep(1000000);
sleep(20);
printf("thread_proc_1 speak : i am ready\n");

printf("thread_proc_1's signflag : %d , pid : %ld\n", signflag, pid);
num--;
return NULL;
}

void* thread_proc_2(void* pMgr)
{
printf("thread_proc_2() my self thread_id : %ld\n", pthread_self());
sigset_t set;
sigemptyset(&set);
sigaddset(&set, SIGALRM);
pthread_sigmask(SIG_UNBLOCK, &set, NULL);

sigmaskhandleset(SIGALRM, sigalarm);

// usleep(1000);
sleep(30);
printf("thread_proc_2 speak : i am ready\n");

printf("thread_proc_2's signflag : %d , pid : %ld\n", signflag, pid);
num--;
return NULL;
}

void* thread_alarm_post(void* pMgr)
{
// kill(getpid(), SIGALRM);
pthread_kill(t_id[1], SIGALRM);
alarm(1);
printf("thread_alarm_post speak : i has post alarm\n");
num--;
return NULL;
}

int main()
{
int ret = 0;
pthread_attr_t pthread_attr;

sigset_t set;
sigemptyset(&set);
sigaddset(&set, SIGALRM);
sigprocmask(SIG_BLOCK, &set, NULL);
// sigmaskhandleset(SIGALRM, sigalarm);
printf("main speak : i am ready\n");

pthread_attr_init(&pthread_attr);
pthread_attr_setdetachstate(&pthread_attr, PTHREAD_CREATE_DETACHED);
ret = pthread_create(&t_id[0], &pthread_attr, thread_proc_1, NULL);
if (0 != ret) {
printf("pthread_create failed : %d\n", errno);
return 0;
}

ret = pthread_create(&t_id[1], &pthread_attr, thread_proc_2, NULL);
if (0 != ret) {
printf("pthread_create failed : %d\n", errno);
return 0;
}

printf("main() my self thread_id : %ld\n", pthread_self());

ret = pthread_create(&t_id[2], &pthread_attr, thread_alarm_post, NULL);
if (0 != ret) {
printf("pthread_create failed : %d\n", errno);
return 0;
}

// kill(getpid(), SIGALRM);
// pthread_join(t_id[0], NULL);
// pthread_join(t_id[1], NULL);
// pthread_join(t_id[2], NULL);
// while(num>0);
return 0;
}

　　　各种情况都测试了下，里面的注释掉那部分其实也是测试过程中的一部分。总结了下（基于测试的OS版本，不针对其它OS）：

　　　　1、使用过程中看不出来usleep、sleep会产生SGIALRM信号（针对网上说的usleep会影响信号这一方面验证的）

　　　　2、过程中看不出来usleep、sleep会影响线程之间的安全（针对网上说的usleep线程不安全）

　　　　3、信号先被哪个线程接收？我还是无法确定，也有可能是随机的。

　　　　　　但是可以确定的是linux下肯定不是最后一个注册信号处理函数的那个线程

　　　　　　我觉得也不是正在运行的那个线程，道理很简单，因为如果主线程不屏蔽信号，那么一直都是主线程处理信号

　　　　　　否则的话，一直都是第一个线程先处理

　　　　4、我测试了几百遍同样一个程序（没有改代码重编的情况下），都是pthread_self()最大的那个线程处理了信号响应。这能说明什么问题吗？

　　　　　　我不能这么下结论，但是他应该说明了些什么东西！

今天又讨论起来这个问题，重新做了一次测试！补充一些上次疏漏的地方：

　　　　1、测试结果还是结果还是最大的线程接收，也就是说如果主线程没有屏蔽！那么处理信号中断函数的pthread_self()函数返回的都是主线程的id

　　　　2、但是每次中断不确定是主线程，而有可能是其它子线程！

　　　　3、线程在sleep过程中，每次被中断之后并不是立刻返回！而是不可预测的中断次数之后返回了

　　　　4、pthread_kill函数每次都会及时中断，而且这个过程中sleep会里面返回