改善C#程序的建议7:正确停止线程

开发者总尝试对自己的代码有更多的控制。“让那个还在工作的线程马上停止下来”就是诸多要求中的一种。然而事与愿违,这里面至少存在两个问题:

第一个问题是:正如线程不能立即启动一样,线程也并不能说停就停。无论采用何种方式通知工作线程需要停止,工作线程都会忙完手头最紧要的活,然后在它觉得合适的时候退出。以最传统的Thread.Abort方法为例,如果线程当前正在执行的是一段非托管代码,那么CLR就不会抛出ThreadAbortException,只有当代码继续回到CLR中时,才会引发ThreadAbortException。当然,即便是在CLR环境中,ThreadAbortException也不会立即引发。

其次,正确停止线程,不在于调用者采取了什么行为(如最开始的Thread.Abort()方法),而更多依赖于工作线程是否能主动响应调用者的停止请求。大体机制是,如果线程需要被停止,那么线程自身就得负责开放给调用者这样的接口:Cancled,然后线程在工作的同时,还得以某种频率检测Cancled标识,若检测到Cancled,线程自己负责退出。

FCL现在为我们提供了标准的取消模式:协作式取消(Cooperative Cancellation)。协作式取消的机制就是上文提到的机制。下面是一个最基础的协作式取消的样例:

CancellationTokenSource cts =new CancellationTokenSource();
Thread t
=new Thread(() =>
{
while (true)
{
if (cts.Token.IsCancellationRequested)
{
Console.WriteLine(
"线程被终止!");
break;
}
Console.WriteLine(DateTime.Now.ToString());
Thread.Sleep(
1000);
}
});
t.Start();
Console.ReadLine();
cts.Cancel();

调用者使用CancellationTokenSource的Cancle方法通知工作线程退出。工作线程则以大致1000毫秒的频率一边工作,一边检查是否有外界传入进来的Cancel信号。若有这样的信号,则负责退出。可以看到,在正确停止线程的机制中,真正起到主要作用的是线程本身。样例中的工作代码比较简单,不过也足以说明问题。更复杂的计算式的工作,也应该以这样的一种方式,妥善而正确地处理退出。

协作式取消中的关键类型是CancellationTokenSource。它有一个关键属性Token,Token是一个名为CancellationToken的值类型。CancellationToken继而进一步提供了布尔值的属性IsCancellationRequested作为需要取消工作的标识。CancellationToken还有一个方法尤其值得注意,那就是Register方法。它负责传递一个Action委托,在线程停止的时候被回调,使用方法如:

cts.Token.Register(() =>
{
Console.WriteLine(
"工作线程被终止了。");
});

本建议中的例子使用Thread进行了演示,使用ThreadPool也是一样的模式,这里就不再赘述。后面我们还会讲到任务Task,它依赖于CancellationTokenSource和CancellationToken完成了所有的取消控制。   

 微信扫一扫,关注最课程(www.zuikc.com),获取更多我的文章,获取软件开发每日一练

之前的话题:

改善C#程序的建议6:在线程同步中使用信号量
改善C#程序的建议5:引用类型赋值为null与加速垃圾回收
改善C#程序的建议4:C#中标准Dispose模式的实现
改善C#程序的建议3:在C#中选择正确的集合进行编码
改善C#程序的建议2:C#中dynamic的正确用法
改善C#程序的建议1:非用ICloneable不可的理由
posted @ 2011-05-08 08:26  陆敏技  阅读(39736)  评论(13编辑  收藏  举报
Web Counter
Coupon for Contacts