Wiki: 协程

红薯 发布于 2010/05/02 07:48
阅读 371
收藏 1

和子例程一样,协程也是一种程序组件。相对子例程而言,协程更加一般和灵活,但在实践中使用没有子例程广泛。协程源自 SimulaModula-2 语言,但也有其他语言支持。协程更适合于用来实现更熟悉的程序组件如合作式多任务,迭代器,无限列表和管道。由于协程不如子例程那样被普遍所知,最好对它 们作个比较。

目录:
1. 简单的对比和示例
2. 详细比较
3. 协程之常见用例
4. 支持协程的编程语言
5. 协程的替代者和实现
6. 参考
7. 另见

1. 简单的对比和示例

协程比子例程更一般化。子例程的起始处是惟一的入口点;协程的起始处是第一个入口点,在协程里,返回点之后是接下来的入口点。子例程的生命期遵循后进先出 (最后一个被调用的子例程最先返回);相反,协程的生命期完全由他们的使用的需要决定。

这里是一个简单的例子证明协程的实用性。假设你有一个生产者-消费者的关系,这里一个协程生产产品并将它们加入队列,另一个协程从队列中取出产品并使用 它。为了提高效率,你想一次增加或删除多个产品。代码可能是这样的:

var q := new queue

生产者协程

loop while q is not full create some new items add the items to q yield to consume

消费者协程

loop while q is not empty remove some items from q use the items yield to produce

每个协程在用yield命令向另一个协程交出控制时都尽可能做了更多的工作。放弃控制使得另一个例程从这个例程停止的地方开始,但因为现在队列被修改了所 以他可以做更多事情。尽管这个例子常用来介绍多线程,实际没有必要用多线程实现这种动态:yield语句可以通过由一个协程向另一个协程直接分支的方式实 现。

2. 详细比较

因为相对于子例程协程可以有多个入口和出口点,可以用协程来实现任何的子例程。事实上,正如 Knuth 所说:“子例程是协程的特例。”

每当子例程被调用时,执行从被调用子例程的起始处开始;然而,接下来的每次协程被调用时,从协程返回(或屈服)的位置接着执行。

因为子例程只返回一次,要返回多个值就要通过集合的形式。这在有些语言,如 Forth, 里很方便,而其他语言,如 C ,只允许单一的返回值所以就需要引用一个集合。相反地,因为协程可以返回多次,返回多个值只需要在后继的协程调用中返回附加的值即可。在后继调用中返回附 加值的协程常被称为产生器。

子例程容易实现于堆栈之上,因为子例程将调用的其他子例程作为下级。相反地,协程对等地调用其他协程,最好的实现是用 continuations(由有垃圾回收 的堆实现)以跟踪控制流程。

3. 协程之常见用例

协程有助于实现:

  • 状态机: 在一个子例程里实现状态机,这里状态由该过程当前的出口/入口点确定;这可以产生可读性更高的代码。
  • 角 色模型:并行的角色模型,例如计算机游戏。每个角色有自己的过程(这又在逻辑上分离了代码),但他们自愿地向顺序执行各角色过程的中央调度器交出 控制(这是合作式多任务的一种形式)。
  • 产生器: 它有助于输入/输出和对数据结构的通用遍历。

4. 支持协程的编程语言

由于 continuations 被用来实现协程,支持 continuations 的编程语言也非常容易就支持协程。

5. 协程的替代者和实现

到2003年,很多最流行的编程语言,包括 C 和他的后继,都未在语言内或其标准库中直接支持协程。(这在很大程度上是受基于堆栈的子例程实现的限制)。

有些情况下,使用协程的实现策略显得很自然,但是此环境下却不能使用协程。典型的解决方法是创建一个子例程,它用布尔标志的集合以及其他状态变量在调用之 间维护内部状态。代码中基于这些状态变量的值的条件语句产生出不同的执行路径及后继的函数调用。另一种典型的解决方案是用一个庞大而复杂的 switch 语句实现一个显式状态机。这种实现理解和维护起来都很困难。

在当今的主流编程环境里,线程是协程的合适的替代者,线程提供了用来管理“同时”执行的代码段实时交互的功能。因为要解决大量困难的问题,线程包括了许多 强大和复杂的功能并导致了困难的学习曲线。当需要的只是一个协程时,使用线程就过于技巧了。然而——不像其他的替代者——在支持 C 的环境中,线程也是广泛有效的,对很多程序员也比较熟悉,并被很好地实现,文档化和支持。在 POSIX 里有一个标准的良定义的线程实现 pthread.

5. 1. 用 C 的实现

C标准库里 的函数 setjmp和 longjmp可以用来实现一种协程。不幸的是,正如 harbison and Steele所述,“setjmp 和 longjmp 的相当得难以实现,程序员要对使用它作最少的假设。”这意味着如果没有留意 Harbison 和 Steele 的警告而在某个环境下使用了 setjmp 和 longjmp ,在其他环境下可能不能正常工作。更糟糕的是,错误的实现并非个例。

人们作了大量的尝试,在 C 里用子例程和实现协程,这些尝试有不同程度的成功之处。Simon Tatham的贡献(见下文)是这一方法的很好示例。他自己注解是对这一方法的限制所了很好的评价。这种方法的确可以提高代码段的可写性,可读 性,可维护性还是存在争议的。用 Titham 的话说:“当然,这一技巧破坏了这本书的每一个编码标准……[但是]任何试图牺牲算法明晰来确保语法清晰的编码标准都应该被重写。如果你的老板因为因为你 使用了这些技巧而解雇你,在保安把你从大楼里拖出来的同时不断地告诉他们上面那句话。

著名的实现:

5. 2. 用Python的实现

6. 参考

  • 高德纳. Fundamental Algorithms, Third Edition. Addison-Wesley, 1997. ISBN 0-201-89683-4. Section 1.4.2: Coroutines, pp.193-200.
  • C: A Reference Manual. Samuel P. Harbison and Guy L. Steele, Jr. Third edition; Prentice-Hall, 1991, ISBN 0-13-110933-2.
加载中
0
虫虫
虫虫

原创?

0
红薯
红薯

引用来自“虫虫”的帖子

原创?

没看到标题栏里的两个转贴的字啊??

0
虫虫
虫虫

引用来自“红薯”的帖子

引用来自“虫虫”的帖子

原创?

没看到标题栏里的两个转贴的字啊??

原文链接呢?

0
红薯
红薯

引用来自“虫虫”的帖子

引用来自“红薯”的帖子

引用来自“虫虫”的帖子

原创?

没看到标题栏里的两个转贴的字啊??

原文链接呢?

http://wapedia.mobi/zh/%E5%8D%8F%E7%A8%8B

返回顶部
顶部