记一次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