今天凌晨2009-10赛季西班牙国家德比第二回合在皇家马德里主场伯纳乌上演，技高一筹的巴萨以2:0干净利落的赢得了这场关键战役。世界足球先生、金球先生、巴萨国王梅西继在欧冠四分之一决赛以一己之力击溃兵工厂阿森纳后，又在本场比赛中为巴萨先把头筹。这场比赛的胜利是巴萨整个团队的胜利，但是梅西绝对是这个团队中最最耀眼的那颗星。

梅西打入个人在国家德比中的第七粒进球

事实证明以这几批拉玛西亚青训营出产的巴萨年轻球员为基础的巴塞罗那队是目前世界范围内实力最强的一支球队（六冠王可证明、新赛季的战绩可证明）。用极具中国特色的段子来描述巴萨，那就是：

巴萨代表着世界足球先进生产力的发展要求 – 拉玛西亚青训营
巴萨代表着世界足球先进技术理念的前进方向 – 控球与进攻
巴萨代表着世界最广大球迷们的足球利益 – 拥有世界范围内最多的球迷、最多的会员

双杀皇马，击沉阿森纳后，巴萨在双线（西甲、欧冠）卫冕道路上都一片光明。不过比赛还是要一场一场的踢，卫冕道路上荆棘依旧。相信瓜迪奥拉和他的弟子们会继续将每一场比赛都当决赛来踢，只有保持这样的态度对待比赛、对待对手，一切才能掌握在自己手中。

期待巴萨联赛卫冕！欧冠卫冕！

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

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

这个机制的实现也是逐渐“改”过来的。最初发现消费者进程退出时子线程长时间无法被唤醒导致无法及时退出，主线程因为要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机制，这里也建议慎用。直到目前也许还有一些例外情况我们还没能考虑周全呢。