UNIX上C 程序设计守则 信号与线程 下.docVIP

UNIX上C 程序设计守则 信号和线程 下 摘自桃源谷的blog：准则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个。 pthread_cancelpthread_setcancelstatepthread_setcanceltype而且,里面还有No other functionsare 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函数有点儿类似。用这个函数登录的回调函数来清除线程的数据和锁，就可以回避死锁了。 回避方法4：不要执行异步撤消处理 最后是、不要执行异步撤消处理。反而代之的是、 设计成不依赖使用异步撤消那样的处理不得不使用线程撤消的话，不做异步撤消而作延迟撤消的处理这是比较实际的做法，是我们值得推荐的。 *1：pthread_setcanceltype函数 *2：pthread_setcancelstate函数 *3：Solaris和HP-UX等 准则5：尽可能避免线程中做延迟撤销的处理 线程的异步撤消是指：一个线程发出中断其他线程的处理的一个动作延迟撤消因为是规格自由度比较高，所以根据OS和C库函数的版本它也有各式各样的动作要想在不同的环境下都能稳定的动作的话，就必须要详细调查运行环境