widows如何执行I/O操作
构造调用一个FileStream对象打开一个磁盘文件-----FileStream.Read方法从文件中读取数据(此时线程从托管代码转为本地/用户模式代码)----Read在内部调用win32ReadFile函数-----ReadFile分配一个小的数据结构（I/O请求包，简称IRP）----IRP请求结构初始化（包括：一个文件句柄，文件一个偏移量，一个byte[]数组地址，要传输的字节数，以及其他常规性内容）------初始化后ReadFile将线程从本地/用户模式代码转变为本地/内核模式代码，向内核传递IRP数据结构，调用windows内核-----windows内核根据IRP设备句柄windows内核知道I/O操作需要传送给哪些硬件设备------windows将IRP送给对应的设备驱动程序的IRP队列（每个驱动维护这自己的IRP队列）-------IRP到达的时候设备驱动程序将IRP信息传递给物理硬件设备上的电路板--完成
如果工作项被送入线程池的速度比一个线程处理它们的速度快，那么线程池可以创建额外的线程。例如，四核处理器，四个客户端请求可以同时在4个线程上同时运行。而且没有上下文切换。
线程池通过判断CPU是否饱和，来决定是否创建新的线程。
“I/O完成端口”（I/OCompletion Port）：CLR在初始化的时候创建一个I/O完成端口，当打开硬件设备的时候，设备科绑定到I/O完成端口。驱动程序便知道将完成IRP送到哪个队列中。
CLR没开始一次垃圾回收，CLR必须挂起进程中所有的线程。以保证垃圾回收速度变快。CLR必须遍历所有线程的栈来查找根(Root).
调试应用程序，遇到断点也会挂起调试程序中所有的线程。
CLR的异步编程模块（APM Asychronous Programming Model）
异步方式执行I/O操作，可以执行BeginXXX方法。所有的BeginXxx方法都返回一个实现了System.IAsyncResult接口的对象。调用BeginXxx方法时，会构造一个对象惟一来表示I/O请求，并将请求加入Windwos设备驱动程序的队列，然后返回对IAsyncResult对象的一个引用。
异步操作方式以EndXxx调用开始。在EndXxx和BeginXxx方法之间，只执行计算限制工作。I/O操作这些方法的“边界”处执行，所以线程永远不会阻塞。在每个方法之后，线程回到线程池中。等待处理网络响应。
AsyncEnumerator类
APM编程模型缺陷：1.代码分解多个回调方法 2.不能使用实参和局部变量 3.不能再另一个地方结束构造 4.很难实现其他功能
AsynEnumerator利用了C#迭代器语言功能解决上面问题。
应用程序及其线程处理模型
.netFramework支持不同的应程序模型。每个应用程序模型都可能引入自己的线程处理模型。
控制台应用程序和Windows服务没有引入任何种类线程处理模型。
GUI应用程序（windows窗体，wpf silverlight）引入一个线程处理模型。创建窗口线程是唯一能对那个窗口进行更新的线程。GUI线程是需要异步操作（鼠标，按键等）当异步完成时用一个线程池线程完成，而线程池线程不能负责显示更新过的UI。
SynchronizationContext类
SynchronizationContex派生对象负责将一个应用程序模型连接到他的线程处理模型。windows窗体应用程序，wpf和silverlight程序的GUI线程有一个和他关联SynchronizationContext派生对象。为了获取该对象的引用，可以让GUI查询SynchronizationContext的current属性，然后该对象引用保存到一个共享变量中。当一个线程池线程需要让GUI线程更新UI时，可以让引用保存的SynchronizationContext派生对象通过post方法传递GUI线程调用的方法。
APM注意事项
在 没有线程池的前提下使用APM
总是调用EndXxx方法而且只调用一次
调用EndXxx方法时总是用相同的对象
为BeginXxx和EndXxx方法使用ref,out,params实参
不能取消异步I/O限制操作
内存消耗
有的I/0操作必须同步完成
FileSteram特有的问题
I/O请求优先级
暂时的版本只能通过P/Invoke本地win32函数方式制定I/O优先级
将IAsyncResultAPM转换为Task
基于事件的异步模式(EAP)
EAP（Event-based Asynchronous Pattern）有点在于捅VS UI 设计器进行了很好的集成（winform的双击关联事件）。
将EAP转换为Task
APM和EAP对比
编程模型的沼泽