【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

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:481158
用户头像

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

关注

评论

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

Electron 插件开发实践

网易云信

c++ Electron

易仓跨境Saas全球租户,如何做到数据秒级响应?

阿里云大数据AI技术

数据库 flink SaaS

SaaS到底是什么?如何做?

小炮

SaaS

教你用 ECharts 轻松做一个Flappy Bird小游戏

华为云开发者联盟

图表 eCharts 图表库 Flappy Bird 小游戏

Java遇上SPL:架构优势和开发效率,一个不放过

华为云开发者联盟

Java stream 应用架构 SPL 结构化数据处理

直播预告丨OpenHarmony标准系统多媒体子系统之音频解读

OpenHarmony开发者

OpenHarmony 多媒体

解构HE2E中的Kubernetes技术应用

华为云开发者联盟

Docker Kubernetes DevOps HE2E CCE部署

作业帮在线业务 Kubernetes Serverless 虚拟节点大规模应用实践

阿里巴巴云原生

阿里云 云原生 客户案例 作业帮 Kubernetes Serverless

队列同步器AQS

急需上岸的小谢

5月月更

JavaScript数据类型

源字节1号

软件开发 前端开发 后端开发 小程序开发

ironSource 推出 Luna Views,通过定制化数据面板呈现多渠道广告效果

Geek_2d6073

PingCAP 宣布 TiDB Cloud 正式商用,助力全球企业在云上构建新一代云原生应用

Geek_2d6073

程序员转型产品经理:懂技术或许是把双刃剑!

博文视点Broadview

WorkPlus统一门户:企业信息互通,实现业务协作

WorkPlus

架构实战营之毕业总结

IT屠狗辈

架构实战营

下个十年高性能 JSON 库来了:fastjson2!

王磊

Java

TiDB Cloud GA,助力全球企业在云上构建新一代云原生应用

PingCAP

如何使用 Authing 单点登录,集成 Discourse 论坛?

Authing

低代码 单点登录 Idaas 应用集成方案 Discourse

Go 学习笔记——函数篇一

为自己带盐

Go 5月月更

集简云 x Authing,助力网校打通用户身份管理屏障

Authing

低代码 单点登录 业务流程优化 小鹅通

干货 | Authing 产品总监佟野:Authing 的产品打磨之路

Authing

身份认证 用户思维 2B 产品 用户旅程 产品功能设计

C语言-strlen和sizeof强化习题练习- I

芒果酱

c++ C语言 5月月更

uni-app技术分享| uni-app转小程序-实时消息

anyRTC开发者

小程序 uni-app 音视频 实时消息 呼叫邀请

2022年记一次慢查询优化指南,MySQL 优化学习第9天

梦想橡皮擦

5月月更

未来以体验为中心的数字化战略前景 已经变得愈发明朗

易观分析

精细运营 渠道融合

智能运维应用之道,告别企业数字化转型危机

云智慧AIOps社区

大数据 监控 数字化转型 智能运维 自动化运维

快慢缓急总相宜|ONES 人物

万事ONES

为什么前端不能没有监控系统?

杨成功

大前端 构架 5月月更

李东山——如何让OpenHarmony支持低功耗蓝牙芯片GR551x

OpenHarmony开发者

OpenHarmony 低功耗蓝牙芯片

一文,教你打造员工生命周期解决方案

Authing

单点登录 零信任 数据泄露 B2E 元气森林

招商蛇口重塑客户经营新思路,推动多业态融合升级

科技热闻

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