具有并发访问对象共享缓存、scala.concurrent.Lock、react vs receive 的 Scala 演员答案

【问题标题】：Scala actors with concurrent acces to shared cache of objects, scala.concurrent.Lock, react vs receive具有并发访问对象共享缓存、scala.concurrent.Lock、react vs receive 的 Scala 演员
【发布时间】：2012-09-26 08:27:24
【问题描述】：

我正在编写一个软件，其中不同的参与者同时创建同一图表的部分。

图的节点通过类层次结构建模，层次结构的每个具体类都有一个伴生对象。

    abstract class Node
    class Node1(k1:Node, k2:Node) extends Node
    object Node1 {
      def apply(k1:Node, k2:Node) = ...
    }
    class Node2(k1:Node, k2:Node) extends Node
    object Node2 {
      def apply(k1:Node, k2:Node) = ...
    }
    ...

到目前为止一切顺利。

我们在创建时对节点执行结构哈希。也就是说，每个伴生对象都有一个 HashTable 存储节点实例，该节点实例以它们的构造函数参数为键，用于检测具有相同子节点的给定节点类的实例是否已经存在，并返回该实例而不是创建新实例。这可以避免内存爆炸，并允许进行需要恒定时间的节点相等测试（参考比较而不是图形比较）。使用 scala.concurrent.Lock 保护对该地图的访问。

但问题是 Lock 在 jvm 线程级别上运行，并且根据 Actor 的编码方式，它们可以分配在自己的 jvm 线程上，或者与其他几个 Actor 交错在同一个 JVM 线程中在这种情况下，结构哈希不再起作用（即，可以创建几个结构相同的节点，并且只有其中一个会存储在缓存中，结构相等性将不再起作用）。

首先，我知道这种结构化哈希架构违背了参与者无共享的理念，但出于性能原因，我们确实需要这种哈希来工作（恒定的时间相等性为我们带来了一个数量级的改进），但是有没有办法与将在参与者级别而不是 jvm 线程级别工作的参与者在共享资源上实现互斥？

我曾想过将节点伴侣封装在一个actor中以完全顺序化对工厂的访问，但这意味着要完全重写所有现有代码，还有其他想法吗？

谢谢，

【问题讨论】：

我认为您的问题需要更多代码。地图在哪里，你如何从演员那里访问它？

标签： scala shared-memory actor locks

【解决方案1】：

如果您已共享可变状态，请使用单个 Actor 来改变此状态。您可以让其他 Actor 读取，但让一个 Actor 负责写入。

【讨论】：