Ruby 1.9加入纤程实现轻量级并发(转)

这是关于纤程的介绍和引入Ruby的一些讨论，帮助理解纤程，也可以看看对应的一些影响。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

 

Ruby的线程成为人们的讨论议题已经很长时间 了。未来版本的Ruby（1.9及更高）是否将使用内核线程（kernel thread）替代用户线程（userspace threads），仍有待决定。最近，关于Ruby中这一系列问题的另一条途径已经出现。David Flanagan指出了Ruby 1.9分支中的一个新特性——纤程（Fiber） ：

下面是如何使用新的Fiber类（注意：类名可能会改变）生成（generate）一个Fibonacci数的无穷序列的范例。我使用“生成 （generate）”这个词采用的是在Python中生成器（generator）的意义上的含义。Ruby中新的纤程是半协程（semi- coroutines）。

1  fib = Fiber.new do
2    x, y = 0, 1
3    loop do
4      Fiber.yield y
5      x, y = y, x + y
6    end
7  end
8  20.times { puts fib.resume }

这段代码会打印出前20个Fibonacci数。它使用了一个叫做协程（Coroutine） 的概念。基本上，调用Fiber.yield 方法会停止（“挂起”）这段代码的执行（请不要把它和用于执行block的yield 关键字相混淆）。如果你熟悉调试器，那么请想象一下对某个线程点击“挂起”按钮或者看这个线程因为断点命中而中断。fib 是这个纤程的句柄，你可以用它对纤程进行操作。在第8行出现的fib.resume 所完成的正是该代码所表达的意思：它恢复了Fiber.yield 调用之后语句的执行，使该纤程恢复执行状态。

第4行显示了Fiber.yield 带着一个参数y 被调用。在某种程度上，这可以被认为是与return y 相类似。子程序（subroutine）的return 和协程的Fiber.yield 之间的区别在于代码调用后其上下文发生的变化上。这就是说，return 的意思是一个函数调用的激活格局（或者叫做栈格局）被取消分配了（deallocate），即所有的本地变量都消失了。在一个协程里，yield 保存着这个激活格局并且其内部的所有数据还是存在的，因此在调用了resume 方法之后，代码还能继续使用这些环境。

现在这段代码如何工作就变得很清晰了：它只是一个循环——通过相继迭代的方式计算出Fibonacci熟。一旦完成一次计算，它就将自己挂起，并将 CPU的控制权让给别人。当代码性药序列中的下一个数时，它只需要恢复Fibonacci代码，代码运行下一次迭代，然后通过调用Fiber.yield 将自己挂起让出控制权（以及下一个Fibonacci数）。

这是在Ruby 1.9分支中加入的一个相当新的特性，而看起来它的细节仍未确定。纤程这个术语对于Windows程序员来说，可能并不陌生。MSDN中是这么解释的 ：

纤程是一个必须由应用程序手动调度的执行单位。纤程运行在调度线程的上下文中。每一个线程可以调度多个纤程。一般来说，纤程所能带来的优势是不及一个设计优良的多线程应用的。但是，对于被设计成必须调度自身线程的应用程序来说，使用纤程可以让它们的移植变得更为容易。

Ruby 1.9 VM（以前被称作YARV ）的开发者笹田耕一（Sasada Koichi） ，就此在ruby-core邮件列表中给出了更详细的一些信息 ：

这些方法名（resume/yield）来自Lua。“transfer”来自Modula-2，“double resume error”来自Python生成器。顺便说一句，我正在考虑使用“纤程（Fiber）”这个名字。目前“纤程”的意思等同于“半协程（Semi- Coroutine）”。Fiber::Core就是协程。是的，“纤程”这个名字是来自于微软，但是它的意义等价于半协程，如Lua的协程和 Python的生成器。

半协程 是不对称（asymmetric）协程 ，在它们对控制权传递的选择上收到限制。不对称协程只能将控制权传递回 它们的调用者，而对于协程来说，只要它们有相应的句柄，它们就可以自由地将控制传递给其它的任何一个纤程。

前面的例子展现了一个半协程是如何被当成一个生成器来用的。比如，便利地生成Fibonacci数。某些语言，比如Python，在语言中支持生成 器且有特定的语法支持。从引文中看来，似乎半协程（纤程）和协程（Fiber::Core）行为都是支持的。最终Ruby 1.9及以后的版本中会出现什么以及它会如何命名尚待分晓，但是Ruby语言的创造者松本行弘（Matsumoto, Yukihiro）认为他们安全：

在核心开发人员之间仍然有热烈的讨论，但是纤程（和外部迭代器）比起Continuation，更可能留在最终的1.9中。

注：Continuation，一个长期在Ruby 1.9分支中缺席的特性。尽管对于它是否可以使用Ruby 1.9的核心线程实现，人们尚存疑虑，但在五月份它仍被加到Ruby 1.9中 。

除了实现了控制结构，协程提供了一种使用轻量级并发（lightweight concurrency） 的方式。实际上它们允许使用协同调度来实现用户线程。协程既能将控制权让给彼此，也能通过将控制权交给调度协程，让其决定下一个调度的协程这种方式来实现集中式调度。

这样，关于Ruby 1.9转向更为重量级的内核线程的疑虑，就迎刃而解了。Ruby 1.8线程被构建成一个用户线程系统，这样做的好处是线程管理的开销更少。创建一个内核线程要进行对操作系统的系统调用，比起对线程系统的进程内调用要费 时得多。例如，JRuby使用内核线程，但也在尝试使用线程池来弥补创建开销的性能不足。

然而，创建大量的内核线程仍旧有许多性能开销，或者会直接导致对线程有硬性数量限制或者对大量线程的支撑力不从心的操作系统出现问题。在这些情况 下，一个轻量级的选择是非常有用的。如果解决方案在逻辑上可行而又简洁的话，它允许代码分配在不同的线程中执行，并且保持低水平的开销。这个方案的另一个 优点是，如果需要调用一个长时间运行的操作或者进行一次系统调用，但又不能阻塞进程中所有代码的执行，那么仍然可以使用内核线程。

Erlang采用了一个相似的方法，它也提供轻量级进程，但Erlang的进程不共享任何东西，与之相反，纤程共享同一个地址空间。然而，线程的存在使得人们可以采用参与式（Actor-style）的编程方式，而不需要担心额外性能开销。

在Ruby领域，纤程的概念也不是全新的。Rubinius拥有Tasks，其描述和Ruby 1.9的纤程类似。（InfoQ最近有一篇新闻报导采访了Rubinius项目的领导人Evan Phoenix对Rubinius中这种线程模型的观点 ）。MenTaLguY就此在ruby-core上详细描述说 ：

不过，在现代的并发环境中，它们[纤程]变得越来越有用。没有它们或者和它们相似的东西（比如Rubinius的Tasks），你就得用一些丑陋的技巧才 能实现轻量级并发了——你可以看看在Scala的actors类库中明确地使用continuation-passing（指函数，而不是 Continuations），这就是它们还没有问世的时候，我们可以期望的最好的例子。

我同意，使用纤程会让JRuby的日子变得不是那么好过。

最后的评论提出了一个重要的观点。如果纤程被Ruby采用，那么对于Ruby在JVM和CLR上的实现，如JRuby、XRuby、 Ruby.NET或者IronRuby来说，将出现一个头疼的问题。现在，它们当中还没有一个支持Continuations，因为在这些虚拟机上操作或 者读取调用栈（callstack）是非常困难，或者几乎不可能实现的。是否需要实现Continuations是一个很有争议的问题，然而它好像并没有 给JRuby等带来什么大难题，因为它并没有广泛地应用在Ruby之中。在Ruby 1.8的标准库中，唯一的应用就是生成器的实现，但是，举例而言，在JRuby 1.0中没有使用Continuations也一样实现了此功能。

虽然可以避开这些问题来实现这些特性，但是问题在于这些迂回解决方法是否会引起性能下降。例如，如果调用栈必须在堆上仿真，而不是使用虚拟机的栈， 这样做可能引起性能的下降，或者会阻止（JIT）编译器的的优化操作。对于非对成协程的迂回解决方法会更容易一些，因为它们使用虚拟机的栈进行方法调用。 像C#这类的语言以这种方式实现了它们的迭代器（Iterator）特性，这些迭代器允许人们用和上面的示例代码相似的方式编写生成器。