Bugfix in C decentralized execution with small after delays

[petervdonovan]

The bug is only apparent when there are connections with small delays of at least one microstep.

I claim responsibility for having recently introduced this bug.

Thanks to @jackykwok2024 for helping to uncover this bug.

[edwardalee]

A question about this fix: With decentralized coordination, a federate should be able to continue to execute even if it gets completely disconnected from the network (no messages come in). It looks to me like this use of max_level_allowed_to_advance will prevent this? Also, if a connection between federates has a large after delay (and messages take a long time to arrive), won't this block the receiving federate until that (future) message arrives?

[petervdonovan]

It looks to me like this use of max_level_allowed_to_advance will prevent this?

No, the MLAA will be updated when the STP offset expires. See this procedure, which was mostly contributed by Anirudh some months ago.

Also, if a connection between federates has a large after delay (and messages take a long time to arrive), won't this block the receiving federate until that (future) message arrives?

I'm not sure what you mean. If there is a large after delay, the receiving federate is still able to keep its logical time arbitrarily close to the physical time minus the STP offset, even if it has not received a message over the connection yet.

When I finish working on this PR, I'll update it with details about the nature of the bug that it fixes and I'll mark the PR ready for review.

[lhstrh]

Looks like merging #279 resulted in a conflict on this PR...

[petervdonovan]

It turns out that what we had in main already seems to match the behavior that @edwardalee described in our meeting today; so, the difference in behavior between this branch and the spec is apparently just due to my erroneous changes in this branch.

The problems in main that are actually fixed by this PR are now:

• In main, we wait for the STA offset to elapse even before we start time 0, which is unnecessary; this is fixed in this PR.
• In main, we do not wait for the STAA offsets to elapse for nonzero-delay connections; this is my mistake and is fixed in this PR.

[edwardalee]

As for non-zero delay connections, I believe that the STAA wait time should be adjusted down by the amount of logical delay. If the amount of delay is 0, of course, this makes no difference, so in this case, it will be treated the same as if there were no delay on the connection.

[lhstrh]

@edwardalee, should we merge this?

[edwardalee]

This looks good, but I've raised some questions.

[edwardalee]

I think we can go ahead and merge this. Thanks!!