MailboxProcessor使用指南？

我刚刚在F#中发现了MailboxProcessor并且它被用作"状态机"......但我对它们的推荐用法找不到多少.

例如...假设我正在制作一个有100个屏幕上敌人的简单游戏,我应该使用MailboxProcessor来改变敌人的位置和健康状况; 给我200个活跃的MailboxProcessor？

引擎盖下是否有任何聪明的线程管理？我应该尝试限制我拥有的活动邮箱处理器的数量,还是可以不断地敲打它们？

提前致谢,

JD.

1> Dmitry Lomov..：

---

用于敌人模拟的MailboxProcessor可能如下所示:

MailboxProcessor.Start(fun inbox ->
async {
  while true do
    let! message = inbox.Receive()
    processMessage(message)
})

它在等待消息到达(let! message =行)时不消耗线程.但是,一旦消息到达,它将消耗一个线程(在线程池上).如果您有100个邮箱处理器同时收到一条消息,它们都将尝试唤醒并使用一个线程.由于此处消息处理受CPU限制,因此100个邮箱处理器将全部唤醒并开始生成(线程池)线程.这不是一个很好的表现.

邮箱处理器擅长的一种情况是,有许多并发客户端都向一个处理器发送消息(想象几个并行的网络爬虫都下载页面并将结果下沉到队列中).屏幕上的敌人情况看起来不同 - 它是许多实体响应单个消息来源(玩家移动/时间刻度).

数千个邮箱处理器是一个很好的解决方案的另一个例子是I/O绑定的MailboxProcessor:

MailboxProcessor.Start(fun inbox ->
async {
  while true do
    let! message = inbox.Receive()
    match message with
    |  ->
         do! AsyncWrite("something")
         let! response = AsyncResponse()
         ...
})

在收到消息后,代理很快就会生成一个线程但仍需要跨异步操作维护状态.这在实践中可以非常好地扩展 - 您可以运行成千上万的这样的代理:这是编写Web服务器的好方法.

2> Brian..：

---

按照

http://blogs.msdn.com/b/dsyme/archive/2010/02/15/async-and-parallel-design-patterns-in-f-part-3-agents.aspx

你可以毫不犹豫地敲打它们.试试吧!他们使用ThreadPool.我没有尝试过这个实时的GUI游戏应用程序,但如果这个"足够好"我也不会感到惊讶.

---

邮箱在逻辑上是单线程的.因此,对一个盒子的400条消息只需要一个线程进行服务(串行).400个邮箱到400个邮箱将使用N个线程,其中N是ThreadPool选择的某个数字.我认为后者可能很好.在我看来,一个更大的潜在问题是"显着的开销",如果你的消息处理很简单(例如更新整数计数器),那么消息传递开销很大.如果你为每条消息做一些工作,那也不错.只需在每一行上编写一个小程序并进行测量,并亲自查看.

---

从理论的角度来看,大概是您正在使用邮箱来封装/序列化对某些可变状态的所有访问.从这个意义上讲,正确的范围是"围绕可变状态",在这种情况下,例如"每个敌人"可能是理想的.从实际的角度来看,这可能会带来很多开销,因此您可能会将更多内容集中到一个邮箱/消息处理中以分摊开销,这可能是以理论 - 理想因素为代价的.我会写出理想,衡量标准,然后在必要时进行修正.(如果有很多代码,原型基准是理想的第一,那么实验是作者的廉价人力.)

3> Jon Harrop..：

---

如果我使用邮箱处理器来改变敌人的位置和健康,我说我正在制作一个有100个屏幕上敌人的简单游戏; 给我200个活跃的MailboxProcessor？

我认为没有任何理由尝试使用MailboxProcessor它.串行循环可能更简单,更快捷.

引擎盖下是否有任何聪明的线程管理？

是的,很多.但它是否适用于异步并发编程(特别是可扩展的IO),而您的程序并没有真正做到这一点.

我应该尝试限制我拥有的活动邮箱处理器的数量,还是可以不断地敲打它们？

你可以毫不犹豫地敲打它们,但它们远没有优化,性能比串行代码差很多.

4> desco..：

---

也许这个或这个有用吗？