关于on reset触发运行机制

上午的时候有同学提出一个问题，完全相同的两个模型，自己做了两次之后，一个可以运行成功，而另一个无法实现。起初并未在意，以为是个bug，后来几番尝试之后发现终于发现了其中的规律。
' ]' b- ^* r8 {, a2 }+ x      这是有关于onreset触发的问题。在onreset触发中关闭自己的端口是完全没有问题的，然而，当我们在onreset中关闭其他实体的端口时我们发现有的时候是可以的有的时候却不可以。我们来简单分析一下这个情况。简单的做了一个小模型（模型1）描述该问题。
, h- }( c$ j6 J, n     首先，我们要提出的是，在重置时，他并不仅仅是将模型还原，这其中，还隐藏着一个逻辑，将各实体的输入输出端口全部打开。这点我们可以用模型2来验证。在重置时，我们延迟关闭的暂存去输入端口被打开了，而我并没有写任何的打开输入端口的代码。
     其次，我们知道，在软件中，代码的执行速度是超快的，然而不管怎么快，它都是有顺序的。比如在同一个触发中，必然是先运行上一行的，然后运行下一行的。而不同的触发，由于触发的条件与时间不同，我们也比较容易区分。但是，onreset是个比较特殊的触发，因为模型中有很多实体，那么我们在点击重置的时候，它的运行顺序是怎样的呢？我在不同的实体的onreset中各自添加了断点。发现，它是按照在结构树中的rank位置依次运行的（没有正式版的同学可以初步认为是你拖入实体得到顺序）。
    至此，两个同样的模型却出现不同情况的原因明了。模型1，虽然在source1中关闭了queue2的输入，但是这些都是在queue2重置触发代码运行之前实现的，当queue2的重置触发运行了的时候，queue2的输入端口又被打开了，所以失败了。而source4与queue3相反，因为queue3在source4之前（rank）。

精品

精品

楼主的这种精神值得学习

很有用的东西~留着学习~顶版主~

1# 雪饼
& e7 M6 x# Z5 ~

- @; y3 `$ ~) H- y版主牛。顶起！受益匪浅！