一种通用模拟器.pdf

一种通用模拟器
    【技术领域】
     本发明涉及计算机仿真领域， 特别涉及一种通用模拟器。背景技术 系统仿真是一种利用系统模型对真实系统或者假想系统进行实验， 通过对实验结 果进行分析， 研究系统运行状态及其随时间的变化过程， 得到系统的仿真输出参数和基本 特性， 以此估计和推断系统的特征和性能， 进而做出决策的一门实验性和综合性的学科。 系 统仿真基于系统模型， 系统模型根据特性可分为两大类， 一类是连续系统， 另一类是离散事 件系统。 两类系统模型的主要区别在于系统状态随时间的变化规律， 前者随时间连续变化， 后者只在某些离散时间点上发生改变。在离散事件系统模型中， 其状态的变化只发生在一 些离散的时间点上， 在相邻两个时间点之间状态不发生任何变化。引起系统状态变化的行 为被称为事件， 它是离散事件系统的核心和驱动力， 正是一个接一个事件的产生和处理推 动着离散事件系统的运行。
     随着计算机技术的发展， 利用计算机实现系统仿真得到普遍应用与推广， 这种在 计算机上实现的系统仿真被称为计算机模拟。 在计算机上运行的用于仿真某一系统的计算 机软件被称为模拟器， 自 1955 年第一个数值积分仿真软件问世以来， 已经出现了大量的、 多种类型的模拟器。但现有的模拟器大都针对特定的目标系统或领域， 例如进行计算机体 系结构模拟的 SimScalor， 进行计算机网络模拟的 NS2， 进行排队系统模拟的 GPSS。这些模 拟器针对其所针对的领域做了优化， 使得它能够在其领域范围内较好地模拟目标系统， 但 对于其它领域内的目标系统则很难进行模拟。 由此存在以下问题 ： 1、 增加了用户学习负担， 当用户需要模拟不同领域中的系统时， 需要学习不同领域中的模拟器 ； 2、 当所要模拟的目 标系统跨领域时， 难以整合不同的模拟器进行模拟。
     发明内容
     本发明的目的是克服现有模拟器只能模拟特定领域的目标系统， 通用性差的缺 陷， 从而提供一种通用性好的通用模拟器。
     为了实现上述目的， 本发明提供了一种通用模拟器， 包括模型派生实体模块、 交互 支持模块、 多线程并发执行模块、 分布支持模块以及虚拟主机模块 ； 其中，
     所述的模型派生实体模块包括多个模拟组， 每个所述的模拟组包括有多个模拟结 点， 所述模拟结点中包括由所要模拟的目标系统的功能单元封装而成的资源型实体 ； 所述 模拟组、 模拟结点和资源型实体都被称为模拟实体 ；
     所述交互支持模块实现了所述模型派生实体模块中所述模拟实体间的交互 ； 所述 模拟实体间的交互用事件表示 ；
     所述分布支持模块实现了将所述模型派生实体模块中的可迁移实体在不同主机 上的迁移 ；
     所述多进程并发执行模块实现了所述通用模拟器所在主机上的多个线程对同时发生事件的并发处理 ；
     所述虚拟主机模块用于抽象物理主机， 容纳所述通用模拟器中的各种实体， 辅助 所述分布支持模块来实现对分布的透明支持。
     上述技术方案中， 所述的模型派生实体模块还包括有用于对所要模拟的目标系统 进行监测和控制的系统实体， 所述系统实体包括用于监测所述模拟实体内部情况的探针， 以及用于控制所述通用模拟器的控制器 ；
     所述交互支持模块还实现了所述系统实体间以及所述系统实体与所述模拟实体 间的交互 ； 该交互用事件表示。
     上述技术方案中， 所述交互支持模块在处理模拟实体间的交互事件时， 根据所述 事件的目标地址将该事件分发到模拟实体中的资源型实体， 所述资源型实体调用相应的事 件处理器来处理该事件。
     上述技术方案中， 所述交互支持模块在处理系统实体间或系统实体与模拟实体间 的交互事件时， 将该事件分发到实现了接口 Invokable 的相应目标的 invoke 函数， 由该函 数进行处理。
     上述技术方案中， 所述交互支持模块还包括通过对所述资源型实体发出的事件依 次做按名装配与按名链接来解耦资源实体间的依赖关系 ； 其中，
     所述按名装配包括指定所述资源型实体发出的事件的目标以及指定该目标在接 收时的事件别名 ； 所述按名链接包括将所述资源型实体发出的事件发送到目标资源型实体 所在的模拟节点。
     上述技术方案中， 所述交互支持模块还包括用事件目标集来管理发出事件的事件 源到接收事件的事件目标之间的链接关系 ； 所述事件目标集包括对所述链接关系的描述， 以及按照策略所生成的事件链接关系。
     上述技术方案中， 所述交互支持模块采用同步事件交互方式处理事件。
     上述技术方案中， 所述的分布支持模块采用基于简化的对象代理方法来实现可迁 移实体在不同主机上的迁移 ； 其中，
     所述的简化的对象代理方法采用一名为存根的类， 该类为所述的可迁移实体在另 一主机上生成对应的存根对象， 所述的存根对象与所对应的可迁移实体相比具有同一模拟 结点、 同一模拟组 ； 对所述存根对象的调用会被转发到分布在其它主机上的对应可迁移实 体。
     上述技术方案中， 所述虚拟主机模块上保存有用于记录位于本地的可迁移实体的 实体表， 以及用于记录本地所用的所有存根对象的存根表 ； 所述虚拟主机模块根据所述实 体表与存根表创建、 获取、 销毁可迁移实体。
     上述技术方案中， 所述的多进程并发执行模块通过令牌分发与回收机制实现多线 程对同时发生事件的并发处理。
     本发明的优点在于 ： 通用性好， 适用范围广， 能够对不同领域的目标系统进行模 拟。 附图说明
     图 1 为本发明的通用模拟器在一个实施例中的结构示意图 ；图 2 为本发明中所涉及的系统抽象模型的示意图 ； 图 3 为本发明中所涉及的交互事件的类型图 ； 图 4 为可迁移实体以及可迁移实体所对应的 Stub 对象的示意图 ； 图 5 为不同主机间服务分布的示意图 ； 图 6 为令牌分发与回收的过程示意图。具体实施方式
     下面结合附图和具体实施方式对本发明加以说明。
     模拟器所要完成的工作是在计算机上实现对目标系统的仿真。 虽然目标系统有不 同的类型， 但通过分析， 不同类型的目标系统都可以抽象出以下要素 ：
     1、 实体。实体是指具有内部逻辑并可与外部进行交互的独立存在物， 例如 CPU、 RAM、 主机、 软件模块等。
     2、 实体间的交互方式， 如共享总线、 网络通道、 消息传递机制等。
     3、 实体间的组织关系， 例如将实体按物理区域划分为组， 用多个实体组成新的更 大的实体， 如实体 CPU、 RAM 等组成一个计算机实体。 模拟器在模拟目标系统的过程中需要体现上述元素。此外， 考虑到用户对模拟器 分布性、 并发性和可监控性的需要， 模拟器还应具有以下特性 ：
     4、 实体的分布和并发性， 模拟器中被模拟的实体应该能够以某种粒度被分布到不 同的计算机中， 并被并行地加以模拟。
     5、 被模拟的实体应该能够被检测和控制。
     上述内容是各个模拟器都应具备的基本特性。 本发明要实现一种能够适用于多种 类型的目标系统的通用模拟器， 因此在本发明的通用模拟器中也应当具备上述特性。需要 特别指出的是， 本发明的通用模拟器能够完成模拟器的基本功能， 但若要将该通用模拟器 应用于某一具体的目标系统， 则还要根据所述目标系统在所述通用模拟器的基础上添加少 量的技术内容。下面对本发明的通用模拟器的基本结构加以说明。
     本发明的通用模拟器包括模型派生实体模块、 交互支持模块、 多线程并发执行模 块、 分布支持模块以及虚拟主机模块。其中， 模型派生实体模块分别与交互支持模块、 多线 程并发执行模块相连， 所述的交互支持模块、 多线程并发执行模块分别连接到分布支持模 块上， 通过该模块与其它主机上的虚拟主机模块进行通信， 通用模拟器中的其它模块都在 虚拟主机模块上运行。在下文中将分别对各个模块的功能做具体的说明。
     虚拟主机模块 (Virtual Host)
     虚拟主机模块用于抽象物理主机， 该模块至少包括两个功能， 一是作为容器容纳 模拟器中的各种实体， 二是辅助分布支持模块实现对分布的透明支持。当在每个主机上启 动一个虚拟主机模块后， 即可在其中生成各种实体。 在生成可迁移实体时， 虚拟主机模块将 其告知分布支持模块， 使之能够保持系统视图的一致性。 当访问可迁移实体时， 若目标实体 不在本虚拟主机模块中， 则虚拟主机模块会将相应的请求转发给分布支持模块， 最终完成 该请求。 与虚拟主机模块有关的上述操作过程会在下文中相关模块的描述中做进一步的说 明。
     虚拟主机模块的实现与通用模拟器所采用的编程环境有关， 在本发明的一个实施
     例中， 如图 1 所示， 使用 JavaMachine 作为虚拟主机模块。JavaMachine 的功能与前面所提 到的虚拟主机模块并没有大的差别， 只是该模块只能应用于 Java 虚拟机中。
     模型派生实体模块
     模型派生实体模块用于描述本发明的通用模拟器中所包含的各类实体。 模型派生 实体模块中所含实体的种类、 不同实体间的连接关系等内容与具体的目标系统有关， 而各 类实体又由系统抽象模型派生得到， 因此， 为了说明方便， 首先对系统抽象模型的相关内容 加以描述。
     所述的系统抽象模型用于实现对目标系统与通用模拟器的抽象。图 2 为系统抽象 模型在一个实施例中的示意图。在该实施例中， 系统抽象模型采用 Java 编程语言加以描 述， 但在其它实施例中， 也可以用其它类型的编程语言描述抽象模型， 所描述的抽象模型与 用 Java 语言所描述的抽象模型相比， 除了因为编程语言各自的特点所造成的差别外， 并无 本质上的不同。
     在前文中已经提到， 目标系统中包括有实体， 而在模拟器中也包括有实体， 对于所 有的实体， 在抽象模型中都被抽象为 Java 中的接口 IEntity， 每个 IEntity 都具有一个全局 唯一的 ID。如图 2 所示， 在抽象模型中， IEntity 分为两类 ： 一类为用于表达目标系统中实 体的 ISimEntity(Simulation Entity， 模拟实体 )， 另一类为用于表达模拟器自身系统中实 体的 ISysEntity(System Entity， 系统实体 )。下面对这两类 IEntity 分别加以说明。 1、 模拟实体
     模拟实体 ISimEntity 用于模拟目标系统中的实体， 显而易见， 一个所要被模拟的 目标系统中必然包括有多种类型、 多个数量的实体， 因此在模拟的过程中要用多个模拟实 体来表示这些实体。考察目标系统中的实体间的关系， 可分为三种 ：
     a、 composite 类型的聚合关系 ；
     b、 share 类型的聚合关系 ；
     c、 行为的主体和客体， 即普通的关联关系。
     模拟实体间的上述三种关系将在下文中有进一步的描述。 模拟实体按照其内容可 分为 ISimStructure( 结构型实体 ) 和 ISimResource( 资源型实体 )。所述的资源型实体 ISimResource 用于封装目标系统中具有逻辑功能的单元， 例如 RAM、 ROM、 CPU 等。所述的结 构型实体 ISimStructure 将资源型实体 ISimResource 组织起来， 以得到更大粒度的功能单 元。
     所述的结构型实体 ISimStructure 可进一步分为用于表达 composite 类型聚 合 关 系 的 ISimNode(Simulation Node， 模拟结 点 ) 和 用 于表 达 share 类 型 聚合关 系 的 ISimGroup(Simulation Group， 模拟组 )。一个模拟节点 ISimNode 中可以包含多个资源型 实体 ISimResource， 而一个模拟组 ISimGroup 则可以包含多个结构型实体 ISimStructure。 需要说明的是， 对于模拟节点和模拟组， 它们所涉及到的包含的含义并不相同， 模拟节点 ISimNode 将所述资源型实体都保存在自身中， 而模拟组 ISimGroup 仅仅记录了结构型实体 的 ID。
     在前文中提到目标系统中的实体之间具有交互关系， 这一交互关系在模拟器 中体现为模拟实体 ISimEntity 间的交互。模拟实体 ISimEntity 间的交互通常指的是 资源型实体 ISimResource 之间的交互， 实际上表现为离散事件系统中的事件， 参与交
     互的资源型实体 ISimResource 分别是事件的发送方和接收处理方。所述的事件可以用 SimEvent(Simulation Event， 模拟事件 ) 表示。
     根据目标系统， 某些模拟实体应当是可迁移的， 某些模拟实体应当是可调用的， 为 了将这些模拟实体与其它模拟实体相区别， 参照图 2， 在抽象模型中采用接口 IPortable 来 标识可迁移的模拟实体， 采用接口 Invokable 来标识可调用的实体。抽象模型还采用了接 口 IEventTargetSet 来简化对复杂事件收发关系管理的事件目标集。
     2、 系统实体
     为了支持对目标系统的监测和控制， 抽象模型从系统实体 ISysEntity 派生出负 责监测模拟实体内部情况， 且接收模拟实体主动发送信息的 IProber( 探针 )， 以及用于负 责用户对模拟器直接控制的 IMonitor( 控制器 )。
     每个模拟实体 ISimEntity 都可以设定一个探针 IProber。 一方面， 探针 IProber 可 以探测到模拟实体 ISimEntiy 中发生的变化， 例如收到了一个事件 SimEvent ； 另一方面， 模 拟实体 ISimEntity 可以将自身的一些信息主动发送给探针 IProber。 在 Java 中， IProbable 接口用于标识一个实体是否能够插入探针 IProber 进行监测。由于 ISimEntity 实现了 IProbable， 因此所有的模拟实体 ISimEntity 及其子类都是可监测的。此外， 由于模拟器 实质上是包含多个模拟实体 ISimEntity 的模拟实体 ISimEntity。因此， 在图 2 中， 表示特 殊的模拟组的 ISimulator 继承自所述的模拟组 ISimGroup。每个模拟组 ISimulator 都需 要有一个控制器 IMonitor 与之配合工作， 且该 IMonitor 必须是 ISimMonitor(Simulator Monitor， 模拟器监控器 )。 系统实体 ISysEntity 除了上面所提到的内容外， 还包括用于简化对复杂事件收 发关系的管理的 IEventTargetSet。这些系统实体都可以由用户定制并使用。
     在前文中已经提到， 模型派生实体模块的生成除了与系统抽象模型有关外， 还与 具体的目标系统有关。在由目标系统生成模型派生实体模块的过程中， 需要将目标系统中 的功能单元实现为资源型实体 ISimResource， 并重用所述的结构型实体 ISimStructure 和 系统实体 ISysEntity。如需进行特殊的控制和检测， 则可定制所需的控制器 IMonitor、 模 拟器监控器 ISimMonitor 和探针 IProber。 为了简化对资源间交互关系的设定和管理， 还可 定义所需的 EventTargetSet( 即实现 IEventTargetSet， 以下简称 ETS)。
     上文是对系统抽象模型以及如何由目标系统生成模型派生实体模块的描述， 下 面对模型派生实体模块的基本结构加以说明。如图 1 所示， 所述的模型派生实体模块 包括一个特殊的模拟组 ISimulator， 该模拟组 ISimulator 有一个与之配合工作的控制 器 IMonitor。在所述的 ISimulator 中， 可以插入多个模拟组 ISimGroup。这些模拟组 ISimGroup 可能位于其它 JavaMachine 模块中， 但对用户来讲其访问方式与对本地组的访 问相同。每个模拟组 ISimGroup 中可以插入多个模拟结点 ISimNode， 模拟结点同样可能位 于其它 JavaMachine 模块中。每个模拟结点中可以放入多个资源型实体 ISimResource。 资源型实体必须与其所属的模拟结点在同一个 JavaMachine 模块中。此外， 用户可以 在 模 拟 组 和 模 拟 结 点 中 放 入 探 针 IProber， 也 可 以 在 JavaMachine 模 块 中 放 入 控 制 器 IMonitor。根据抽象模型的定义， 可迁移的实体可以通过 JavaMachine 模块使之迁移到其 它 JavaMachine 模块上。
     交互支持模块
     交互支持模块用于实现模型派生实体模块中所包含的各个实体之间的交互。 下面 从多个角度对交互支持模块加以说明。
     A、 对不同类型的事件的处理
     实体间的交互可以分为如下的两种， 对于不同种类的实体间交互可以用不同类型 的事件表示。
     1、 模拟实体 ISimEntity 间的交互， 即资源型实体 ISimResource 间通过收发模拟 事件 SimEvent 进行的交互。
     2、 有系统实体 ISysEntity 参与的交互， 这包括系统实体 ISysEntity 之间的交互， 以及系统实体 ISysEntity 与模拟实体 ISimEntity 之间的交互。
     第一种交互是目标系统中的行为。例如， 当资源型实体 ISimResourceRi 需要和资 源型实体 ISimResource Rj 进行交互时， 它发送一个模拟事件 SimEvent 到 Rj， 从而发起一 次交互。模拟实体 ISimEntity 间的交互可细分为两类 ： 同步交互和异步交互。同步交互需 要目标实体同步地返回交互结果， 类似于一次函数调用。 异步交互则不需要返回任何结果， 类似于一次消息发送。
     第二种交互实际上是目标系统中的模拟实体 ISimEntity 或模拟器用户对模拟器 的调整。例如， 模拟器用户希望改变探针 IProber 中数据的报告方式， 或目标系统中的一个 网络节点修改自身的 IP 地址。StarSim 将这种交互行为处理为目标系统之外的行为， 使用 IInvokable 来表示能够进行此类交互的实体 IEntity。需要说明的是， 在使用 Invocation 进行交互时， 不影响模拟时钟， 即不会导致模拟时钟向前推进。
     在图 3 中， 对用于交互的事件做了区分， SimEvent 代表用于表示第一种交互类型 的模拟事件， Invocation 则代表用于表示第二种交互类型的调用事件。这两类事件都具有 如下要素 ：
     1、 事件名， 用于区分不同的交互行为， 类似于方法调用中的函数名 ；
     2、 事件数据， 用于传递交互时的参数及可能的处理结果。
     无论何种类型的事件， 用于表示事件的事件数据都是一个键值对的列表， 每个数 据都有一个用于区分的名称。
     基于事件的交互支持模块对于不同类型的事件具有不同的处理方法。
     a)、 对于资源实体发送出的模拟事件 SimEvent， 交互支持模块将根据该资源实体 中设定的事件目标将事件分发到指定的资源中。 每个资源中都存在一些用于处理事件的事 件处理器 (IEventHandler)。用户需要按照事件处理器的格式为自己的资源实体编写一些 事件处理器。模拟事件 SimEvent 被分发到指定的资源后， 模拟器首先获得处理该模拟事件 SimEvent 的事件处理器， 然后调用事件处理器对模拟事件进行处理。
     b)、 对 于 调 用 事 件 Invocation， 交互支持模块将其直接分发到实现了接口 Invokable 的相应目标的 invoke 函数， 由该函数进行处理。
     B、 解耦资源实体间的依赖关系
     基于事件的交互支持模块除了前文提到的对事件的分类处理外， 还具有其它功 能。
     在创建模拟器的过程中， 经常会遇到这样的问题 ： 当用户在模拟器中定义一个资 源型实体时， 通常难以确定与之进行交互的其它资源型实体的具体类型。例如， 定义 CPU 这一资源型实体时， 尽管知道它将要访问存储空间中的数据， 但并不知道提供数据的是资源 型实体 RAM/ROM 还是资源型实体 Cache。这显然不利于模拟器的成功创建。作为一种优选 实现方式， 基于事件的交互支持模块可通过解耦资源实体间的依赖关系来克服这一问题。
     以前面提到的对资源型实体 CPU 的定义为例， 在定义 CPU 时， 确定它需要分别通 过名为 “READ_MEM” 的事件和 “WRITE_MEM” 的事件来读取和写入数据。在定义 RAM 时， 确 定它可以响应数据的读事件和写事件， 并将这两个事件分别命名为 “DATA_READ” 和 “DATA_ WRITE” 。 在模拟器中将 CPU 和 RAM 组合在一起时， 只需要将 CPU 的 READ_MEM 事件链接到 RAM 中 DATA_READ 事件的事件处理单元， 使得 CPU 发送的名为 READ_MEM 的事件会被模拟器分发 给 RAM， 作为 RAM 中名为 READ_MEM 的事件， 这一过程也被称为事件名的链接装配。同理， 当 需要将 CPU 先连接到 Cache， 再由 Cache 连接到 RAM 时， 只需要在链接装配时将 CPU 的 READ_ MEM 事件链接到 Cache 的 CACHE_READ 事件， 并将 Cache 的 MISS_MEM_READ 事件 (cache 未命 中时， 所发起的内存读取事件 ) 链接到 RAM 中的 DATA_READ 事件即可。通过事件名的链接 装配， 既确保了资源型实体的重用性， 又增加了系统的灵活性。
     上文中只是对事件名的链接装配过程做了简单的说明， 下面对基于事件的交互支 持模块解耦资源实体间的依赖关系的具体实现过程加以说明。 首先， 对资源型实体所发出的事件做按名装配。所述的按名装配是指指定资源实 体所发出的事件的目标及目标在接收时的事件别名。
     所述的按名装配通过创建事件的目标列表实现。 每个事件的目标列表是由一个事 件名到多个目标信息的 Key-Values 映射实现。目标列表中的每个目标信息描述了相应目 标的以下内容 ： 目标资源实体的 ID、 目标资源实体所在模拟节点 ISimNode 的 ID、 目标资源 实体接收时的事件别名。
     其次， 事件的按名链接。所述按名链接是指将资源型实体 ISimResource 发送的名 为 EventName 的事件， 发送给目标资源实体 ISimResource 作为名为 AliasEventName 的事 件。
     在按名链接的过程中， 当作为交互发起者的资源型实体 ISimResource 发送模拟 事件 SimEvent 时， 模拟器根据事件的名称查找按名分配过程中所创建的目标列表， 得到目 标的以下信息 ： 目标资源实体的 ID、 目标资源实体所在模拟节点 ISimNode 的 ID、 目标资源 实体接收时的事件别名。在得到目标的上述信息后， 就可以由模拟器根据相关信息将事件 发送到目标资源所在的模拟节点 ISimNode， 由其在正确的模拟器时刻从目标资源型实体中 得到处理该事件别名的事件处理器， 并交由该事件处理器处理。 在按名链接的过程中， 为了 避免无关事件从源端 ( 即事件的发送端 ) 到目的端不必要传输所带来的额外开销， 还可以 在事件分发前进行过滤操作。所述过滤操作由事件过滤器实现， 事件过滤器检查当前事件 是否需要送到目标端， 若需要， 才进行后续的分发操作。 由于是否需要事件过滤器以及采用 何种事件过滤器在不同目标上可能会有所不同， 因此事件过滤器的相关信息也可预先保存 在目标列表中。
     C、 复杂事件链的装配
     以上是对事件的链接装配基本过程的描述， 无论目标系统中包括有多少个资源型 实体， 模拟器都可以利用这一链接装配过程完成资源型实体间的交互。 虽然如此， 当资源实 体之间的事件收发关系不是简单的单源单目标或单源多目标， 而是复杂的多源多目标时，
     单纯依靠逐个指定事件源的发送目标来完成对资源实体的事件链接将会使得装配工作变 得繁琐。 例如在对一个房间内 WiFi 网络的模拟中， 每个被模拟的主机上的 WiFi 网卡都需要 与房间内其它 WiFi 网卡相连——即它产生的事件需要发送到其它所有有效范围内的 WiFi 网卡。若逐个装配链接， 需要 N×N 次链接 (N 为网卡数目 )， 并且要维护这种链接所要花费 的代价较大。例如某个节点的加入和退出都需要修改其它所有节点上的链接关系。为了在 此类情况下减少链接次数， 降低维护成本， 作为一种优选实现方式， 在另一个实施例中采用 “事件目标集” (IEventTargetSet， ETS) 来管理事件源到事件目标之间的链接关系。所述的 ETS 首先包括对这些链接关系的描述， 然后按照预定的策略自动生成事件链接关系， 并分发 到事件源结点。当事件链接关系需要变动时， 直接通知 ETS， 由 ETS 进行更新即可。例如， 可 以预先定义一个 WiFi 的 ETS， 然后将所有网卡及其位置放入 ETS 中， 由 ETS 根据各网卡的有 效距离和位置确定其事件链接关系。当结点位置发生变化时， 只需修改 ETS， 由 ETS 自动更 新涉及的结点间的事件链接关系即可。这样， 无论是初始化还是更新， 使用者都只需要 1 次 设定。
     D、 同步事件交互方式
     在现有技术的典型离散事件系统中， 事件从产生到发送并被接收方处理的整个过 程通常是异步的， 即发送方发送事件后不再等待接收方处理完毕而继续往下执行。这种异 步的事件交互方式， 会增加实体内部事件响应逻辑的复杂度。例如， 当 CPU 实体需要读取 RAM 实体中数据时， 由于异步事件交互方式， 使得完成这一操作必须由 CPU 发送一个 READ 事 件， 然后等待 RAM 实体发送回来的 READ_ACK 事件， 只有当接收到 READ_ACK 事件后， 读取操 作才算完成。 鉴于异步事件交互方式的这一不足， 为了简化实体交互时的内部逻辑， 在本发 明的一个优选实施例中， 基于事件的交互支持模块采用同步事件交互方式， 这一交互方式 也被称为 CallByEvent 机制。在同步事件交互方式中， 发送方需要等待接收方将事件处理 完毕， 接收方需要显式告知事件处理完毕。在同步事件的支持下， CPU 发送 READ 事件后， 自 动处于等待状态， 直到 RAM 将数据放入 READ 事件并返回 ； 而 RAM 在读出数据并放入 READ 事 件后， 需要显式告知事件处理完毕。CPU 的发送动作返回时， READ 事件中已经具有了 RAM 中 读出的数据。 与异步事件交互相比， 在同步事件交互过程中， 接收方不需要显式发送一个应 答事件， 发起方也不需要编写处理应答事件的 IEventHandler， 同时减少了一次事件链接的 装配同步事件交互方式 ( 或 CallByEvent 机制 )， 因此简化了实体间的交互。
     分布支持模块
     在前文中已经提到， 模拟器中的某些模拟实体是可迁移的， 并采用接口 IPortable 来标识和支持可迁移的模拟实体。 对模拟实体的迁移由所述的分布支持模块在前述虚拟主 机模块的辅助下实现。
     在本发明的一个实施例中， 分布支持模块是基于简化 ORB 实现的。所述的 ORB 即 对象代理， 典型的对象代理方法包括 CORBA、 DCOM、 J2EE 等。由于这些典型方法需要处理复 杂网络环境、 跨平台、 跨语言等诸多难题， 因此通常都非常复杂。鉴于模拟器所面临的运行 环境较为简单， 例如通过高速可靠的局域网 TCP/IP 互联， 不存在跨编程语言的问题， 因此 可以采用简化后的对象代理方法。所述的简化后的对象代理方法只包含三个功能 ： 1、 维护 主机之间的关系， 即有哪些主机参与模拟， 如何访问它们 ； 2、 可迁移对象的位置管理， 即位 于哪个主机 ( 运行模拟器的计算机 ) ； 3、 对可迁移对象的访问。本发明中主要涉及如何利用简化后的 ORB 实现对可迁移对象在不同主机上的分布以及后续的交互访问。
     要实现可迁移实体在不同主机上的支持， 需要采用一类名为存根 (Stub) 的类， Stub 类为可迁移实体生成对应的 Stub 对象。Stub 对象与其所对应的可迁移实体相比， 具 有相同的模拟组 ISimGroup、 特殊模拟组 ISimulator 以及模拟结点 ISimNode， 因此使用者 在使用所述的可迁移实体时， 并不需要区分是实体本身还是其对应的 Stub 对象。 Stub 对象 将确保对它的调用会被转发到分布在其它主机上的对应实体， 并返回结果， 从而使得用户 可以访问分布在不同主机上的实体， 而不需要关心底层如何实现这种远程请求。对用户而 言， 分布在不同主机上的实体就像在一台主机上运行。图 4 为可迁移实体以及可迁移实体 所对应的 Stub 对象的示意图， 其中的右侧表示了所述的 Stub 对象。Stub 对象对于用户而 言是不可见的， 图中的虚线表示实现关系， Stub 对象实现与其虚线相连的可迁移对象。图 中的实线表示继承关系， Stub 对象继承与其实线相连的可迁移对象。通过上述操作可以确 保用户透明地使用 Stub， 但却认为使用的是相应的可迁移对象。
     为了便于用户操纵分布系统中的各个主机， 在所述的虚拟主机模块中保存了两张 表， 一张是用于记录位于本地的可迁移实体的实体表， 另一张是用于记录本地所用的所有 Stub 的存根表。另外， 虚拟主机模块还使用了一个用于实现简化后的 ORB 的 IJVMORB 对象 来和其它主机上的虚拟主机模块进行交互。对远程虚拟主机模块的访问可以通过获得其 Stub 来进行。但是， 虚拟主机模块的启动不能通过 Stub 来进行， 必须手工在主机上启动并 运行一个虚拟主机模块。虚拟主机模块启动后， 将按照预定的策略寻找其它的虚拟主机模 块， 并完成必要的信息同步工作。 在前文中对 Stub 和虚拟主机模块做了描述以后， 下面就可以对可迁移实体的管 理过程加以说明。可迁移实体的管理过程包括创建、 销毁和迁移。在实现上述管理过程中， 虚拟主机模块提供了迁移的调用接口， 这些调用接口在内部将实际的动作交由分布支持模 块执行。这样就实现了分布支持模块对用户的透明性， 从而可以根据情况提供不同的分布 支持模块。具体实现过程如下。
     当用户创建一个可迁移实体时， 首先由虚拟主机模块生成该实体， 并放入所述实 体表中 ； 然后， 虚拟主机模块生成该实体对应的 Stub， 放入所述的存根表中 ； 接着， 虚拟主 机模块再使用 IJVMORB 中的用于通知其它主机上的虚拟主机模块添加一个可迁移实体 的 notifyAddMobile 方法 ； 最后虚拟主机模块向需要创建可迁移实体的用户返回生成的 Stub。
     当用户根据 ID 获取可迁移实体时， 虚拟主机模块首先查找所述存根表中是否有 此 ID 的 Stub， 有则直接返回该 Stub， 无则创建一个 Stub， 并将所创建的 Stub 放入存根表， 并返回该 Stub。
     当用户要销毁一个可迁移实体时， 虚拟主机模块判断该实体是否在本地， 若在本 地则从所述实体表中删除并销毁， 然后调用 IJVMORB 中的用于通知其它主机上的虚拟主机 模块删除一个可迁移实体的 notifyRemoveMobile 方法， 并接着删除存根表中可能存在的 该对象的 Stub。若所要删除的实体不在本地， 则使用 IJVMORB 中的要求返回指定实体所在 虚拟主机模块编号的 getHostJVM 方法获得该实体所在的虚拟主机模块的 Stub， 然后转发 销毁请求。
     用户调用虚拟主机模块中方法得到的可迁移实体都是 Stub。用户对 Stub 发起
     调用时， 调用将被 Stub 截获。Stub 首先根据自身所代理的实体的 ID， 在本地虚拟主机模 块中查找该实体， 若实体在虚拟主机模块的实体表中， 则将调用转发给该实体。否则将调 用转发给本地虚拟主机模块的 nrmi 方法。在 nrmi 方法中， 虚拟主机模块调用 IJVMORB 的 getHostJVM 方法获得该实体所在的虚拟主机模块的 Stub， 然后调用虚拟主机模块的 Stub 中的 remoteCalled 方法。由于虚拟主机模块的 Stub 是由 IJVMORB 管理的， 因此 StarSim 实际上将分布化的底层支持划归 IJVMORB 进行管理。因此， 针对不同特点的主机系统， 可以 通过使用不同的 IJVMORB 实现来提高底层分布的性能。
     图 5 给出了在 Java 环境下的一个实例， 在该图中， 实线圆形表示可迁移实体， 虚线 圆形表示 Stub， 椭圆表示 JavaMachine 模块。当 JavaMachine 模块 1 中的用户访问可迁移 实体 B 时， 对 B 的访问被可迁移实体 B 所对应的 Stub b 截获， 并由其转发到 JavaMachine 模块 1 的 nrmi 方法。JavaMachine 模块 1 的 nrmi 调用 IJVMORB1 获得 JavaMachine 模块 2 的 Stub j2。由于 j2 是 IJVMORB1 创建的， 故它可能包含了 JavaMachine 模块 2 的网络地址 等信息， 因而能够将请求转发到 JavaMachine 模块 2， 并返回结果。
     多线程并发执行模块
     在离散事件的模拟中， 事件的完全并行处理与模拟时钟的统一推进是一个尚未从 理论上解决的问题。完全的并行性不可避免地遇到模拟时间上的 “因果顺序” 问题， 而时钟 的统一推进又会大大降低事件处理的并行性。因此， 本发明中采用多线程并发执行模块对 大型系统中大量存在的同时发生事件 ( 即发生在同一个模拟器时钟上的事件 ) 进行多线程 的并发处理。
     多线程并发执行模块通过令牌分发与回收的机制来支持使用多线程对事件的并 行处理， 同时确保时钟的统一推进。 如图 6 所示， 在模拟时刻 Ti， 结构实体 (ISimStructure) N 上有 k 个同时发生的事件 E1， ...， Ek， 则由 N 的时钟推进函数 (advance) 创建 k 个线程， 并将调用 advance 的线程所持有的 Token 分为 k 份， 分发给这 k 个线程。然后启动这 k 个 线程分别处理这些事件。调用 advance 的线程启动所有的子线程后， 等待收集已分发的 k 个子 Token， 收集齐后才能继续。每个子线程执行完毕后， 向主线程归还所持有的子 Token。 每个结构实体上都重复这一过程， 使得每个结构实体上的处理过程大致相同。由于结构实 体可以分布在不同的主机上， 故并发的线程可以支持和利用分布性。这种并发机制无需用 户所定义的资源实体的参与， 因而对用户是透明的。
     在前文中已经提到， 在本发明的一种优选实现方式中， 可以采用同步事件交互方 式 (CallByEvent) 实现对事件的处理。多线程并发处理机制同样适用于 CallByEvent。具 体的说， 事件发送方 S 调用用于实现同步事件交互的 callByEvent 函数， 该函数首先调用 dispatchEvent 以将事件发送到目标实体 D， 然后将自身的令牌 token 归还主线程， 并通过 调用 waitForACKEvent 来实现对当前子线程 T 的阻塞睡眠， 以等待事件的返回。当目标 实体 D 处理完事件后， 调用 returnEvent 函数。该函数将会唤醒正在睡眠的线程 T， 使得 callByEvent 函数得以继续执行。当它获取目标实体所返回的事件后， 完成退出。
     以上是对本发明的通用模拟器的详细说明。 从对通用模拟器各个模块的详细说明 可以看出， 本发明为被模拟的目标系统建立通用、 简单的模型， 使得通用模拟器能用于大部 分事件系统的模拟， 并降低对具体目标系统进行模拟的难度。
     此外， 本发明的通用模拟器提供基于事件的实体间交互机制， 该机制支持实体间的解耦以提高实体的重用性， 而同步事件交互机制 (CallByEvent) 能够简化实体内部的事 件处理逻辑， 事件目标集 ETS 还能够简化复杂事件收发关系的装配。
     本发明的通用模拟器也支持模拟实体的分布化。本发明基于简化的 ORB( 对象请 求代理 ) 思想， 将模拟实体分布到不同的主机进行模拟， 解决模拟器运行时单机性能不足 的问题， 还隐藏分布时的底层细节， 提供对模拟实体分布的控制。
     本发明的通用模拟器还支持同时事件的并行处理 ： 使用令牌分发和多线程技术， 使得多个主机和同一主机中的多个线程能够透明的并行处理同一模拟时刻发生的模拟事 件。
     本发明的通用模拟器支持对模拟系统的可定制的监测和控制， 通过提供可定制的 监测和控制方法， 使得用户能够灵活的监测和控制目标系统中的实体。
     最后所应说明的是， 以上实施例仅用以说明本发明的技术方案而非限制。尽管参 照实施例对本发明进行了详细说明， 本领域的普通技术人员应当理解， 对本发明的技术方 案进行修改或者等同替换， 都不脱离本发明技术方案的精神和范围， 其均应涵盖在本发明 的权利要求范围当中。