Skipping tasks due to common origin?

[kelbiedavidson]

I have a state machine with 4 states, (A,B,C and DONE). Since I am trying to set up a system can be resumed after interruption, each state is intentionally "stateless" and is passed all the information it needs via its payload.

• A will prepend to the plan a transition to B on an event, providing a list and an index of 0 as payload;
• C will also prepend to the plan a transition to B on an event, providing a different list and an index of 0 as its payload;
• B will process the item at position (index in the list. It will then add to the plan a transition to process the next (index + 1) item in the list. If there are no more items to process, it will transition to DONE.
• DONE will simply succeed, proceeding to the next item in the plan;

The transition A -> B or C -> B can occur at any time via an event.

For example my plan stack throughout multiple updates might look like:

• A -> B (index = 0, list of 100 items)
  -- UPDATE --
  B -> B (index = 1, list of 100 items)
  -- UPDATE --
  B -> B (index = 2, list of 100 items)
  -- Event C --
  C-> B (index = 0, list of 250 items)
  B -> B (index = 2, list of 100 items)
  -- UPDATE --
  B -> B (index = 0, list of 250 items)
  B -> B (index = 2, list of 100 items)

However, since both states on the stack have the same origin, the library drops the first and automatically transitions to the second.

Is this intentional or am I misusing the library? Is there a better way to achieve what I am going for?

[andrew-gresyk]

Could you post a minimal example I could try out for myself to avoid any misunderstanding?

[kelbiedavidson]

#define HFSM2_ENABLE_LOG_INTERFACE
#define HFSM2_ENABLE_PLANS

#include <hfsm2/machine.hpp>
#include <iostream>
#include <vector>

struct Payload
{
    int id = 0;
};

using M = hfsm2::MachineT<hfsm2::Config::PayloadT<Payload>>;

#define S(s) struct s

using FSM = M::PeerRoot<
    S(A),
    S(B),
    S(C),
    S(Done)
>;

#undef S

struct CustomState : FSM::State
{
    static void prependToPlan(PlanControl& control, Plan::Task task)
    {
        auto plan = control.plan();
        std::vector<Plan::Task> existing_tasks;

        for (auto it = plan.begin(); it; ++it)
        {
            existing_tasks.push_back(*it);
        }

        control.plan().clear();
        if (task.payload())  control.plan().changeWith(task.origin, task.destination, *task.payload());
        else  control.plan().change(task.origin, task.destination);

        for (const auto& t : existing_tasks)
        {
            if (t.payload())  control.plan().changeWith(t.origin, t.destination, *t.payload());
            else  control.plan().change(t.origin, t.destination);
        }
    }

    int planCount(PlanControl& control)
    {
        auto plan = control.plan();
        int plan_count = 0;
        for (auto it = plan.begin(); it; ++it)  plan_count++;
        return plan_count;
    }
};

struct A : CustomState
{
    void enter(PlanControl& control)
    {
        printf("A::enter()\n");

        control.plan().changeWith<A, B>(Payload{.id = 1});
        control.plan().changeWith<Done, B>(Payload{.id = 2});
        control.plan().changeWith<Done, B>(Payload{.id = 3});
    }

    void update(FullControl& control)
    {
        printf("A::update()\n");
        control.succeed();
    }
};

struct B : CustomState
{
    void enter(PlanControl& control)
    {
        auto transitions = control.currentTransitions();
        auto payload = transitions[0].payload();
        printf("B::enter() with id %ld and %d tasks in the plan ", payload->id, planCount(control));
        if (payload->id == 0)
        {
            prependToPlan(control, Plan::Task(
                stateId<B>(),
                stateId<Done>(),
                hfsm2::TransitionType::CHANGE
            ));
        }
        else
        {
            prependToPlan(control, Plan::Task(
                stateId<C>(),
                stateId<B>(),
                hfsm2::TransitionType::CHANGE,
                 Payload{.id = payload->id - 1}
            ));
            prependToPlan(control, Plan::Task(
                stateId<B>(),
                stateId<C>(),
                hfsm2::TransitionType::CHANGE
            ));
        }
    }

    void update(FullControl& control)
    {
        printf("B::update()\n");
        control.succeed();
    }
};

struct C : CustomState
{
    void enter(PlanControl& control)
    {
        printf("C::enter()\n");
    }

    void update(FullControl& control)
    {
        printf("C::update()\n");
        control.succeed();
    }
};

struct Done : CustomState
{
    void enter(PlanControl& control)
    {
        printf("Done::enter()\n");
    }

    void update(FullControl& control)
    {
        printf("Done::update()\n");
        control.succeed();
    }
};

int main(int argc, char* argv[])
{
    FSM::Instance fsm;

    for (int i = 0; i < 10; i++)
    {
        printf("--- update() #%d\n", i);
        fsm.update();
    }
    printf("\n=== Done ===\n");

    return 0;
}

STDOUT:

A::enter()
--- update() #0
A::update()
B::enter() with id 1 and 2 tasks in the plan --- update() #1
B::update()
C::enter()
--- update() #2
C::update()
B::enter() with id 0 and 2 tasks in the plan --- update() #3
B::update()
Done::enter()
--- update() #4
Done::update()
B::enter() with id 2 and 0 tasks in the plan --- update() #5
B::update()
C::enter()
--- update() #6
C::update()
--- update() #7
C::update()
--- update() #8
C::update()
--- update() #9
C::update()

=== Done ===

[andrew-gresyk]

Prepending to plan is coming in the next version.

Interestingly, running the snippet above on MSVC 17 generates different output:

A::enter()
--- update() #0
A::update()
B::enter() with id 1 and 2 tasks in the plan --- update() #1
B::update()
C::enter()
--- update() #2
C::update()
B::enter() with id 0 and 2 tasks in the plan --- update() #3
B::update()
Done::enter()
--- update() #4
Done::update()
A::enter()
--- update() #5
A::update()
--- update() #6
A::update()
--- update() #7
A::update()
--- update() #8
A::update()
--- update() #9
A::update()

=== Done ===

[kelbiedavidson]

That is interesting...

It would also be useful to allow states to emit events. I have found a temporary work around passing the FSM within the context.

[andrew-gresyk]

I need to explain this better in docs.

The behavior you're experiencing is by design.
The intent with it is to allow multiple transitions to be initiated within a single task.

In a hierarchical FSM, thanks to the existence of orthogonal region, it is sometimes useful to initiate multiple transitions together (e.g. to different sub-states of an orthogonal region).

Suppose, we have the following FSM:

using FSM = M::PeerRoot<
				S(A)
				M::Orthogonal<S(B),
					M::Composite<S(B_1),
						S(B_1_1),
						S(B_1_2),
						S(B_1_3),
					>,
					M::Composite<S(B_2),
						S(B_2_1),
						S(B_2_2),
						S(B_2_3),
					>
				>
			>;

Now, suppose we want to transition from A to B, but rather than activating the default initial sub-states B_1_1 and B_2_1, we need B_1_2 and B_2_3 to be activated instead.

To do that outside of plans, two transitions can be initiated before calling update() which will enact the transitions:

fsm.chaneTo<B_1>();
fsm.chaneTo<C_1>();
fsm.update();

Or, by using immediateChangeTo() (which will trigger transition processing), if the update() cycle is undesirable:

fsm.chaneTo<B_1>();
fsm.immediateChangeTo<C_1>();

With that in mind, plans needed a symmetrical workflow, thus the behavior you observed.