记一次C程序线程大面积假死、卡住

今天是客户要求的最后期限，可突然发现一种操作方式下，程序会很容出现线程大面积卡住。

程序开了数十个线程，每个都会ping一个ip。

于是有人说是线程太多，有人说是发包太多，还有说是usleep会导致卡死。

gdb连接上卡死的程序:

gdb main pid

info threads
发现确实很多程序处于usleep。

网上很多说用select的，同事给了一段用select的，结果最基本的sleep时间都远远不对（估计是什么低级错误）。我也不喜欢select，因为效率低。

后来换了naosleep，

 

void sleepSelect1(unsigned int us, char* file, int line)

 

{

 

struct timespec ts1;

 

struct timespec ts = {

 

us / 1000000,

 

(us % 1000000) * 1000

 

};

 

 

 

while ((-1 == nanosleep(&ts, ts1)) && (EINTR == errno));

 

}

 

结果还是会全面卡住，而且似乎更快，

后来换pthread_cond_timedwait：

 

void sleepSelect2(unsigned int us, char* file, int line)

 

{

 

pthread_mutex_t *mutex = malloc(sizeof(pthread_mutex_t));

 

pthread_cond_t *cond = malloc(sizeof(pthread_cond_t));

 

 

 

memset(mutex, 0, sizeof(pthread_mutex_t));

 

memset(cond, 0, sizeof(pthread_cond_t));

 

 

 

struct timespec *deadline=malloc(sizeof(struct timespec));

 

struct timeval *now=malloc(sizeof(struct timeval));

 

 

 

gettimeofday(now,NULL);

 

long nanoseconds = (us % 1000000) * 1000;

 

 

 

deadline->tv_sec = now->tv_sec + seconds;

 

deadline->tv_nsec = now->tv_usec * 1000 + nanoseconds;

 

 

 

if( deadline->tv_nsec >= 1000000000L )

 

{

 

deadline->tv_nsec -= 1000000000L;

 

deadline->tv_sec++;

 

}

 

 

 

pthread_mutex_lock(mutex);

 

pthread_cond_timedwait(cond,mutex,deadline);

 

pthread_mutex_unlock(mutex);

 

 

 

free(deadline);

 

free(now);

 

free(mutex);

 

free(cond);

 

}

 

同样会大面积卡住在 pthread_cond_timedwait。而且发现把sleep(50)这样专用 cond_timedwait会直接卡住。

后来我发现sleep最终也是nanosleep实现的，nanosleep要传2个参数，我却没有搜索到第二个参数的意义。这让我想起另外一个函数gettimeofday的第二参数，我都是传的null。。。。

下面这段代码，用上之后：程序没有卡住了：

 

void sleepSelect1(unsigned int us, char* file, int line)

{

 

struct timespec ts = {

 

us / 1000000,

 

(us % 1000000) * 1000

 

};

 

while ((-1 == nanosleep(&ts, NULL)) && (EINTR == errno));

 

}

 

#define sleepSelect(us) sleepSelect1(us, __FILE__, __LINE__)

sleepSelect就等同于 usleep