问题标签 [actor]

.net/c#的演员并发模型有什么好的实现吗？

我必须优化 ac# 例程，我认为演员模型非常适合作为我的问题的解决方案。不幸的是，我只有 scala 实现方面的经验。

我是一名 18 岁的实习生，我正在发现我非常喜欢的 scala :-)。为了熟悉 scala actor，我编写了一个带有一些齿轮和一个控制器的小型模拟。ActorApplication 以随机速度创建 N 个齿轮。控制器计算同步速度并启动齿轮执行器。齿轮逐步同步到这个给定的速度（1+或1-）。当所有齿轮都达到同步速度时，仿真结束。我在 scala 2.7.7 中开发了模拟 - 它按我的预期工作（见下面的输出）。但是，当我切换到当前的 2.8.0-SNAPSHOT 时，我发现了奇怪的行为。这是代码：

上面的代码在 scala 2.7.7 中生成如下输出：

您可以看到不同参与者（齿轮和控制器）的交替输出。但是，如果我更改为 scala 2.8，我会得到如下输出：

您可以看到交替的演员互动要少得多。我怀疑在齿轮工作时控制器被卡住了。有人可以解释这种行为吗？谢谢菲利普

更新：此问题包含一个错误，导致基准测试毫无意义。我将尝试一个更好的基准来比较 F# 和 Erlang 的基本并发功能，并在另一个问题中询问结果。

我正在尝试了解 Erlang 和 F# 的性能特征。我发现 Erlang 的并发模型非常吸引人，但出于互操作性的原因，我倾向于使用 F#。虽然开箱即用的 F# 没有提供像 Erlang 的并发原语这样的东西——据我所知，async 和 MailboxProcessor 只涵盖了 Erlang 做得好的一小部分——我一直在试图了解 F# 性能的可能性明智的。

在 Joe Armstrong 的 Programming Erlang 书中，他指出 Erlang 中的进程非常便宜。他使用（大致）以下代码来证明这一事实：

在我的 Macbook Pro 上，生成和杀死 10 万个进程 ( processes:max(100000)) 每个进程大约需要 8 微秒。我可以进一步增加进程的数量，但是一百万似乎相当一致地破坏了事情。

我对 F# 知之甚少，我尝试使用 async 和 MailBoxProcessor 来实现这个示例。我的尝试（可能是错误的）如下：

在 Mono 上使用 F#，启动和杀死 100,000 个演员/处理器每个进程花费不到 2 微秒，大约比 Erlang 快 4 倍。也许更重要的是，我可以扩展到数百万个进程而不会出现任何明显的问题。启动 1 或 200 万个进程仍然需要每个进程大约 2 微秒。启动 2000 万个处理器仍然是可行的，但会减慢到每个进程大约 6 微秒。

我还没有花时间完全理解 F# 如何实现异步和 MailBoxProcessor，但这些结果令人鼓舞。我做错了什么吗？

如果没有，Erlang 是否在某些地方可能会胜过 F#？有什么理由不能通过库将 Erlang 的并发原语带到 F# 中？

编辑：由于布赖恩指出的错误，上述数字是错误的。当我修复它时，我会更新整个问题。

我注意到两种“消息传递”的方法。一种我见过 Erlang 的使用，另一种来自 Stackless Python。据我了解，这就是区别

Erlang Style - 消息被发送并排队到接收进程的邮箱中。从那里他们以先进先出的方式被移除。一旦第一个进程发送消息，它就可以自由地继续。

Python 风格 - 进程 A 排队等待发送到进程 B。B 当前正在执行一些其他操作，因此 A 被冻结，直到 B 准备好接收。一旦 B 打开读取通道，A 发送数据，然后它们都继续。

现在我看到 Erlang 方法的优点是你没有任何阻塞的进程。如果 B 永远无法接收，A 仍然可以继续。但是我注意到在我编写的一些程序中，Erlang 消息框可能会充满数百（或数千）条消息，因为消息的流入量大于流出量。

现在我还没有用任何一种框架/语言编写过大型程序，所以我想知道你的经验是否与此有关，如果这是我什至应该担心的事情。

是的，我知道这是抽象的，但我也在寻找相当抽象的答案。

我对 Scala 中的标准 actor 库的理解存在问题。在下面的代码中，我创建了一个简单的 swing，它基本上应该测试它是否能够连接到 postgreSQL 服务器。然而，它并没有那么远，我使用 Actors 因为 UI 会在执行连接到数据库所需的工作时冻结。当我使用这条线时（意味着我使用演员而不是单个线程）

Swing 永远不会更新。但是，如果我将该行注释掉并使用接下来的三行。（意思是演员不会被使用）

Swing 将冻结，但大约 25 秒后，Swing 将更新。

我的模拟是使用演员和 Scala 2.8-Snapshot。在 Java JRE 1.5 中它运行良好——所有 40 个齿轮（参与者）同时工作。使用 Java JRE 1.6 只有 3 个齿轮同时工作。我在有和没有 GUI 的情况下对其进行了测试：两者都给出了相同的结果。

我的 GUI 模拟可在 github 上找到：http: //github.com/pmeiclx/scala_gear_simulation

也许你还记得我的第一个问题是演员。在解决了这些问题后，我为模拟做了一个 GUI，我得到了这个新的“奇怪”行为。

这是没有 GUI 的代码：

This program, after executing main(), does not exit.

Because of this unexpected side-effect, using actors can be viewed as intrusive.

Assuming the actors must continue to run until program termination, how would you do to preserve original behavior in all cases of termination?

我来自 Java，在那里我将Runnables 提交给ExecutorService由线程池支持的线程池。在 Java 中如何设置线程池大小的限制非常清楚。

我对使用 Scala 演员很感兴趣，但我不清楚如何限制并发性。

假设说，我正在创建一个接受“工作”的 Web 服务。作业随POST请求一起提交，我希望我的服务将作业排入队列然后立即返回202 Accepted——即作业是异步处理的。

如果我使用演员来处理队列中的作业，我如何限制同时处理的作业数量？

我可以想出几种不同的方法来解决这个问题；我想知道是否有社区最佳实践，或者至少有一些在 Scala 世界中有些标准的明确确立的方法。

我想到的一种方法是让一个协调器参与者来管理作业队列和作业处理参与者；我想它可以使用一个简单的 int 字段来跟踪当前正在处理的作业数量。但是，我确信这种方法会有一些问题，例如确保跟踪错误发生的时间以减少数字。这就是为什么我想知道 Scala 是否已经为此提供了一种更简单或更封装的方法。

顺便说一句，我不久前试图问这个问题，但我问得很糟糕。

谢谢！

对我来说，它们似乎是一回事，只是注册的过程被术语“演员”伪装了。

更新：

从那以后，我看到了我思维方式的错误。我想因为我是 Erlang 的新手，所以我在根本不属于他们的地方使用了演员（在某个地方是否有一个反模式名称？）

在 Erlang 中，消息发送者有什么方法可以等待响应，因此只有在处理完消息后才继续执行？

我的意思是这样的：

我知道可以通过发送发送者的 Pid 来进行回调，但是还有其他方法可以等待吗？