线程终止

2009年4月15日

 

前段时间多线程编程，在调试的时候遇到麻烦。多线程的debug太困难，打log是不好用的，因为log本身也不一定是线程安全的。后来借助eclipse的可视化debug工具以及helgrind，问题算得到了比较好的解决。

 

这礼拜遇到的bug是，程序在运行一段时间之后异常，而且是不稳定的异常。一开始真的不知道是哪儿有问题。用了各种方法最后确定是分配新线程失败。而我恰好没有在开辟新线程的代码中使用断言。解这个bug得到最大的收获就是，不管代码看上去多么的正确，只要涉及到系统调用，该断言的就得断言，不含糊。

 

本以为就几行破代码，照书写，怎么可能出错。但结果还是出乎预料。仔细查看文档，才知道真实的代码并不像书上的例子写的那么简单。分配线程失败的原因，是因为我想当然地认为线程正常return之后便被释放。但实际情况是，一个默认属性的线程，即使终止之后，也会一直保持到对该线程调用pthread_join()或pthread_detach()函数。因为默认属性的线程认为结束后的返回值是有价值的，因此等待着pthread_join()来取得其返回值。结果我忽略了这一点，造成结束后的线程大量堆积，直至系统默认的每进程最大分配线程数，然后导致线程分配失败。

 

解决办法，一是显式调用pthread_join()或pthread_detach()函数；二是设置线程属性：

 

pthread_t tid; pthread_attr_t attr; assert( 0==pthread_attr_init(&attr) ); assert( 0==pthread_attr_setdetachstate( &attr, PTHREAD_CREATE_DETACHED ) ); assert( 0==pthread_create( &tid, &attr, func, arg ) );

 

PTHREAD_CREATE_DETACHED 意味着这个线程被创建时就是“分离”状态，一旦自然终止即被自动释放，不可通过pthread_join()函数得到返回值，通常被用于创建不关心返回值的线程。这是好东西。

 

说到好东西，想起另外一个，就是pthread的mutex。因为用了半天mutex发现mutex可以设置检查死锁的属性。- -！

 

pthread_mutexattr_t mattr; pthread_mutex_t mutex; assert( 0==pthread_mutexattr_init( &mattr ) ); assert( 0==pthread_mutexattr_settype( &mattr, PTHREAD_MUTEX_ERRORCHECK) ); assert( 0==pthread_mutex_init( &mutex, &mattr ) );

 

不过这个errorcheck属性也只能检查自己的死锁，即自己被连续加锁两次的情况。多mutex复杂死锁还是得真人纠错~~。

 

还有，valgrind也是个好东西，--tool=helgrind 参数可以在程序运行时检查所有多线程竞合资源。参考helgrind检查结果修改多线程逻辑，可以使多线程更加安全稳定，也可以让锁加得更少更有针对性。经过一天的努力，俺的一个模块终于没有helgrind error了。加锁是个技术活。