慎用线程取消

本周二，我们产品在某省的一个节点应用运行时出现了“死锁”情况，由于监控得力，我们在“死锁”后一分钟内就发现了这个情况，并及时重启了这个节点应用。由于是集群式系统，一个节点的故障对整个系统业务的运行几乎没造成什么影响。不过，这确是一个潜在的隐患。

经过对系统当时运行日志的分析，我们将问题锁定在“线程取消”这个机制的使用上。在“生产者-消费者”实现思路这篇文章中，我曾经提到过我们目前采用的一种通知机制的实现。消费者进程的主线程创建一个子线程，后者一般挂起在条件变量上等待生产者侧的唤醒。一般情况下，这种机制运行都很良好，问题出就出在消费者进程要退出的时候。

这个机制的实现也是逐渐“改”过来的。最初发现消费者进程退出时子线程长时间无法被唤醒导致无法及时退出，主线程因为要Join子线程，所以也阻塞在Join上，两个线程都挂起了，进程也就无法退出，导致后续业务逻辑上会出现一些问题。

之前开发人员在解决这个问题上采用了“线程取消”机制，在主线程Join子线程前调用pthread_cancel取消了子线程。但由于对线程取消机制理解的不透彻，导致子线程在pthread_cond_wait这个"cancellation point"（man cancellation）上退出。在Sun官方文档中提到在pthread_cond_wait这个取消点退出线程时，线程仍然持有与条件变量关联的那把互斥锁，这样就会导致其他进程在上锁时挂起在互斥锁上。但由于我们在代码中使用了不可移植的死锁恢复机制，这个问题也就不那么明显，偶尔出现（锁状态不一致很可能会导致死锁恢复机制失效），就这个偶尔出现导致了上述问题。

与另外一个产品线的同事做了一下内部沟通，发现他们那边的产品已经做了改善（或许是我们没有经常性同步库代码导致代码出现不一致了^_^）。最初他们通过调用pthread_cleanup_push注册取消点清理程序来完成mutex的unlock，该问题得到了暂时解决。但是子线程在其内部其他取消点的退出也带来的一些麻烦，比如open日志文件时。为了控制子线程在合适的取消点退出，他们采用了Disable Cancel State的线程设置，并在关键路径上使用“enable cancel -> pthread_testcancel -> disable cancel”来设置子线程退出的窗口。

另外为了子线程能在主线程Cancel它的时候有机会被唤醒，主线程在cancel调用后，使用pthread_cond_broadcast给子线程提供了一次机会。当然这也让阻塞在同一个条件变量上的其他线程被“假唤醒”，但这种情况是可以被忍受的。

在很多讲解多线程的书籍中都不建议使用cancel机制，这里也建议慎用。直到目前也许还有一些例外情况我们还没能考虑周全呢。