写点什么

Ruby 中的 Concurrency、Actors 和 Rubinius——MenTaLguY 访谈

  • 2008-02-22
  • 本文字数:3366 字

    阅读完需:约 11 分钟

随着 Ruby 1.9 增加了纤程 Fibers(协同程序),以及最近 Erlang 和 Actors 的流行,一组少为人之的概念进入了 Ruby 的编程世界。为了了解 Ruby 世界中的并发程序,我们采访了 Ruby 社区的老会员 MenTaLguY 。他长期致力于 Ruby 中的并发程序和线程机制,例如 fastthread 库,通过 1.8.x 的 MRI 改进了线程机制。最近他还涉猎了 Rubinius 。另外他还是 JRuby 小组的成员。

InfoQ: 请介绍一下你的 Ruby 版 Actors 库?

MenTaLguY: 实际上,我写了两个 Actors 库(已经发布)。一个是 Omnibus 并发库,另一个是 Rubinius 标准库中的一部分。两者都是 Ruby 实现的 Actors 模型的,也就是由 Erlang 普及的并发模型。并发程序, 从代码并行运行的意义上讲,并不难做到。麻烦出现在当不同的控制线程需要共享同一个资源或者通信路径时。如果你对此不采用一些简单的正规模型来进行结构化,基本上就不可能写出正确的或者最起码有意义的代码,尽管他们表面上看起来能“工作”。

“Actors”就是一个正规模型。一个 actor 由一个信箱和一个线程组成。它很灵活,actor 线程可以等待信箱中出现特定种类的消息,然后“执行”相应的动作,另外也可能再发消息发给别的 actor。通过这种自动而显式的消息交换方式,线程可以由一种相对容易理解的方式来通讯。

InfoQ: 它与 Ruby 的线程体系或者 Ruby 中新的纤程 / 协程有什么关系?

MenTaLguY: 我的 actor 库只是简单地把每个 Ruby 线程都关联一个信箱,这样每个线程都有了一个 actor。但这并不是在 Ruby 中使用 actor 的唯一方式。而纤程只是单线程中的协同调度任务,而且你也可以基于 actor 来实现,就像 Tony Arcieri 在他的 Revactor 库中所做的那样。由于纤程比完全线程更轻量级,而且你无需担心抢占问题,因此他的方法很有优势。然而有时你还是需要用完全线程(有时 Ruby 标准库会迫使你使用它)。

Tony 和我曾进行了多次有益的设计讨论;计划让 actor 的实现尽量有好的兼容性,并提供简单的对象协议,让每个 actor 实现都可以使用这个协议。从外部看, actors 同样是多态的——你最终都会把消息提交给一个信箱。基本上不用关心它是到底一个线程还是一个纤程,或者是什么运行在另一个 Ruby 虚拟机上的东西。原则上,actor-duck 甚至还可以由一些 Erlang 进程来支持 (例如通过 Scott Fleckenstein 的 Erlectricity).

InfoQ: 我看到你最近对 Rubinius 库的一些贡献,例如这个对付Actor 。Actors 是用在Rubinius 中吗?

MenTaLguY: 并不是它的一部分(这也是我把它从内核移到标准库中的原因之一)。我认为对它是需求还不到那个程度。

InfoQ: Actors 或者用它们实现的信箱有没有可能被用于 Evan 最近在 Rubinius 加入的 Multi-VM IPC 的消息传递中?

MenTaLguY: Actors 并没有用于实现 MVM IPC 机制,但我们想在幕后使用 MVM IPC 来允许不同 VM 中的 actors 互相通讯。

InfoQ: 现在 Rubinius 线程体系处于什么样的开发状态?都用到了什么——用户线程、内核线程,还是两者的 m:n 混合?

MenTaLguY: 我们在 VM 中使用了用户线程,但每个 VM 都运行在不同的内核线程中。现在,如果你想使用所有的 CPU,就要为每个 CPU 建立一个或两个 VM。Evan 想要最终在 VM 中使用 m:n 模式,但在 Ruby 中还有许多技术难关需要克服。甚至 Ruby 1.9 依然在原生线程上裹足不前,所以实际上他们还是用户线程。

可能只有基于支持原生线程运行时(比如 XRuby、JRuby、IronRuby)的 Ruby 实现才完全支持原生线程。如果 MVM 可以做得更轻量级或者多 CPU 之间的通讯变得足够复杂(世界正日益变得 NUMA 化),原生线程就不会变得那么重要了。

但是,有一种情况无法摆脱原生线程:使用那些不支持异步操作的设计糟糕的 IO API。在这种情况下,你需要使用多原生线程,而不是使用多核。有时你还不得不选择一个专门的进程来等待阻塞调用来结束这些,你的其它代码也随之结束。

但愿将来我们能少看到这种 API。Tony 的 Revactor 库带来了一线希望:他用 actor 来对付 IO,因此你的代码执行可以被 IO 事件驱动,而不是干等着阻塞调用的到来,或者承受控制的变换而变成了巨大的状态机。现在,Revactor 库还用在 MRI 1.9 上,但我们有望移植它,或者在 Ruby 中实现一个类似的库。

InfoQ: Rubinius 好像有了很丰富的并发概念和工具——线程、actor、多虚拟机+消息传递 IPC 等等。

MenTaLguY: 从历史上看,在这一点上,并发是一个非常重要的东西,我想是受了 Rubinius 的影响。

InfoQ: 我注意到其中的一个工具是通道——它在 Rubinius 中扮演什么角色?(我注意到快速调试器使用通道来通知调试器线程等)

MenTaLguY: 通道是 Rubinius 中的基本通讯方式;其它所有方式都基于它。基本的并发模型差不多就是异步的 pi 演算去掉同步和一些诸如非确定性选择之类的公用扩展(需要仲裁通道操作)。我提倡使用 pi 演算通道是由于它的简单性,换句话说是由于它的高效性和可维护性。

现在,pi 演算已经可以很好地直接用于“局部的”(VM 内的)地方,但还不太好用于实现分布式的地方,因为在 pi 演算中,通道两端都是可活动的。由于写操作是异步的,你可以随心所欲地写。但对通道的读操作是同步的。当一个通道遇到多个读操作时,这些读操作必须集中进行。当这些操作互相距离遥远时,就很不妙。

这就是我对 actor 如何应对大规模情况感兴趣的一个原因。Actor 信箱的异步计算特性与通道有点相像,除了只有(异步的)写操作一端是单独可活动的;读操作一端被紧密绑定在一个特定的本地代理上,且不需要考虑“远距离”协调的问题。

InfoQ: Ruby 1.9 增加了纤程和协程——它们是如何在 Rubinius 中实现的?

MenTaLguY: 我认为纤程在有了 Rubinius Tasks 之后实现起来并不麻烦;纤程和 Tasks 其实很相似。

InfoQ: 你对纤程和协程有什么见解和意见吗?你会使用他们吗——用来做什么呢?

MenTaLguY: 我认为他们可以很好地代替状态机,特别是协程令你更自由地使用库代码。不过,当状态机足够小或者在一些情况下,比如适合用 Ragel 之类地东西来产生它时,状态机仍是更好地选择。

InfoQ: 你现在拥有对 JRuby 的贡献权对吗?你对 JRuby 的兴趣在哪?或者说你致力于它的哪些方面?

MenTaLguY: 是的。我的主要兴趣是并发程序:Ruby 和原生线程的结合提出了一些有意思的挑战。因此我一直在修正并发程序的错误,并确定我们应该为并发程序提供怎样的保证。有可能的话我想最终把 Java 的并发程序的便利性引入 Ruby,希望通过移植的方式来进行(这也是 Omnibus Concurrency 库的一部分任务)。

InfoQ: 你还参与了其他什么项目吗?

MenTaLguY: 除了偶尔对 Shoes 打些补丁外,我从事一些未发布库的工作,其中大部分将会在准备好的时候发行和公布。这里可以讲讲我最近发行的一个库,尽管还没有正式公布:“case”gem 包。 它可以令 Ruby 的 case-match 运算支持数组、结构体和任意谓语的模式匹配。

<blockquote id="b39p">require 'rubygems'<br></br>require 'case'<br></br>Foo = Case::Struct.new :a, :b<br></br>def example(arg)<br></br> case arg<br></br> when Foo[:blarg, Object] # matches any Foo with .a == :blarg<br></br> # ...<br></br> when Foo[10, 20] # matches only a Foo with .a == 10 and .b == 20<br></br> # ...<br></br> when Foo # matches any Foo<br></br> # ...<br></br> when Case::Any[String, Array] # matches either a String or Array<br></br> # ...<br></br> # matches a three-element array with initial elements 1, 2:<br></br> when Case[1, 2, Object]<br></br> # ...<br></br> # matches any Integer > 10:<br></br> when Case::All[Integer, Case.guard { |n| n > 10 }]<br></br> # ...<br></br> end<br></br>end</blockquote>Tony 和我在我们的 actor 库中使用 case-match 运算符(===)来选择特定种类的消息去等待。因此。这个 gem 包在这里很有用。

欲详细了解 MenTaLguY,请访问他的博客 http://moonbase.rydia.net/ 或者关注他所参与的项目。要详细了解 Actors,请阅读最近对Tony Arcieri 的采访,他是Revactor 的开发者。 Revactor 是一个为高性能网络应用开发的应用程序框架。它面向 Ruby 1.9,并使用了诸如纤程的并发特性。关于 Rubinius 的详情,请参见 InfoQ 的 Rubinius 专题内容

查看英文原文: Ruby Concurrency, Actors, and Rubinius - Interview with MenTaLguY

2008-02-22 02:481280
用户头像

发布了 33 篇内容, 共 50274 次阅读, 收获喜欢 0 次。

关注

评论

发布
暂无评论
发现更多内容

java培训-JVM内存分配面试题分享

@零度

JVM JAVA开发

java版gRPC实战之三:服务端流

程序员欣宸

gRPC

java版gRPC实战之五:双向流

程序员欣宸

gRPC grpc双向流

java版gRPC实战之六:客户端动态获取服务端地址

程序员欣宸

gRPC grpc双向流

亚马逊云科技创新大会 | 云基础架构

亚马逊云科技 (Amazon Web Services)

架构

2.7万只!当前及未来仍将是量化交易的黄金期

非凸科技

rust 招聘 机器学习算法 算法交易

在线正则表达式大全测试

入门小站

工具

JavaScript数组,看这篇就ok了!

坚果

3月月更

TDengine 助力国产芯片打造“梦芯解算”,监测地质灾害 24 小时无间断

TDengine

数据库 tdengine 物联网

求职有 Pulsar | 中国联通、StreamNative 多个热招岗位

Apache Pulsar

开源 云原生 代码 Apache Pulsar 岗位招聘

web前端培训-MySQL的索引下推解析

@零度

MySQL 前端开发

大数据自动管理,24 小时服务无间断,StarRocks 如何做到?

StarRocks

大数据 数据分析 StarRocks

在线Javascript美化格式化工具

入门小站

工具

架构实战营-模块一-作业

CityAnimal

架构实战营 #架构实战营 「架构实战营」

面试突击35:如何判断线程池已经执行完所有任务了?

王磊

Java java面试

100行代码实现HarmonyOS“画图”应用,eTS开发走起!

HarmonyOS开发者

HarmonyOS ETS ArKUI 3.0

一文带你了解 Python 中的生成器

踏雪痕

Python 生成器 3月程序媛福利 3月月更

融云猿桌派:35 岁程序员,正值当打之年,尚有星辰大海

融云 RongCloud

程序员

超分算法在 WebRTC 高清视频传输弱网优化中的应用

融云 RongCloud

PyTorch

基于服务网格的分布式 ESB, 实现应用无关的传统 ESB 转型升级

BoCloud博云

微服务 ESB

TiDB 在携程 | 实时标签处理平台优化实践

PingCAP

开放报名丨《音视频社交新风口》线上峰会,聚焦海外社交生态升级

融云 RongCloud

java版gRPC实战之四:客户端流

程序员欣宸

gRPC grpc双向流

Linux下TCP网络编程-创建服务器与客户端

DS小龙哥

3月月更

《LeetCode刷题报告》题解内容 Ⅲ

謓泽

3月月更

Linux之file命令

入门小站

Linux

java版gRPC实战之二:服务发布和调用

程序员欣宸

Java gRPC

一个服务器轻松存储上亿数据,TDengine 在北京智能建筑边缘存储的应用

TDengine

数据库 tdengine 物联网

java版gRPC实战之七:基于eureka的注册发现

程序员欣宸

gRPC 注册中心 eureak

《2022网络威胁形势研究报告》重磅发布 | 附下载

青藤云安全

云效持续交付流水线,免费还好用!

阿里云云效

云计算 阿里云 持续集成 持续交付 持续交付流水线

Ruby中的Concurrency、Actors和Rubinius——MenTaLguY访谈_Ruby_Werner Schuster_InfoQ精选文章