先看一个较低的层次。如果从CPU的角度看，其实大部分的IO都是异步的：因为CPU启动这个IO操作后，就去干其它的事情了，一直到产生一个中断，告诉它IO完成了。
“Most physical I/O is asynchronous—the CPU starts the transfer and goes off to do something else until the interrupt arrives. User programs are much easier to write if the I/O operations are blocking—after a read system call the program is automatically suspended until the data are available in the buffer. It is up to the operating system to make operations that are actually interrupt-driven look blocking to the user programs.” （引自 Modern Operating Systems, 2ed）

不过，本文并不想探究那么底层的东东。作为程序员，更多的还是从应用层面来考虑。所以，以下重点介绍的是应用程序中能够采用的四种IO机制。
（说明，下文中图片引用自 http://www.ibm.com/developerworks/cn/linux/l-async/ ）

首先，从最常用到的，也是最容易理解的同步阻塞IO 说起。

在这个模型中，应用程序（application）为了执行这个read操作，会调用相应的一个system call，将系统控制权交给kernel，然后就进行等待（这其实就是被阻塞了）。kernel开始执行这个system call，执行完毕后会向应用程序返回响应，应用程序得到响应后，就不再阻塞，并进行后面的工作。
 

 
例如，“在调用 read 系统调用时，应用程序会阻塞并对内核进行上下文切换。然后会触发读操作，当响应返回时（从我们正在从中读取的设备中返回），数据就被移动到用户空间的缓冲区中。然后应用程序就会解除阻塞（read 调用返回）。”

 举一个浅显的例子，就好比你去一个银行柜台存钱。首先，你会将存钱的单子填好，然后交给柜员。这里，你就好比是application，单子就是调用的 system call，柜员就是kernel。提交好单子后，你就坐在柜台前等，相当于开始进行等待。柜员办好以后会给你一个回执，表示办好了，这就是 response。然后你就可以拿着回执干其它的事了。注意，这个时候，如果你办完之后马上去查账，存的钱已经打到你的账户上了。后面你会发现，这点很重要。

接下来谈同步非阻塞IO 。
先看这个图，

在linux下，应用程序可以通过设置文件描述符的属性O_NONBLOCK，I/O操作可以立即返回，但是并不保证I/O操作成功。
也就是说，当应用程序设置了O_NONBLOCK之后，执行write操作，调用相应的system call，这个system call会从内核中立即返回。但是在这个返回的时间点，数据可能还没有被真正的写入到指定的地方。也就是说，kernel只是很快的返回了这个 system call（这样，应用程序不会被这个IO操作blocking），但是这个system call具体要执行的事情（写数据）可能并没有完成。而对于应用程序，虽然这个IO操作很快就返回了，但是它并不知道这个IO操作是否真的成功了，如果想知道，需要应用程序主动地去问kernel。

这次不是去银行存钱，而是去银行汇款。同样的，你也需要填写汇款单然后交给柜员，柜员进行一些简单的手续处理就能够给你回执。但是，你拿到回执并不意味着钱已经打到了对方的账上。事实上，一般汇款的周期大概是24个小时，如果你要以存钱的模式来汇款的话，意味着你需要在银行等24个小时，这显然是不现实的。所以，同步非阻塞IO在实际生活中也是有它的意义的。

再来谈谈异步阻塞IO 。
在linux中，常常通过select/poll来实现这种机制。

 
以图为例，
和之前一样，应用程序要执行read操作，因此调用一个system call，这个system call被传递给了kernel。但在应用程序这边，它调用system call之后，并不等待kernel返回response，这一点是和前面两种机制不一样的地方。这也是为什么它被称为异步的原因。但是为什么称其为阻塞呢？这是因为虽然应用程序是一个异步的方式，但是select()函数会将应用程序阻塞住，一直等到这个system call有结果返回了，再通知应用程序。也就是说，“在这种模型中，配置的是非阻塞 I/O，然后使用阻塞 select 系统调用来确定一个 I/O 描述符何时有操作。”
所以，从IO操作的实际效果来看，异步阻塞IO和第一种同步阻塞IO是一样的，应用程序都是一直等到IO操作成功之后（数据已经被写入或者读取），才开始进行下面的工作。异步阻塞IO的好处在于一个select函数可以为多个描述符提供通知，提高了并发性。

关于提高并发性这点，我们还以银行为例说明。比如说一个银行柜台，现在有10个人想存钱。按照现在银行的做法，一个个排队。第一个人先填存款单，然后提交，然后柜员处理，然后给回执，成功后再轮到下一个人。大家应该都在银行排过对，这样的流程是很痛苦的。如果按照异步阻塞的机制，10个人都填好存款单，然后都提交给柜台，提交完之后所有的10个人就在银行大厅等待。这时候会专门有个人，他会了解存款单处理的情况，一旦有存款单处理完毕，他会将回执交给相应的正在大厅等待的人，这个拿到回执的人就可以去干其他的事情了。而前面提到的这个专人，就对应于select函数。

最后，谈谈异步非阻塞IO 。
这个概念相对前面两个反而更容易理解一些。

 
如图所示，应用程序提交read请求的system call，然后，kernel开始处理相应的IO操作，而同时，应用程序并不等kernel返回响应，就会开始执行其他的处理操作（应用程序没有被IO操作所阻塞）。当kernel执行完毕，返回read的响应，就会产生一个信号或执行一个基于线程的回调函数来完成这次 I/O 处理过程。

比如银行存钱。现在某银行新开通了一项存钱业务。用户之需要将存款单交给柜台，然后无需等待就可以离开了。柜台办好以后会给用户发送一条短信，告知交易成功。这样用户不需要在柜台前进行长时间的等待，同时，也能够得到确切的消息知道交易完成。

从前面的介绍中可以看出，所谓的同步和异步，在这里指的是application和kernel之间的交互方式。如果application不需要等待 kernel的回应，那么它就是异步的。如果application提交完IO请求后，需要等待“回执”，那么它就是同步的。
而阻塞和非阻塞，指的是application是否等待IO操作的完成。如果application必须等到IO操作实际完成以后再执行下面的操作，那么它是阻塞的。反之，如果不等待IO操作的完成就开始执行其它操作，那么它是非阻塞的。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/historyasamirror/archive/2009/06/15/4270633.aspx

阻塞：没有收完数据函数不返回，线程也被挂起

异步：函数立即返回，通过事件或是信号通知调用者

非阻塞：函数立即返回，通过select通知调用者

这样看来异步和非阻塞有什么区别呢？

异步=非阻塞？

同步是在操作系统层面上，阻塞是在套接字上？

Reactor是同步 Proactor是异步？

回答：

同步、异步、阻塞和非阻塞的概念

　　在进行网络编程时，我们常常见到同步、异步、阻塞和非阻塞四种调用方式。这些方式彼此概念并不好理解。下面是我对这些术语的理解。

同步
　　所谓同步，就是在发出一个功能调用时，在没有得到结果之前，该调用就不返回。按照这个定义，其实绝大多数函数都是同步调用（例如sin, isdigit等）。但是一般而言，我们在说同步、异步的时候，特指那些需要其他部件协作或者需要一定时间完成的任务。最常见的例子就是 SendMessage。该函数发送一个消息给某个窗口，在对方处理完消息之前，这个函数不返回。当对方处理完毕以后，该函数才把消息处理函数所返回的 LRESULT值返回给调用者。

异步
　　异步的概念和同步相对。当一个异步过程调用发出后，调用者不能立刻得到结果。实际处理这个调用的部件在完成后，通过状态、通知和回调来通知调用者。以 CAsycSocket类为例（注意，CSocket从CAsyncSocket派生，但是起功能已经由异步转化为同步），当一个客户端通过调用 Connect函数发出一个连接请求后，调用者线程立刻可以朝下运行。当连接真正建立起来以后，socket底层会发送一个消息通知该对象。这里提到执行 部件和调用者通过三种途径返回结果：状态、通知和回调。可以使用哪一种依赖于执行部件的实现，除非执行部件提供多种选择，否则不受调用者控制。如果执行部 件用状态来通知，那么调用者就需要每隔一定时间检查一次，效率就很低（有些初学多线程编程的人，总喜欢用一个循环去检查某个变量的值，这其实是一种很严重 的错误）。如果是使用通知的方式，效率则很高，因为执行部件几乎不需要做额外的操作。至于回调函数，其实和通知没太多区别。

阻塞
　　阻塞调用是指调用结果返回之前，当前线程会被挂起。函数只有在得到结果之后才会返回。有人也许会把阻塞调用和同步调用等同起来，实际上他是不同的。对于同 步调用来说，很多时候当前线程还是激活的，只是从逻辑上当前函数没有返回而已。例如，我们在CSocket中调用Receive函数，如果缓冲区中没有数 据，这个函数就会一直等待，直到有数据才返回。而此时，当前线程还会继续处理各种各样的消息。如果主窗口和调用函数在同一个线程中，除非你在特殊的界面操 作函数中调用，其实主界面还是应该可以刷新。socket接收数据的另外一个函数recv则是一个阻塞调用的例子。当socket工作在阻塞模式的时候， 如果没有数据的情况下调用该函数，则当前线程就会被挂起，直到有数据为止。

非阻塞
　　非阻塞和阻塞的概念相对应，指在不能立刻得到结果之前，该函数不会阻塞当前线程，而会立刻返回。

　　对象的阻塞模式和阻塞函数调用
　　对象是否处于阻塞模式和函数是不是阻塞调用有很强的相关性，但是并不是一一对应的。阻塞对象上可以有非阻塞的调用方式，我们可以通过一定的API去轮询状 态，在适当的时候调用阻塞函数，就可以避免阻塞。而对于非阻塞对象，调用特殊的函数也可以进入阻塞调用。函数select就是这样的一个例子。

阻塞通信

--------------------------------------------------------------------------------

　　通过重叠通信和计算在许多系统能提高性能。由一个智能通信控制器自动地执行通信的系统是真实的。轻－重线索是取得这种重叠的一种机制。导致好性能的 一个可选的机制是使用非阻塞通信。一个阻塞发送开始调用初始化这个发送操作，但不完成它。在这个消息被从这个发送缓存拷出以前，这个发送开始调用将返回。 需要一个独立的“发送完成”调用完成这个通信，例如，检验从发送缓存拷出的数据。用适当的硬件，在发送被初始化后和它完成以前，来自发送者存储的数据转换 可以和在发送者完成的计算同时进行。类似地，一个非阻塞“接收开始调用”初始化这个接收操作, 但不完成它。在一个消息被存入这个接收缓存以前，这个调用将返回。须要一个独立的“接收完成”调用完成这个接收操作，并检验被接收到这个接收缓存的数据。 用适当的硬件，在接收操作初始化后和它完成以前，到接收者存储的数据转换可以和计算同时进行。非阻塞接收的使用虽着信息较早地在接收缓存位置被提供，也可 以避免系统缓存和存储器到存储器拷贝。

　　非阻塞发送开始调用能使用与阻塞发送一样的四种模式: 标准, 缓存, 同步和准备好模式。这些具有同样的意义。无论一个匹配接收是否已登入，能开始除“准备好”以外的所有模式的发送；只要一个匹配接收已登入，就能开始一个非 阻塞“准备好”发送。在所有情况下，发送开始调用是局部的：无论其它进程的状态如何，它立刻返回。如果这个调用使得一些系统资源用完，那么它将失败并返回 一个错误代码。高质量的MPI实现应保证这种情况只在“病态”时发生。即，一个MPI实现将能支持大数量挂起非阻塞操作。　　

　　当数据已被从发送缓存拷出时，这个发送完成调用返回。它可以带有附加的意义，这取决于发送模式。　

　　如果发送模式是“同步的”，那么只有一个匹配接收已开始这个发送才能完成。即，一个接收已被登入，并已和这个发送匹配。这时，这个发送完成调用是非 局部的。注意，在接收完成调用发生以前，如果一个同步、非阻塞发送和一个非阻塞接收匹配, 它可以完成。(发送者一“知道”转换将结束，它就能完成，但在接收者“知道”转换将结束以前)。　　

　　如果发送模式是“缓存”，并没有挂起接收，那么消息必须被缓存。这时，发送完成调用是局部的，而且无论一个匹配接收的状态如何，它必须成功。　　

　　如果发送模式是标准的，同时这个消息被缓存，那么在一个匹配接收发生以前，发送结束调用可以返回。另一方面，发送完成直到一个匹配接收发生才可以完成，并且这个消息已被拷到接收缓存。　　

　　非阻塞发送能被用阻塞接收匹配，反过来也可以。

　　给用户的建议. 一个发送操作的完成, 对于标准模式可以被延迟, 对于同部模式必须延迟, 直到一个匹配接收登入。这两种情况下非阻塞发送的使用允许发送者提前于接收者进行，以便在两进程的速度方面，计算更容忍波动。　　

　　缓存和准备好模式中的非阻塞发送有一个更有限的影响。一可能一个非阻塞发送将返回，而一个阻塞发送将在数据被从发送者存储拷出后返回。只要在数据拷贝能和计算同时的情况下，非阻塞发送的使用有优点。

　　消息发送模式隐含着由发送者初始化通信。当发送者初始化通信(数据被直接移到接收缓存, 并不要求排队一个挂起发送请求) 时，如果一个接收已登入，这个通信一般将有较低的额外负担。但是，只在匹配发送已发生后，一个接收操作能完成。当非阻塞接收等待发送时，没有阻塞接收，它 的使用允许得到较低的通信额外负担。（给用户的建议结束）。

利用MFC进行编程时，我们从对话框中利用GetWindowText得到的字符串是CString类型，CString是属于MFC的类。而一些标准C/C++库函数是不能直接对CString类型进行操作的，所以我们经常遇到将CString类型转化char*等等其他数据类型的情况。这里总结备忘于此！ 首先要明确，标准C中是不存在string类型的，string是标准C++扩充字符串操作的一个类。但是我们知道标准C中有string.h这个头文件，这里要区分清楚，此string非彼string。string.h这个头文件中定义了一些我们经常用到的操作字符串的函数，如：strcpy、strcat、strcmp等等，但是这些函数的操作对象都是char*指向的字符串。 而C++的string类操作对象是string类型字符串，该类重装了一些运算符，添加了一些字符串操作成员函数，使得操作字符串更加方便。有的时候我们要将string串和char*串配合使用，所以也会涉及到这两个类型的转化问题。 1.CString和string的转化 stringstr="ksarea"; CStringcstr(str.c_str());//或者CString cstr(str.data());初始化时才行 cstr=str.c_str();或者cstr=str.data(); str=cstr.GetBuffer(0); //CString -> string cstr.format("%s", str.c_str()); //string->CString cstr.format("%s", str.data()); //string->CString str = LPCSTR(cstr); //CString->string /*c_str()和data()区别是：前者返回带'\0'的字符串，后者则返回不带'\0'的字符串*/ 2.CString和int的转换 inti=123; CStringstr; str.format("%d",i);//int->CString 其他的基本类型转化类似 i=atoi(str);//CString->int 还有(atof,atol) 3.char*和CString的转换 CStringcstr="ksarea"; char* ptemp=cstr.getbuffer(0); char* str; strcpy(str,ptemp);//CString->char* cstr.releasebuffer(-1); char*str="lovesha"; CStringcstr=str;//char*->CString string类型不能直接赋值给CString 至于int与float、string与char*之间的转化可以使用强制转化，或者标准库函数进行。对于CString与其他类型的转化方法很多，但其实都殊途同归，朝着一个方向即将类型首先转化为char*类型，因为char*是不同类型之间的桥梁。得到char*类型，转化为其他类型就非常容易了。

主要有以下文章：
http://blog.csdn.net/bitxinhai/archive/2008/04/14/2292014.aspx
http://www.vczx.com/article/show.php?id=845
http://www.vczx.com/article/show.php?id=846