Events 将事件推送到自己的事件队列的状态机

我目前正在研究分层状态机（UML状态机、状态图等），我不清楚以下内容：

在转换期间和从状态将事件推送到机器自己的事件队列是否有效，如果有效，是否在实践中安全使用，还是应该避免？这样做是否有一定的影响（至少在实现上有问题，正交区域起作用时有问题，或者类似）

我将用两个虚拟机器来说明这个问题：

以下机器将处于状态

A

等待事件

A_到B

，之后它将通过将事件作为转换动作进行调度而进入无限循环：

      +-----+                    +-----+                    +-----+
      |  A  |  A_to_B /          |  B  |  B_to_C /          |  C  |
      |-----|   dispatch B_to_C  |-----|   dispatch C_to_A  |-----|
O---->|     +------------------->|     +------------------->|     |
      |     |                    |     |                    |     |
      +-----+                    +-----+                    +-----+
         ^                                C_to_A /             |
         |                                 dispatch A_to_B     |
         +-----------------------------------------------------+

以下机器将通过将事件作为入口操作进行调度，立即进入无限循环：

      +-------------------+           +-------------------+           +-----+
      |         A         |           |         B         |           |  C  |
      |-------------------|  A_to_B   |-------------------|  B_to_C   |-----|
O---->| on entry:         +---------->| on entry:         +---------->|     |
      |  dispatch A_to_B  |           |  dispatch B_to_C  |           |     |
      |                   |           |  dispatch C_to_A  |           |     |
      +-------------------+           +-------------------+           +-----+
         ^                                                               |
         |                                                   C_to_A      |
         +---------------------------------------------------------------+

---

状态机可以将事件发布到self，但这有特殊的用途，例如将较长的运行到完成（RTC）步骤分解为较短的部分。您可能希望这样做，以便在过长的RTC步骤之间启用系统中其他状态机（或更一般的活动对象）的调度

具体到你的例子，在这种情况下，我会尽量避免向self发布事件。通常我看到人们在混淆状态图和流程图时会这样做。状态图需要事件从一个状态转换到另一个状态。流程图在框中指定的计算完成后自动从一个处理框转换到另一个处理框。显然，当您将事件发布到self时，您将状态图转换为流程图。所以，你真的需要一个流程图，而不是状态图，因为你真的不需要等待任何事情。你保持全速处理

---

你也可以这样看。事件的目的是向状态机提供新信息。这就是状态机“学习”的方式。但当你把事情告诉自己时，你不会获得任何新的知识。您所需要的所有知识都已通过最初的“真实”事件提供。因此，您有足够的信息在一次转换中执行所有这些处理，而不是将其分散在许多“状态”中，这些状态实际上是这一漫长处理的各个阶段。

我不知道这是怎么回事。但是，如果您对事件进行排队，那么最好将进程分离到单独的处理器/核心。然后，您可以控制每个项目的优先级。共享内存也可能很有用。+对于ASCII绘图来说，它可以用来解释这个问题，你们是如何绘图的？我曾经画过这些WOW，这是除了米罗·萨梅克本人之外，没有其他人的答案！你在UML状态图上的材料是不可或缺的，在我研究这个主题的过程中对我帮助很大。事实上，这就是我最初问的原因，它给我的印象是相当于状态机的“代码气味”。因为我将要实现HSM框架，所以我希望它尽可能轻，但仍然足够强大。除此之外，我还设计了一个中等复杂的GUI应用程序作为概念证明，而我缺乏使用HSMs的经验，这让我怀疑我是否需要更强大的功能，或者我的设计是错误的：）