协程，即协作式程序，其思想是，一系列互相依赖的协程间依次使用CPU，每次只有一个协程工作，而其他协程处于休眠状态。协程可以在运行期间的某个点上暂停执行，并在恢复运行时从暂停的点上继续执行。
协程已经被证明是一种非常有用的程序组件，不仅被python、lua、ruby等脚本语言广泛采用，而且被新一代面向多核的编程语言如golang
rust-lang等采用作为并发的基本单位。
协程可以被认为是一种用户空间线程，与传统的线程相比，有2个主要的优点：
首先来简单回顾一下一些常用的网络编程模型。网络编程模型可以大体的分为同步模型和异步模型两类。
同步模型使用阻塞IO模式,在阻塞IO模式下调用read等IO函数时会阻塞线程直到IO完成或失败。同步模型的典型代表是thread per connection模型，每当阻塞在主线程上的accept调用返回时则创建一个新的线程去服务于新的socket的读/写。这种模型的优点是程序简洁，编写简单；缺点是可伸缩性收到线程数的限制，当连接越来越多时，线程也越来越多，频繁的线程切换会严重拖累性能。
异步模型一般使用非阻塞IO模式，并配合epoll/select/poll等多路复用机制。异步模型可以使一个线程同时服务于多个IO对象。异步模型的典型代表是reactor模型。在reactor模型中，我们将所有要处理的IO事件注册到一个中心的IO多路复用器中（一般为epoll/select/poll），同时主线程阻塞在多路复用器上。一旦有IO事件到来或者就绪，多路复用器返回并将对应的IO事件分发到对应的处理器（即回调函数）中，最后处理器调用read/write函数来进行IO操作。异步模型的特点是性能和可伸缩性比同步模型要好很多，但是其结构复杂，不易于编写和维护。在异步模型中，IO之前的代码（IO任务的提交者）和IO之后的处理代码（回调函数）是割裂开来的，虽然可以通过多线性来提供并发，但是又不得不通过安全队列或加锁的方式来保证逻辑层是单线程的。
协程为克服同步模型和异步模型的缺点，并结合他们的优点提供了可能：
首先简单认识一下调度器：一个线程运行一个调度器，可以在一个调度器上创建若干个协程。调度器负责调度这些协程。并且调度器在其内部维护了一个多路复用器（epoll/select/poll）。现在假设我们有3个协程A,B,C分别要进行数次IO操作。这3个协程运行在同一个调度器(线程)的上下文中，并依次使用CPU。协程A首先运行，当它执行到一个IO操作，但该IO操作并没有立即就绪时，A将该IO事件注册到调度器中，并主动放弃CPU。这时调度器将B切换到CPU上开始执行，同样，当它碰到一个IO操作的时候将IO事件注册到调度器中，并主动放弃CPU。调度器将C切换到cpu上开始执行。当所有协程都被“阻塞”后，调度器检查注册的IO事件是否发生或就绪。假设此时协程B注册的IO事件已经就绪，调度器将恢复B的执行，B将从上次放弃CPU的地方接着向下运行。A和C同理。这样，对于某个协程而言，我们采用的是同步的模型；但是对于整个调度器（线程）而言，实际上却是异步的模型。好了，原理说完了，我们来看一个实际的例子，echo server。
在这个例子中，我们将使用orchid库来编写一个echo server。orchid库是一个构建于boost基础上的 协程/网络IO 库。
echo server首先必须要处理连接事件，我们创建一个协程来专门处理连接事件：
typedef boost::shared_ptr<orchid::socket> socket_ptr; //处理ACCEPT事件的协程 void handle_accept(orchid::coroutine_handle co) { try { orchid::acceptor acceptor(co -> get_scheduler().get_io_service());//构建一个acceptor acceptor.bind_and_listen("5678",true); for(;;) { socket_ptr sock(new orchid::socket(co -> get_scheduler().get_io_service())); acceptor.accept(*sock,co); co -> get_scheduler().spawn(boost::bind(handle_io,_1,sock),orchid::minimum_stack_size());//在调度器上创建一个协程来服务新的socket。 //第一个参数是要创建的协程的main函数， //第二个参数是要创建的协程的栈的大小。 } } catch(boost::system::system_error& e) { cerr<<e.code()<<" "<<e.what()<<endl; } }
在上面的代码中，我们创建了一个acceptor，并让它监听5678端口，然后在"阻塞"等待连接到来，当连接事件到来时，创建一个新的协程来服务新的socket。处理套接字IO的协程如下：
在orchid中，协程的main函数必须满足函数签名void(orchid::coroutine handle)，如handle accept所示，其中参数co是协程句柄，代表了当前函数所位于的协程。
//处理SOCKET IO事件的协程 void handle_io(orchid::coroutine_handle co,socket_ptr sock) { orchid::tcp_ostream out(*sock,co); orchid::tcp_istream in(*sock,co); for(std::string str;std::getline(in, str) && out;) { out<<str<<endl; } }
IO处理协程首先在传入的套接字上创建了一个输入流和一个输出流，分别代表了TCP的输入和输出。然后不断地从输入流中读取一行，并输出到输出流当中。当socket上的TCP连接断开时，输入流和输出流的eof标志为会被置位，因此循环结束，协程退出。
orchid可以使用户以流的形式来操作套接字。输入流和输出流分别提供了std::istream和std::ostream的接口；输入流和输出流是带缓冲的，如果用户需要无缓冲的读写socket或者自建缓冲，可以直接调用orchid::socket的read和write函数。但是需要注意这两个函数会抛出boost::system _ error异常来表示错误。
细心的读者可能已经发现，handle io的函数签名并不满足void(orchid::coroutine handle)，回到handle accept中，可以发现，实际上我们使用了boost.bind对handle io函数进行了适配，使之符合函数签名的要求。
最后是main函数：
int main() { orchid::scheduler sche; sche.spawn(handle_accept,orchid::coroutine::minimum_stack_size());//创建协程 sche.run(); }
在上面这个echo server的例子中，我们采用了一种 coroutine per connection 的编程模型，与传统的 thread per connection 模型一样的简洁清晰，但是整个程序实际上运行在同一线程当中。
由于协程的切换开销远远小于线程，因此我们可以轻易的同时启动上千协程来同时服务上千连接，这是 thread per connection的模型很难做到的；由于整个底层的IO系统实际上是使用boost.asio这种高性能的异步io库来实现的，而且协程切换的开销非常小，所以能够达到很高的性能；在伸缩性方面，可以使用scheduler per cpu的方式，即为每个CPU核心分配一个调度器，有多少个CPU核心就建立多少个调度器。
总结:通过协程，我们可以在保持同步IO模型简洁性的同时，获得近似于异步IO模型的高性能和伸缩性。
原文：http://www.cnblogs.com/fuland/p/3736731.html