Darryl Green wrote:
I have been trying to formulate a reasonable model that is a pure extension to UML statechart semantics to deal with this - I think I have. It also shouldn't break any code that currently uses boost:fsm. My proposal is to allow a transition action's context to be *any* outer state of the source state and to change the state transition processing to:
1) Exit and destruct out to (but not including) the transition action's context or the ICOS, whichever comes first.
2) Execute transition action.
3) Exit and destruct any remaining states out to the ICOS.
4) Enter destination states.
Ok, this doesn't break any existing client code. But I think it is also surprising for FSM folks because UML clearly defines that all exit actions are called before the transition action is called. But I'm not strictly against such a change, I just have to think about this some more.
This doesn't allow access to the state being exited in the transition action, but it does allow the action of a transition that exits an outer state to access that state's context "on the way out".
I don't understand. With your proposal above the transition action can access any state that is exited as the result of the transition, even the innermost state. Simply make the action a member of the state you want to access and you're done, right?
I am finding this to be more frequent/useful than access to an individual simple state's context anyway. Where the requirement is really to access an individual state the cost is a split into an inner and outer state.
Still confused...
There is afaiks no impact on exception handling (I don't think it changes the docs, but it my change the implementation - I haven't checked). If the transition action fails, the exit actions up to the ICOS should run, then the failure reaction is searched for from ICOS out.
I'll have to change the implementation to run exit() and destructors when an exception is propagated from the transition action. Also when this happens we have a major problem if one of the called exit() functions throws as this would inevitably abort the program.
In FSM terms your "pre-exit" trick is an in-state reaction immediately followed by a transition and I think it is much more intuitive to do it this way than the way you propose.
Intuitive to you ;-)
I'm not sure. I'd expect that an FSM expert would immediately know what's going on when I say "in-state reaction immediately followed by a transition".
I don't think it is too bad in simple cases, but it gets ugly when what I really wanted was more like what is described in my proposal above (access to an outer state's context), which I've found my usage evolving into, more often than not.
If you only need to access the outer states' data members, why not give this outer state an in-state reaction, as I have written in my second followup to your message? I'll quote here for clarity: Andreas Huber wrote:
One more and probably the strongest argument pro your pre-exit trick is that it also works nicely with a transition originating at an outer state. E.g. in the StopWatch state chart you want to do something special when a EvReset event is received and the machine is currently in the Stopped state. You'd then add a Stopped in-state reaction, which does what it has to do with whatever Stopped data members and them simply calls forward_event(). The event will then trigger the transition originating at the Active state.
I'm also unsure why you think that your pre-exit trick leads to ugly code. I guess an example would make this a much clearer.
Exit actions are more critical than others in the current implementation because the state machine can be terminated pre-maturely at any time (state_machine<>::terminate()). UML clearly defines what termination means.
I agree with this. I overstated my case somewhat. I think you will see in my later description of exception handling that I do conceed that exit is critical in some ways. I'm having trouble clearly delineating the features of exit that need special handling, and felt that this case was one that didn't. I think this is just a very slight difference of opinion on how to decompose the features of exit, and not of any great importance overall.
Agreed.
3) I think this is a red herring
Do you mean a logical fallacy?
I think it is in the sense that you can't infer that because some aspect of A is the same as a corresponding aspect of B that A is B.
Ok.
I think this *is* quite important. I believe not sticking to UML would lower the acceptance of the library a lot.
I didn't mean to say that the library shouldn't stick to the UML spec where it is applicable. I don't think that it is applicable in the area of object lifetime management because in UML states are not objects.
True. Perhaps a better way to put it: One should be able to model UML state charts with boost::fsm, with as few detours/workarounds/surprises as possible. In any case, UML statecharts (or Harel statecharts) aren't
the only/ultimate/most rigourous definitions of FSM semantics. It isn't hard to find a plethora of possibly more rigorous FSM models (I'm not making any claims for them, I have just seen a lot of citations - not read all the papers). One thing that is not so easy to find is anything regarding integrating FSM as an aspect of a multi-paradigm programming language like C++
Agreed.
(yuk - reads like an add - lucky I didn't say "rich API" as well...).
:-)
In such languages RAII is achieved with a separate Dispose() function. If I was to port the library I'd have users provide Dispose() to implement an exit action.
Precisely. I don't mean that it can't be done, only that the C++ view that what a ctor does a dtor "undoes" doesn't always hold in other contexts, why in this one? I suggest that users have to provide an exit() to implement an exit action. If you think it will help Java programmers, I guess you could call it dispose() -)
LOL
Restrict the allowable transition to be to an inner state only (once again, avoids any further exit actions).
I don't understand this. You said that the reaction should be searched in the ICOS.
No I didn't I said innermost outer state, (IOS) not ICOS.
Sorry, I guess it was a little late.
A better term might have been immediate outer state (of the state that had exit fail). I'm going to write IOS from now on, and hope that the definition is clear enough.
It certainly is. BTW, in the docs I always use "direct outer state", I think that is even clearer (at least for my Swiss German-thinking brain).
I reached my proposed solution after discounting the approach of entering inner states to do recovery, because it won't work for an innermost state with an exit action that can fail (because the recovery state would then be the innermost state, making the original state unstable). I guess some ephemeral "recovery state" concept could deal with this and only construct/enter an inner recovery state when needed, otherwise treating the recovery state's IOS as the innermost state. I haven't checked to see how boost::fsm behaves if you don't specify the initial inner state (illegal in UML afaik).
In boost::fsm, if you don't specify an inner initial state for state A then A is automatically an innermost state and can therefore not have inner states. That is, trying to specify A as the Context of another state will lead to a compile time error.
I would envisage using such a mechanism by making the transition to a recovery state used only for that purpose. The recovery state, as a sibling of the failed state has access to all the context the failed state had (except for the now destructed failed states own).
We have never left the state whose exit action has thrown, right?
That was my first preference, but it created the problem of ephemeral inner recovery states.
It wouldn't if we required that exit() failures must always be handled in the state the caused the failure, see below.
So instead, I proposed considering exit to be "done" but "failed". This seems reasonable enough - analogous to exception handling where you aren't in the block that threw any more, you are in the catch block. This means that after the exit action runs and fails, the state's destructor must run (and succeed - don't throw in the dtor or we are doomed obviously).
How can we then enter a sibling (in StopWatch e.g. Running and Stopped are siblings)?
I think the above explained it. If we were in Running, and its exit action failed, this would have to be reacted to by Active, which could then make a transition to stopped (or more likely, a 3rd sibling that dealt with recovery from failing to exit Running).
Hmmm, all this is very problematic because in the transition to the recovery state the IOS state is exited although its inner state has never been successfully exited. I'd very much prefer to stay in the state that we just failed to exit, recover and then retry to exit the state. Everything else seems very questionable to me. Moreover, how many times do we retry? Does it even make sense to retry? The more I think about this the more I believe that pretty much the only sensible thing to do is to destruct the remaining state objects and propagate the exception to the state machine client... Regards, Andreas