码迷,mamicode.com
首页 > 编程语言 > 详细

读书笔记—CLR via C#线程27章节

时间:2014-11-09 18:02:39      阅读:275      评论:0      收藏:0      [点我收藏+]

标签:winform   style   blog   http   io   ar   os   使用   sp   

前言

这本书这几年零零散散读过两三遍了,作为经典书籍,应该重复读反复读,既然我现在开始写博了,我也准备把以前觉得经典的好书重读细读一遍,并且将笔记整理到博客中,好记性不如烂笔头,同时也在写的过程中也可以加深自己理解的深度,当然同时也和技术社区的朋友们共享

同步IO执行过程,拿Read举例

  • 托管代码转变为本地用户模式代码,Read在内部调用Win32的ReadFile函数
  • ReadFile分配IRP(IO Request Packet)
  • IRP包括:一个文件句柄、文件偏移量、Byte[]数组
  • IO请求进入Windows内核模式,传递IRP,调用内核,根据设备句柄,内核将IRP分发给设备驱动的IRP队列
  • 线程在IRP队列里阻塞,硬件执行IO,不涉及到任何线程
  • 线程虽然变成睡眠,节省了CPU时间,但是依然浪费了空间(用户模式栈、内核模式栈、TEB等)
  • 硬件设备完成IO,Windows唤醒线程,把它调度给一个CPU
  • 线程从内核模式返回用户模式,再返回托管代码

同步IO的危害

  • 降低服务器响应能力和吞吐量
  • 浪费过多的系统资源(线程和内存)
  • 频繁的上下文切换
  • 线程池频繁创建更多的新线程、阻塞线程醒来时又是上下文切换

异步IO

异步IO的过程的区别在于,IRP请求在内核模式添加到硬盘驱动程序的IRP队列之后,线程不再阻塞,而是允许返回代码,线程立即返回。对回调方法调用的委托实际会在IRP中一路传递道设备驱动程序。硬件处理好IRP后,将IRP的委托放到CLR的线程池队列中。线程池线程提取完成的IRP,并调用回调方法。调用BeginXXX方法时,它构造一个对象来唯一标识IO请求,将请求加入Windows设备驱动程序队列,然后返回对IAsyncResult的引用。在内部CLR线程池使用IOCP来完成异步请求的绑定和发送

异步IO的好处

  • 降低资源使用率
  • 减少上下文切换
  • 提升GC性能和调试性能
  • 提高并发量和吞吐量

APM

某一些提供Begin和End方法接口的类,但不与硬件设备通信,这些方法的代码仅仅执行计算限制的操作。不能执行IO限制的操作,因此需要一个线程来执行这些操作

FLC中还有其他:文件流类、网络流类、数据库类、Webservice、WCF

基于传统的begin...,end...模式的异步实现,如果该实现是基于IOCP的话,那么它并不会阻塞在IO线程上。它的实现原理是将IO请求转换成IRP(IO Request Package)然后传递到硬件设备驱动的IRP Queue中,调用begin..方法的线程会立马返回,然后硬件驱动会去它的IRP Queue取出工作项执行,真正执行的时候也不会用到任何线程。当实现完之后会把irp逐层向上抛直到IOCP,然后会将其扔给threadpool,threadpool会选用一个IO线程执行begin...方法中传递的回调方法

委托的BeginInvoke方法在内部调用ThreadPool.QueueUserWorkItem将计算限制操作添加道CLR的线程池队列。最好将IAsyncResult返回调用者。
如果存在回调,执行完后会线程池线程不会回到池中,会调用回调

不建议:

  • 直接调用End,会阻塞
  • 要避免使用IAsyncResult的WaitHandle属性,会阻塞线程,可能造成线程池分配另一个线程
  • 查询IsCompleted,也不建议,会浪费CPU事件

建议

  • 总是调用End,而且只调用一次。(1.释放资源 2. 处理异常)
  • 调用End方法时应该和Begin方法相同的对象

异常

调用Begin抛异常时,表示异步操作没有进入队列,所以线程池线程不会调用传给Begin的任何回调方法。设备驱动程序向CLR线程池post已完成的IRP,并会在代表异步操作的IAsyncResult中放入一个错误码。线程池调用回调方法,传递Result,回调方法把Result传给恰当的End方法,End方法发现错误码会把它转换成恰当的Exception异常

一般关心从End方法调用抛出的异常

如果采用委托的方式异步调用某个没有返回值的方法, 那么,当你不调用EndInvoke时,你是不知道是否有异常抛出的

委托异步

委托的异步调用是将任务交给线程池的工作线程来执行的

对于delegate的begininvoke的异步实现是在threadpool里的线程来运行的,但是它是基于remoting的架构实现的。这点明显很费性能,所以最好不要用它

线程上下文切换

Context.Post方法将回调送到GUI线程队列中,允许线程池线程立即返回,Send也将回调送入GUI线程队列,但随后会阻塞线程池线程,但随后会阻塞线程池线程,知道GUI线程完成对回调方法的调用。注意,这些Context都在内部调用BeginInvoke(Post)或Invoke方法。EAP中还是用了AsyncOperationManager

EAP

用起来比较方便,但是它是由wiondows form团队开发的,主要是提供给winForm使用的,能很好地在winform开发中使用,但是它会在每次出发时产生EventArgs对象,会造成很多垃圾。其次,使用时间地方式来通知外面也是有性能损失的,对于delegate的调用比virtual方法地调用性能还要差

EAP的诸多限制,同时实现两个模式。支持EAP的类自动将应用程序模型映射到它的线程处理模型。在内部使用了SynchronizationContext类

backgroundworker这个组件本质还是通过delegate的begininvoke来做的(可以通过reflector来查看),所以也是不推荐使用的

BackgroundWorker用于执行异步的计算限制的工作。不用于执行IO限制的工作

EAP相较APM的缺点,1:包装损耗 2:实际订阅容易内存释放 3.错误处理不一致

APM与Task的转换

  • IAsyncResult APM转换为Task,通过Task.Factory.FromAsync<Response>。ask实现了IAsyncResult接口,可以兼容APM。Task封装了对End方法的调用
  • 将EAP转变为Task,在EAP的事件回调中针对TaskCompletionSource进行创建

.NET Framework 的异步编程模型

bubuko.com,布布扣

结语

我知道,Jeffrey Ritchter在线程章节花了很大的心血,但是书写时还是没有很好的归纳清楚,比如他用25章讲线程基础和线程的发展和历史背景,这OK无可厚非,但是26章和27章明显就有点没有章法了,他在26章的标题是计算限制的异步,讲线程池然后直接跳到TPL的部分(顺带讲了一下定时器),27章标题是IO限制的异步,可是实际上在讲APM和EAP。哎,所以导致我看书笔记也写的很凌乱,勿怪,仅仅作为自己的一个记录,罢了!

读书笔记—CLR via C#线程27章节

标签:winform   style   blog   http   io   ar   os   使用   sp   

原文地址:http://www.cnblogs.com/fecktty2013/p/4085577.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!