【发布时间】：2011-01-12 06:35:40
【问题描述】：
对于.net/c#，actors concurrency model 有什么好的实现吗？
我必须优化一个 c# 例程，我认为演员模型非常适合作为我的问题的解决方案。不幸的是，我只有 scala 实现方面的经验。
【问题讨论】：
标签： c# .net concurrency actor
【发布时间】：2011-01-12 06:35:40
【问题描述】：
.NET Actor 模型框架：
Proto.Actor
- 演员
- 虚拟演员
https://github.com/AsynkronIT/protoactor-dotnet
Akka.NET
- 演员
https://github.com/akkadotnet/akka.net
微软奥尔良
- 虚拟演员
【讨论】：
-
这个开源项目也有很好的前景github.com/louthy/language-ext // 记录过程 var logger = spawn
("logger", Console.WriteLine); // Ping 进程 ping = spawn ("ping", msg => { tell(logger, msg); tell(pong, "ping", TimeSpan.FromMilliseconds(100)); }); // Pong 进程 pong = spawn ("pong", msg => { tell(logger, msg); tell(ping, "pong", TimeSpan.FromMilliseconds(100)); }); // 触发 tell(pong, "start");
今天微软发布了 Azure Service Fabric，根据这张图，它实现了一个 Actor 编程模型：
更新：SDK 现已推出，video tutorial 也可用。
【讨论】：
也可以看看 Project Orleans Microsoft 对演员的处理方法。（上周发布）
这是项目网站： http://research.microsoft.com/en-us/projects/orleans/
这也是一个来自 build 2014 的精彩演讲作为介绍
使用 Orleans 在 Azure 中构建 Halo 4 的分布式云服务 http://channel9.msdn.com/Events/Build/2014/3-641
请注意，今天发布的下载位是 CTP。
奥尔良简介：http://felixnotes.com/orleans-microsofts-take-on-the-actor-pattern-in-net/
是的，它也是开源的：https://github.com/dotnet/orleans
【讨论】：
-
不幸的是，它将您与 Azure 联系在一起......
-
我认为它更适合与 Azure 一起运行（因为它来自 Microsoft），但不一定需要，但不是 100% 确定。
-
似乎连开发者都不确定 :) orleans.codeplex.com/discussions/543928
-
这三个中哪一个最合适？
如前所述，F# 的 MailboxProcessor 类提供了 Actor 模型的简单、直接的实现。 here 提供了有关如何使用它的精彩介绍。 F# 与 C# 的互操作性非常好，您可以使用发布不同消息的方法将代理包装在一个类中。对于代理将使用异步响应进行回复的情况，请参阅PostAndAsyncReply 方法。这将返回一个异步工作流，您可以将其转换为可以在 C# 中使用 Async.StartAsTask 方法等待的任务。
最后，如果您需要远程分发您的演员，我建议您查看Akka.NET，它同时提供 C# 和 F# API。
【讨论】：
Remact.Net 是我目前的项目。它使用 WebSockets 和 Json 进行远程参与者消息传递。 它对 C# actor 具有类型安全性，但也支持用 Java 脚本编写的基于浏览器的 actor 的动态类型。
我之前的项目是AsyncWcfLib。这是一个 C# 库，用于参与者在进程中或不同应用程序之间进行通信。远程消息传递使用 WCF。
Actor 目录服务可以在多个主机上发现 Actor。这些主机可以运行 Windows 或 Linux。
【讨论】：
刚刚注意到这个问题，并想添加一个更新的数据点。微软目前有一个半官方的项目，名为ActorFX。它是开源的并且仍在不断发展，但值得关注...
【讨论】：
FSharp.Actor
F# 的 Actor 框架。
举个例子：
let rec schizoPing =
(fun (actor:IActor<_>) ->
let log = (actor :?> Actor.T<_>).Log
let rec ping() =
async {
let! (msg,_) = actor.Receive()
log.Info(sprintf "(%A): %A ping" actor msg, None)
return! pong()
}
and pong() =
async {
let! (msg,_) = actor.Receive()
log.Info(sprintf "(%A): %A pong" actor msg, None)
return! ping()
}
ping()
)
向 'schizo' 演员发送两条消息会导致
let schizo = Actor.spawn (Actor.Options.Create("schizo")) schizoPing
!!"schizo" <-- "Hello"
!!"schizo" <-- "Hello"
输出：
(schizo): "Hello" ping
(schizo): "Hello" pong
【讨论】：
你也应该考虑PostSharp Actors
【讨论】：
您应该看看 MS Concurrency & Coordination Runtime (CCR) 和 Decentralized Software Services (DSS)，Robotic Studio 的一部分。
这些框架将允许您开发满足大多数参与者方法要求的松散耦合服务。
Axum 将是最合适的，不幸的是它仍处于某种 alpha/beta 阶段（更新它已在 2011 年 2 月被杀死）。我将它用于我的研究，并且必须说大方向很棒，并且具有巨大的潜力。
不是 C#，而是 C++ 是 Microsoft 的 Asynchronous Agents Library，它为您提供所需的所有功能。
好好看看 .NET 4 的 Parallel related features。
希望对你有帮助！
【讨论】：
-
我在这里找到了这个：code.google.com/p/retlang
-
感谢您的全面回答。
-
TPL 数据流包含用于 C# 上的代理/参与者的构建块
-
ccrdss 链接现在已失效-此处讨论了 TPL 数据流 (TDF)：msdn.microsoft.com/en-us/concurrency/default.aspx 和此处：msdn.microsoft.com/en-us/devlabs/gg585582（尽管我认为第二个链接迟早会失效。在发表此评论时，TDF 仍处于预览阶段。
-
TPL 数据流链接更新：msdn.microsoft.com/en-us/library/vstudio/…
NAct 是一个适用于 .NET 的演员框架，它采用非常易于使用的方法。 （免责声明：我写的）
两个参与者之间传递的消息只是两个对象之间的方法调用。您必须确保所有方法参数都是不可变的，并且是线程安全的。
它通过将对象包装在处理线程切换的代理中来工作。所有正常的 .NET 功能，尤其是事件，都得到了正确处理，因此您可以编写正常的代码，线程编组将自行发生。
甚至还有一个支持 C# 5 async/await 的分支。
【讨论】：
-
您是否会考虑花一些时间来扩展 Stact 而不是创建一个新框架？我很想看到你的异步思维更多地渗透到 Stact（我不是它的作者，但我真的很喜欢它）。
-
嗯，我很高兴 Actors 的任何实现都受到关注，但我仍然喜欢使用方法调用来实现它。将这些与使用 Stact 和 NAct 的（巧合相同的）代码示例进行比较：github.com/phatboyg/Stact/wiki/Samples-Ping-Pong 和 code.google.com/p/n-act/wiki/PingPong
-
我更喜欢消息传递语义，因为它是真实的，并且没有办法显示例如间歇性网络故障或在不明确的情况下通过发送消息的并发性和时钟轻松推理。如果我现在参与一个框架，我会扩展 F# MailboxProcessor，它已经工作得非常好 - 有监督者和更容易跨网络传递的消息。
-
我刚刚创建了EasyActor，其理念类似于NAct。与 Nact 的主要区别在于它支持从具有 Task
的参与者接收的结果，并且基于 Castle Core DynamicProxy 来拦截方法调用。原始性能测试还表明，乒乓球测试的性能提高了大约 40%。
状态
.Net 上的演员库。相当称职且经过良好测试。 TopShelf、MassTransit 和 NServiceBus.Host 的基础。
https://github.com/phatboyg/stact
包含抽象：
- 工作流，允许定义和执行复杂的状态驱动协议
- 通道，支持对象之间的消息传递
- 演员，包括打字和匿名演员
- Fibers，一种协作线程模型
- 路由
- 请求/回复
- 调度器
即将到来：
- 适当的主管层次结构
Chris 在撰写本文时正在积极开发。
概述：
开发并发应用程序需要一种不同于当前软件开发方法的方法，这种方法强调自治系统组件之间的并发性和通信。 Actor 模型定义了一个称为 Actor 的软件组件系统，它们通过交换消息（而不是在面向对象设计中调用接口上的方法）相互交互，产生一个系统，其中数据（而不是控制）流经组件以满足系统的功能需求。
Stact 是一个使用 .NET 中的 Actor 模型构建应用程序的库。主程序集 Stact.dll 是参与者库，包括在任何类型的应用程序中使用参与者模型所需的一切。还有其他支持框架，例如 Stact.ServerFramework，可用于通过套接字或 HTTP 公开参与者，从而允许使用参与者构建服务。
【讨论】：
-
刚刚在 Øredev 上看到@phatboyg 关于 stact 的演讲。很有前途
-
Stact 似乎不再积极开发了。
你考虑过 F# 提供的 T 的 MailboxProcessor 吗？
【讨论】：
我不知道 C# 的任何实现，但是 Microsoft 提供了一种基于 Actor 模型的全新编程语言。它叫Axum：
Axum（以前的代号为Maestro）是一种基于Actor模型的领域特定并发编程语言，由微软开发。它是一种基于 .NET 公共语言运行时的面向对象语言，使用类似 C 的语法，它是一种特定于领域的语言，旨在开发非常适合并发的软件应用程序部分。但它包含足够多的通用结构，因此无需为并发组件的顺序部分切换到通用编程语言（如 C#）。
【讨论】：
-
感谢您的回答。 Axum 似乎很有趣，但乍一看，我认为 c# 选项更适合我的问题。
-
不幸的是项目已被 MS 杀死
-
@CharlesB TPL DataFlow 库取代了这个，不是吗？
-
@EJoshuaS 我不知道