[IGSTK-Developers] State machine questions

[David Gobbi]

Kevin Gary wrote:

> 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...

I think that the answers to 1 & 4 are related.  The Attempt()
method is called by the state machine: it is indirectly called
from within ProcessInputs().

 - David

>
> 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
>
>
>
> _______________________________________________
> IGSTK-Developers mailing list
> IGSTK-Developers at public.kitware.com
> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>