[IGSTK-Developers] State machine questions

[Kevin Gary]

Wow,

After clicking "send" I went to review the SM wiki page
discussion, and David uses the exact example I looked
at. Guess I looked at things in the wrong order! His
suggestion of setting the state before doing the
transition takes care of my questions 2 & 3. Questions
1 & 4 remain however...

K2


Kevin Gary wrote:

> Hi all,
>
> I was looking at some of the state machine code to get
> refreshed on the topic, and as often happens when I look
> at code, I got confused ;).
>
> In looking at SerialCommunication and base Tracker
> classes, the sequence of calls for the Open methods
> will first push an input to the SM and then process it.
> In StateMachine::ProcessInputs, the function pointer is
> traversed (toward the bottom of the method), and the
> ensuing private method on the original object called.
> The result of traversing the transition should leave
> us in an "AttemptingToDoSomething" state. The private
> method invoked (SerialCommunication::AttemptToOpenPort
> or Tracker:: AttemptToOpen) then does a PushInputBoolean
> based on the result of a virtual "InternalXXX" method call.
>
> Some questions:
>
> 1. I do not see a call to StateMachine::ProcessInput(s)
> anywhere after the PushInputBoolean (which queues an input
> to the SM based on the outcome of the Internal method).
> When is the queued input processed? Subsequent call to
> the SM on the next request?
>
> 2. At the end of StateMachine::ProcessInput, the last 2
> things done are 1) an execution of the transition, i.e.
> the function pointer, and 2) setting the state of the
> SM itself to the endpoint of the transition. If the
> invocation of the function pointer itself leads to a
> transition, then the call sequence will in fact "nest"
> the invocation, meaning you will not end up in the
> correct state. For example, in my hand-trace, it would
> seem the SerialCommunication object would end up in the
> "AttemptingToOpen" state and not one of the "m_IdleState"
> (on failure) or "m_PortOpenState" on success. Of course,
> question #1 may make this moot as I do not see when we
> would ever traverse the 2nd transition (it seems to me
> the only reason it works is because the Internal method
> does the actual work *before* the PushInputBoolean call,
> e.g. not under the guide of the StateMachine).
>
> 3. I am not sure of the utility of multiple queued inputs
> to our StateMachines. As each input is mapped onto a single
> transition in a given state, and the processing of a single
> input should lead to a new target state, it seems that
> a sequence of inputs queued on the basis of being in some
> state will find the SM will not be in that source state
> when the input is actually processed! For example, assume
> I have a SM with 3 states, S1-S4, and 3 inputs I1-I3. S1
> accepts inputs I1 and I2. I1 leads to a transition to S2,
> I2 leads to a transition to S3. If I queue I1 and I2 and
> then call ProcessInputs, I will have queued I2 believing
> my object was in S1, when in fact it will be in S2 when
> I2 is processed???
>
> 4. I am not sure of the utility of having the StateMachine
> traverse two transitions and go through two states in this
> call pattern. As we are assumed single-threaded (right?)
> and these are private calls where the result of the original
> client method invocation will never seemingly result in
> being in the "AttemptingXXX" state...why introduce the
> complexity? I'm not sure I see the benefit?
>
> I also looked at the ImageSpatialObjectRepresentation, and
> it does not do the "Attempting" type pattern, and so these
> questions disappear (though it does validate input up
> front to determine the input to push, instead of doing the
> PushInputBoolean thing).
>
> Sorry for the long narrative, it is involved code to trace
> through by hand. I'm sure I am missing something...
>
> Hope everyone has been well...
>
> K2
>
>
>
> _______________________________________________
> IGSTK-Developers mailing list
> IGSTK-Developers at public.kitware.com
> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers