Ruby pre-1.9和Ruby 1.9线程之间有什么实际区别吗？

Question

我正在尝试理解1.9和1.9之前的Ruby线程（在标准的MRI实现中）之间的区别，但似乎就你可以用它们实现的好处而言，它们实际上是相同的。这是对的吗？

从我有限的理解：

• 1.9之前的线程是“绿色线程”，这意味着它们由Ruby解释器管理，而不是操作系统。这样做的一个结果是，您永远不会实现真正的并发性，因为您永远不会同时运行多个线程（即使您使用的是多核/多处理器系统）。 （但是，如果执行在不同线程之间切换，例如，如果某个程序运行而另一个程序正在等待I / O，则可以获得并发的外观。）
• 1.9线程是本机线程，这意味着它们确实由操作系统管理。如果没有全局解释器锁，这将允许Ruby同时运行多个线程（在多核/多处理器系统上）。但Ruby 确实有一个全局解释器锁，这意味着只有一个线程可以运行，所以你再次得不到真正的并发。 （但是如果执行在不同的线程之间切换，你仍然可以看到并发的外观。）

这是正确的，还是我错过了什么？ 1.9线程与1.9之前的线程（在MRI中）有什么好处？

Answer 1

我觉得有点愚蠢地提供这个作为答案，但你的描述完全符合我对情况的理解。

如果我们是对的，我应该补充说，以这种方式发展语言确实有意义。

请记住，functional编程，the Actor Model,和其他共享内存替代并行模型的要点是解决开发并行共享内存应用程序的极大困难。 ("Threads considered harmful.")

因此，对于Ruby来说，从无到有并行到并行的所有内容都会有太多的期望。

目前的做法似乎是建立机制，但要保持巨大的锁定。我认为将来，单独调试和测试的功能区域将被允许并行执行，因为它们接收细粒度锁和并发测试。

Answer 2

你的分析是完全正确的，ruby 1.9现在使用本机线程，但由于有全局解释器锁，你在红宝石代码中实际上没有得到任何东西。

在其他实现中已经有一些工作要改变它：

• JRuby已经删除了GIL（我不确定是否曾经开始使用GIL）但实施并不是100％与MRI兼容，主要是因为本机宝石如果你使用它们（JRuby没有允许C扩展名

• Rubinius 2.0将摆脱GIL并且现在应该接近完成的工作：预发布版本已经过测试并且已经很好用了。

编辑：ruby 1.9但是添加了Fiber，在特定情况下它可以是一个不错的选择，它们就像线程，但你是安排它们的人。

Edit2：2.0开发者版本上的rubinius新闻：http://rubini.us/2011/06/07/inside-rubinius-20-preview/

Answer 3

在1.9下，一个线程可以进行I / O，而另一个线程是doing CPU work。

  

我听到了一个常见的误解   在做的时候，Ruby固有地“阻止”   磁盘IO或进行数据库查询。在   现实中，Ruby切换到另一个   线程，只要它需要阻止   IO。换句话说，如果一个线程需要   等待，但没有使用任何CPU，   Ruby的内置方法允许另一种方法   等待线程使用CPU的同时   原始线程等待。

这对我没什么帮助，因为我不是受限于I / O，但对你来说这可能是个好消息。