原文地址：http://d.hatena.ne.jp/yupo5656/20040724/p1

■[C++] UNIX上的C++程序设计守则 (4)

铁则4: 请不要做线程的异步撤消的设计

• 线程的异步撤销是指： 某个线程的执行立刻被其他线程给强制终止了
• 请不要单单为了让“设计更简单”或者“看起了更简单”而使用线程的异步撤消

咋一看还是挺简单的。但是搞不好可能会引起各种各样的问题。请不要在不能把握问题的实质就做出使用线程的异步撤消的设计！

在pthread的规格说明中，允许一个线程可以强制中断某个线程的执行。这就是所说的异步撤消。

线程的撤消有下面的两种方式。

• 方式1： 异步撤消(PTHREAD_CANCEL_ASYNCHRONOUS)
  • 撤销动作是马上进行的
• 方式2： 延迟撤销(PTHREAD_CANCEL_DEFERRED)
  • 撤消动作，是让线程的处理一直被延迟到撤消点才会去执行

还有，到底是用哪种撤消方式，不是撤消侧，而是被撤销侧能够决定的*1。另外，在被撤销侧也能够选择完全禁止撤消的这种方式 *2。

会造成什么问题呢

那么，让我看看乱用线程的异步撤消会引起什么问题呢。看过准则3的人可能会知道，在下面的脚本里，被撤销线程以外的任意一个线程会被死锁。

1. 线程1中调用malloc函数正在做内存分配的过程中，线程2异步撤消了线程1的处理
2. 线程1马上被撤销，但是malloc函数中的互斥锁就没有线程去解除了
3. 后面的任意一个线程如果再次调用malloc函数的话就会马上导致该线程死锁

在这个例子中使用了malloc函数，但是其他的危险函数还有很多。

反之，即使做了异步撤消也没有问题的函数也有少数存在的、我们把它们叫做「async-cancel safe函数」或者「异步撤消安全函数」。在一些商用UNIX*3中、OS提供的api函数的文档说明中有async-cancel safety的记载、但是在Linux(glibc)里就很遗憾，几乎没有相关的说明。

在这儿，参看规格(SUSv3)的话，会发现，、描述异步撤消安全的函数只有3个。

1. pthread_cancel
2. pthread_setcancelstate
3. pthread_setcanceltype

而且、里面还有"No other functions are required to be async-cancel-safe"这样的记载。因此，Linux的场合，如果在文档里没有记载成async-cancel safety的函数，我们还是把它假定成不安全的函数为好!

如何避免这些问题呢

在多线程编程中为了安全的使用异步撤消处理、有没有回避死锁的方法呢？我们试着想了几个。他们与准则3里的线程+fork的场合的回避策很相似。

回避方法1: 被撤销线程中，只能使用异步撤消安全函数

首先，被撤销线程中，只能使用异步撤消安全函数。但是这个方法

• 在规格说明中只有3个异步撤消安全的函数
• 这些以外的函数是不是异步撤消安全(商用UNIX)、因为没有说明文档我们不清楚(Linux)

中有以上的两点，所以这个回避方法几乎不现实。

回避方法2: 被撤销线程中，在做非异步撤消安全处理的过程中，再把撤消方式设置成「延迟」或者是「禁止」

第二个是，被撤销线程在做非异步撤消安全处理的过程中，把撤消方式再设定成「延迟」或者「禁止」。对于这个方法

• 就像方法1写的那样、要把我那个函数是异步撤消安全的一时还是挺麻烦的
• 在任意的场所并不能保证撤消动作会被马上执行
  • 例如，再设定成「延迟」后的一段时间内如果撤消发生时、某个正在阻塞的I/O函数是否能够被解除阻塞还是挺微妙的
  • 如果设定成撤消禁止的话，则撤消会被屏蔽掉

有上面样的问题、会导致「一精心设计撤消方式的替换，从一开始就使用延迟撤消还不够好」这样的结果。所以这几乎是不好的一个回避策。

回避方法3： 使用pthread_cleanup_push函数，登录异步撤消时的线程数据清除的回调函数

第三种则是，用pthread_cleanup_push函数、登录一个在异步撤消发生时的数据清除的回调函数。这和在准则3中介绍的pthread_atfork函数有点儿类似。用这个函数登录的回调函数来清除线程的数据和锁，就可以回避死锁了。

...但是，pthread_cleanup_push函数登录的回调函数，在「延迟撤消」的场合是不能被调用的。因此、这个回避方法对于异步撤消没有什么大的作用。

回避方法４： 不要执行异步撤消处理

最后是、不要执行异步撤消处理。反而代之的是、

• 设计成不依赖使用异步撤消那样的处理

或者

• 不得不使用线程撤消的话、不做异步撤消而作延迟撤消的处理

这是比较实际的做法，是我们值得推荐的。