问题标签 [actor]

理论上，是否有可能使用 Scala Actor 框架来进行类似于 JDK 7 的 Fork-Join 框架的异步分治计算？如果是这样，我如何用框架表达 FJ 问题 - 例如，教程合并排序概念？欢迎使用代码片段。

（我的想法是基于我在其他FJ 相关问题中获得的资源视频。）

对于受过Scala教育的人来说，这可能是一个简单的问题，但我仍然是初学者；）

我有一个基础演员，他将任务分派给多个工人演员，并将其结果回复到阻塞的外部调用！？

现在我不知道如何在阻塞调用中真正并行化工作角色，因为最后我必须回复（）。调用实体不是演员，只是一个普通的班级。

来自多代理系统（使用JADE在 Java 中开发）的学术背景，我只是外围地了解 Actor 并发范式。现在我已经开始探索 Scala，我不禁被 Agent 和 Actor 方法之间的相似性所震惊。

我很想在我的下一个研究项目中使用 Scala 的 Actor 库，而不是简单地调用 JADE 库，因为这将迫使我更深入地掌握该语言。此外，JADE 专注于根据行为定义一切，这对我的问题不是很合适。

高度自治的 Actor 和我缺少的 Agent 之间有什么根本不同吗？

我是新来的斯卡拉。在学习Actor的时候，我尝试过扩展它以节省一行def：

然后异常跟踪如下所示：

可能有许多替代方案可以做同样的事情，但我最好知道上面的代码不起作用的原因。

让演员睡觉的最佳方式是什么？我将参与者设置为想要维护数据库的不同部分（包括从外部来源获取数据）的代理。出于多种原因（包括不使数据库或通信超载和一般负载问题），我希望参与者在每个操作之间休眠。我正在看类似 10 个演员对象的东西。

演员将几乎无限运行，因为总会有新数据进入，或者坐在表中等待传播到数据库的其他部分等。这个想法是让数据库在任何时候都尽可能完整及时。

我可以用一个无限循环来做到这一点，并在每个循环结束时休眠，但根据http://www.scala-lang.org/node/242演员使用一个线程池，只要所有线程都被阻塞，它就会扩展. 因此，我认为每个参与者中的 Thread.sleep 都是一个坏主意，因为这会不必要地浪费线程。

我也许可以有一个有自己的循环的中心参与者，它在时钟上向订阅者发送消息（如异步事件时钟观察者）？

有没有人做过类似的事情或有什么建议？很抱歉提供额外（也许是多余的）信息。

干杯

乔

首先让我说，我有相当多的 Java 经验，但最近才对函数式语言感兴趣。最近我开始研究 Scala，这似乎是一种非常好的语言。

但是，我在Programming in Scala中一直在阅读有关 Scala 的 Actor 框架的内容，但有一件事我不明白。在第 30.4 章中，它说使用react而不是receive可以重用线程，这对性能有好处，因为线程在 JVM 中很昂贵。

这是否意味着，只要我记得 callreact而不是receive，我就可以启动任意数量的 Actors 吗？在发现 Scala 之前，我一直在使用 Erlang，而Programming Erlang的作者吹嘘自己毫不费力地生成了超过 200,000 个进程。我讨厌用 Java 线程来做这件事。与 Erlang（和 Java）相比，我在 Scala 中看到了什么样的限制？

另外，这个线程如何在 Scala 中重用？为简单起见，我们假设我只有一个线程。我开始的所有演员会在这个线程中按顺序运行，还是会发生某种任务切换？例如，如果我启动两个相互发送 ping-pong 消息的演员，如果他们在同一个线程中启动，我会面临死锁的风险吗？

根据Programming in Scala，编写actors 来使用react比with 更难receive。这听起来很合理，因为react不会返回。然而，这本书继续展示了如何react使用Actor.loop. 结果，你得到

对我来说，这似乎很相似

本书前面使用过。尽管如此，这本书还是说“在实践中，程序至少需要几个receive's”。那么我在这里错过了什么？除了回报，还有什么不能receive做的？react我为什么要关心？

最后，来到我不明白的核心：这本书一直提到 using 如何react使丢弃调用堆栈以重用线程成为可能。这是如何运作的？为什么需要丢弃调用堆栈？为什么当函数通过抛出异常 () 终止时可以丢弃调用堆栈react，而当它通过返回 ( receive) 终止时不能？

我的印象是，Scala 中的编程一直在掩盖这里的一些关键问题，这是一种耻辱，因为否则它是一本真正优秀的书。

鉴于我Actor从内部调用一个反应，这会阻止调用Actor还是仍在处理其他请求？

我现在已经使用 scala actor 编写了一些应用程序，并且我对人们如何处理或处理我遇到的一些问题感兴趣。

过多的消息类或！？

我有一个对用户操作做出反应并且必须导致某些事情发生的演员。假设它react是一条消息UserRequestsX(id)。我遇到的一个持续问题是，因为我想模块化我的程序，一个演员自己无法在不涉及其他演员的情况下完成动作。例如，假设我需要使用id参数来检索一堆值，然后需要通过其他一些参与者删除这些值。如果我正在编写一个普通的 Java 程序，我可能会执行以下操作：

这很简单。然而，使用演员这变得有点痛苦，因为我想避免使用 !?. 一个参与者对消息做出反应，ReportTrades(date)但它必须要求 aPersistenceActor进行交易，然后 aReportActor报告它们。我发现这样做的唯一方法是：

所以在我的PersistenceActor我有一个反应块：

但现在我有两个问题：

1. 我必须创建额外的消息类来表示相同的请求（即“报告交易”）。事实上，在这种情况下我有三个，但我可能还有更多 - 跟踪这些成为一个问题
2. 我应该怎么称呼第一条和第三条消息ReportTrades？将它们都称为是令人困惑的ReportTrades（或者如果我这样做，我必须将它们放在单独的包中）。本质上不存在overloading按val类型划分的类。

有什么我想念的吗？我可以避免这种情况吗？我应该放弃并使用!?人们是否使用某种组织结构来澄清正在发生的事情？

Because my first question was so long, I'm asking this as a separate question. It's another one about the architecture of an actor-based application.

Keeping track of message paths through an Application

Let's take a piece of Java code:

In this code I have 4 separate components and the interaction between them required for the procedure deleteTrades is well-defined. It's completely contained in the method deleteTrades.

Modelling this with Actors and replacing my 4 components with 4 separate actors, how do I keep track (in my mind) of what a procedure involves? Particularly if I'm avoiding using the !? operator, then it's likely that I'll be sending a message ConditionalDelete to my PermissionActor, which will be sending a message GetTradesAndDelete to my PersistenceActor which will then send further messages etc etc. The code to process a delete will be strewn across my application.

It also means that pretty much every actor needs a handle on every other actor (in order to forward messages).

As in my previous question, how do people deal with this? Is there a good modelling tool which lets you keep track of all this? Do people use !? Am I turning too many components into Actors?

我正在考虑在系统中使用 Actors 来包装一些存储（可以是数据库，也可以是内存中的集合）。我想这样做的原因是因为我不希望对商店的调用被调用它的代码阻塞，并且我打算推送大量消息。

演员的入站消息队列能否处理数十万条消息？在代码直接调用对象上的方法和将带有队列的参与者放在中间之间会有什么性能差异？

干杯

乔