backmp11: Provide additional possibilities to defer events (?)

[chandryan]

Problem statement

MSM currently allows 2 ways to defer events:

• Via a deferred_events property in a state and
• Via an action within a transition

The first possibility is consistent with the UML standard, but the second one is not foreseen by it. While this mechanism supports more than what is foreseen by UML, such as conditional event deferrals with the help of guards in the transition, it leads to undesired (and likely unsolvable, see #72 for more details) issues:

• due to the need to dispatch the event for evaluation, UML-compliant behavior cannot be ensured with this mechanism in orthogonal regions; events can be deferred and processed by different regions at the same time
• the event has to be removed from the deferred events queue and dispatched for evaluation and then get pushed back to it, leading to potential issues wrt. deferred event orders in the queue - worst case to infinite recursion

Possible solutions

For backmp11 there are 2 possiblities to handle the problem:

1. Remove support for event deferral as an action, as it's anyway not foreseen by UML
2. Provide an alternative approach that allows deferral evaluation at runtime, but is more similar to the deferred_events state property

Feedback required ❗

Solution no. 1 "remove support" is currently targeted for the next Boost release 1.91, mainly because it's not clear whether this functionality is needed in the first place.

If a more sophisticated event deferral mechanism than described in the UML standard is needed, please provide feedback by stating your use case and your needs.

[henry-ch]

Strong vote against Solution 1. If you think of a solution 2, I am interested :)

[chandryan]

Thanks for the feedback! I'm fairly confident we'll find a good solution 2 which works well with the "UML" way of deferring events.

For solution 1, "removal" was the technically imprecise short statement 😅
What I would like to do in backmp11 in detail is the following:
Change the access modifier of state_machine's defer_event method from public to protected. Deferring as an action is not actually removed then, but you need to opt-in by inheriting from state_machine and making the method public again. This would express "I'm aware there are limitations, I want to do it anyway and I know that I can shoot myself in the foot".

For solution 2 I have a member function in the state like this in mind:

template <class Event, class Fsm>
bool is_event_deferred(const Event&, Fsm&) const;

The function would be evaluated complementary to the deferred_events property, in pseudo-code: is_in_deferred_events<State, Event>::value || state.is_event_deferred(event, fsm)

This should provide similar possibilities to deferring the event in an action, but the evaluation can happen prior to event dispatch.
Please let me know if you have any doubts about the idea, I'll add you the Pull Request when I have set something up that works :)

[chandryan]

I've spent some time on this topic and was able to draft an implementation with a conditionally_deferred_events property. It does work technically, though there might still be better solutions.

I see 3 possible approaches so far, sharing a summary of my thoughts below.
Out of these, approach C "new row types for deferral" seems to be the most promising for me currently.

---

A: Additional property in the state

Approach:

• conditionally_deferred_events property in the state that describes which events are eligible for conditional deferral
• Additional methods in the state to implement the conditional deferral

Pros:

• Most similar to what UML imagines how deferral should look like (-> having a state property)

Cons:

• Some redundancy due to the need to define a property plus method(s), but without that hint for the compiler provided by the property the compile time increased too much
• Compile time (and runtime?) overhead compared to using a mechanism like the Defer action in rows? There is a potentially bigger cost involved even if just one immediate substate defers events, because then all substates need to be evaluated (at least in compile-time) for the presence and contents of the deferred events properties. And that then needs to happen for all possible events

---

B: Improve deferral as action

Approach:

• Split transition execution into check and execute
• First check all orthogonal regions and then conditionally execute or defer

Pros:

• Probably good compile time
• Can be priorized with other rows in the transition table
  -> Supports edge cases, for example "override" a deferral

Cons:

• Deferral as action is semantically contradictory
• Having a target state in these rows is confusing, it's not clear to me if that transition should happen or not
• Runtime overhead of split when not needed? Though ideally this could be just one additional function call

---

C: New row types for deferral

Approach:

• Split transition execution into check and execute
• First check all orthogonal regions and then conditionally execute or defer
• New DeferRow: With source state, event and (optional) guard
• New DeferInternal: With event and (optional) guard

Pros:

• Probably good compile time
• Clear semantics
• Can be priorized with other rows in the transition table
  -> Supports edge cases, for example "override" a deferral
• This could be "the one" universal mechanism to do conditional and unconditional deferral and has the potential to supersede the deferred_events property

Cons:

• Runtime overhead of split when not needed? Though ideally this could be just one additional function call