首页 > 代码库 > pthread_setcanceltype 线程取消

pthread_setcanceltype 线程取消

取消线程:

   (1)一个线程可以调用pthread_cancel来取消另一个线程。 
   (2)被取消的线程需要被join来释放资源。 
   (3)被取消的线程的返回值为PTHREAD_CANCELED 

    有关线程的取消,一个线程可以为如下三个状态: 
         (1)可异步取消:一个线程可以在任何时刻被取消。 
         (2)可同步取消:取消的请求被放在队列中,直到线程到达某个点,才被取消。
         (3)不可取消:取消的请求被忽略。 
           默认状态下,线程是可同步取消的。 

     调用pthread_setcanceltype来设定线程取消的方式: 
               pthread_setcanceltype (PTHREAD_CANCEL_ASYNCHRONOUS, NULL); //异步取消、 
               pthread_setcanceltype (PTHREAD_CANCEL_DEFERRED, NULL); //同步取消、 
               pthread_setcanceltype (PTHREAD_CANCEL_DISABLE, NULL);//不能取消 

 取消的应用:

     一般来说,Posix的线程终止有两种情况:正常终止和非正常终止。线程主动调用pthread_exit()或者从线程函数中return都将使线程正常退出,这是可预见的退出方式;非正常终止是线程在其他线程的干预下,或者由于自身运行出错(比如访问非法地址)而退出,这种退出方式是不可预见的。 
     最经常出现的情形是资源独占锁的使用:线程为了访问临界资源而为其加上锁,但在访问过程中被外界取消,如果线程处于响应取消状态,且采用异步方式响应,或者在打开独占锁以前的运行路径上存在取消点,则该临界资源将永远处于锁定状态得不到释放。外界取消操作是不可预见的,因此的确需要一个机制来简化用于资源释放的编程。 

C代码  收藏代码
  1. pthread_cleanup_push(pthread_mutex_unlock, (void *)&mut);   
  2. pthread_mutex_lock(&mut);   
  3. /* do some work */   
  4. pthread_mutex_unloc(&mut);   
  5. pthread_cleanup_pop(0);   

 

    必须要注意的是,如果线程处PTHREAD_CANCEL_ASYNCHRONOUS状态,上述代码段就有可能出错,因为CANCEL事件有可能在pthread_cleanup_push()和pthread_mutex_lock()之间发生,或者在pthread_mutex_unlock()和pthread_cleanup_pop()之间发生,从而导致清理函数unlock一个并没有加锁的 mutex变量,造成错误。因此,在使用清理函数的时候,都应该暂时设置成PTHREAD_CANCEL_DEFERRED模式。为此,POSIX的Linux实现中还提供了一对不保证可移植的pthread_cleanup_push_defer_np()/pthread_cleanup_pop_defer_np()扩展函数,功能与以下代码段相当:

 

Java代码  收藏代码
  1. {   
  2.    int oldtype;   
  3.    pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED, &oldtype); //设置为同步取消,这样保证push和其他操作不能被打断   
  4.   pthread_cleanup_push(routine, arg);   
  5.   ...   
  6.    pthread_cleanup_pop(execute);   
  7.    pthread_setcanceltype(oldtype, NULL);   
  8. }   

 


资料来自: http://shaojiashuai123456.iteye.com/blog/1485843

      http://linux.die.net/man/3/pthread_setcanceltype

               http://blog.csdn.net/caianye/article/details/5912172

               http://www.cnblogs.com/forfuture1978/archive/2010/4/27.html