Trying to adhere to RTC design pattern, but I'm not actually running to completion

I have just designed a statechart that includes four states that each call a
method that performs some very long looping. The states execute in sequence
(synchronously). I wish to allow the user to cancel within this looping. Of
course, then the it looks as if I am violating the design principle of RTC
(and I don't want to do that).

However, in my statechart there is a state I call "Continuing". It maintains
state info about which was the last of the long running states to completely
finish. If the user has cancelled at some point, then resumed, the
Continuing state is entered, and the next long running state is chosen
appropriately.

In my view, I am designing in accord with RTC. For example, my logic is that
the completion could either be via finishing the loop or by early
cancellation, and it is still RTC. I feel my states behave in accord with
RTC principles.

My question is whether others have encountered my type of thinking about
design and whether I should be concerned about a flaw in my logic. Any
comments or corrections are appreciated!

Regards,
Mountain

On Wed, 17 Dec 2003 02:41:43 GMT, "Mountain Bikn' Guy" <>
wrote in comp.arch.embedded:

> I have just designed a statechart that includes four states that each call a
> method that performs some very long looping. The states execute in sequence
> (synchronously). I wish to allow the user to cancel within this looping. Of
> course, then the it looks as if I am violating the design principle of RTC
> (and I don't want to do that).
>
> However, in my statechart there is a state I call "Continuing". It maintains
> state info about which was the last of the long running states to completely
> finish. If the user has cancelled at some point, then resumed, the
> Continuing state is entered, and the next long running state is chosen
> appropriately.
>
> In my view, I am designing in accord with RTC. For example, my logic is that
> the completion could either be via finishing the loop or by early
> cancellation, and it is still RTC. I feel my states behave in accord with
> RTC principles.
>
> My question is whether others have encountered my type of thinking about
> design and whether I should be concerned about a flaw in my logic. Any
> comments or corrections are appreciated!
>
> Regards,
> Mountain

What do you mean by "RTC design pattern"? Real Time Clock? Real Time
Control? Really Tiny Calculator? Try to describe your acronyms.

I have never heard of designing any sort of software around a rigid
state machine mode, where states could not be skipped.

One technique that I like to avoid spaghetti state transitions has a
state machine that enters each state in turn. Each state accepts
events, one of which is "enter state". Each state returns a value for
each event it receives. The return value is essentially Boolean, one
value meaning remain in this state, the other meaning advance to the
next state.

Each state machine has a data store associated with it. If some event
in the second state should cause the skipping of states 3 and 4, state
2 sets some flag in the data store and returns "next state".

State 3 is then invoked with an "enter state" event. It determines
the flag in the data store and determines that it has nothing to do,
so it returns "next state". This same sequence is repeated with state
4, which likewise decides not to do anything. So the state machine
advances to state 5 (or perhaps wraps around back to the idle state,
state 0).

I like this model for several reasons. One is that neither any state
nor the state machine engine needs to know the order of states at all,
it is inherent in the table of state event functions.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

Mountain Bikn' Guy wrote:
>
> I have just designed a statechart that includes four states that each call a
> method that performs some very long looping. The states execute in sequence
> (synchronously). I wish to allow the user to cancel within this looping. Of
> course, then the it looks as if I am violating the design principle of RTC
> (and I don't want to do that).

Help me here, since I haven't looked at formal state machines in a
while. My understanding is that a state in a state machine is
effectively a resting point at which no activity occurs. When an event
is received that matches a trigger for a transition from the state, the
transition can invoke activity. When the activity is finished, the
machine goes to the specified next state to await another event. The
point here is that activity occurs between states, not within a state
(although it can occur on a loop back to the same state).

With that model, a state doesn't execute anything. A sequence of states
occur when a particular pattern of events occur that select a particular
path between events. If activity is continually occurring without
external activation, I think that a state machine is not the best model.

> However, in my statechart there is a state I call "Continuing". It maintains
> state info about which was the last of the long running states to completely
> finish. If the user has cancelled at some point, then resumed, the
> Continuing state is entered, and the next long running state is chosen
> appropriately.
>
> In my view, I am designing in accord with RTC. For example, my logic is that
> the completion could either be via finishing the loop or by early
> cancellation, and it is still RTC. I feel my states behave in accord with
> RTC principles.

If the cancel request is considered an event to the state machine, I
would say that you are not running to completion. I don't know what
that model violation is costing you.

I can conceive of two other ways of looking at the problem that wouldn't
cause this:

1. Make a state "Finished small step"
Then the transitions out of that are
a. cancel request: do cancellation activity and go to appropriate
state
b: finished all steps: go to rest state for completion
c: no cancel request and not finished: do another small step, go to
finished small step

The last transition is done as a result of no explicit external
event, so might not be appropriate.

2. Consider the cancel request as part of the data which the activity
processes. Thus the activity invoked is "crunch data until completion
or cancel flag set". Then, when the cancellation flag is set, the
activity is finished by definition. State is saved outside the machine
to allow it to resume. The problem here is that the cancellation
request is considered data, not an event, which is slightly awkward.

Thad

Hi Jack,
Comments inline.
Regards,
Mountain

"Jack Klein" <> wrote in message
news:...
>
> What do you mean by "RTC design pattern"? Real Time Clock? Real Time
> Control? Really Tiny Calculator? Try to describe your acronyms.

I apologize. I'm not in the embedded systems area, so I just assumed the
acronym was clear in this area. It means "run to completion." RTC can be
considered a state machine design principle.

Here's a definition of this approach:
A method of implementation in which concurrent applications are organized as
cooperative collections of active objects, each endowed with a thread of
execution. In such applications, active objects don't share memory or any
other resources, communicate only by sending and receiving events, and
process each event in a run-to-completion (RTC) fashion.

The term "state machine" can be substituted for "active object" above.

So as you can probably see now, I'm trying to adhere to this definition,
including run-to-completion, yet I also want to accomodate the need to break
out of a long operation on a cancel request. Given that the long operation
is a loop, it isn't possible to take the normal approach of splitting it
into several discrete states.

Regards,
Mountain


>
> I have never heard of designing any sort of software around a rigid
> state machine mode, where states could not be skipped.
>
> One technique that I like to avoid spaghetti state transitions has a
> state machine that enters each state in turn. Each state accepts
> events, one of which is "enter state". Each state returns a value for
> each event it receives. The return value is essentially Boolean, one
> value meaning remain in this state, the other meaning advance to the
> next state.
>
> Each state machine has a data store associated with it. If some event
> in the second state should cause the skipping of states 3 and 4, state
> 2 sets some flag in the data store and returns "next state".
>
> State 3 is then invoked with an "enter state" event. It determines
> the flag in the data store and determines that it has nothing to do,
> so it returns "next state". This same sequence is repeated with state
> 4, which likewise decides not to do anything. So the state machine
> advances to state 5 (or perhaps wraps around back to the idle state,
> state 0).
>
> I like this model for several reasons. One is that neither any state
> nor the state machine engine needs to know the order of states at all,
> it is inherent in the table of state event functions.
>
> --
> Jack Klein
> Home: http://JK-Technology.Com
> FAQs for
> comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
> comp.lang.c++ http://www.parashift.com/c++-faq-lite/
> alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

Hi Thad,
Thanks for your reply.

"Thad Smith" <> wrote in message
news:...
> Mountain Bikn' Guy wrote:
> >
> > I have just designed a statechart that includes four states that each
call a
> > method that performs some very long looping. The states execute in
sequence
> > (synchronously). I wish to allow the user to cancel within this looping.
Of
> > course, then the it looks as if I am violating the design principle of
RTC
> > (and I don't want to do that).
>
> Help me here, since I haven't looked at formal state machines in a
> while. My understanding is that a state in a state machine is
> effectively a resting point at which no activity occurs.

There are 2 classical definitions: Mealy and Moore automata. In Mealy
automata, actions are associated with transitions. In Moore automata,
actions are associated with states. I actually use something of a blend, as
described by Miro Samek (www.quantum-leaps.com), which is basically the UML
definition of a statechart.

Regards,
Mountain

Mountain Bikn' Guy <> wrote:

> I apologize. I'm not in the embedded systems area, so I just assumed the
> acronym was clear in this area. It means "run to completion." RTC can be
> considered a state machine design principle.

> Here's a definition of this approach:
> A method of implementation in which concurrent applications are organized as
> cooperative collections of active objects, each endowed with a thread of
> execution. In such applications, active objects don't share memory or any
> other resources, communicate only by sending and receiving events, and
> process each event in a run-to-completion (RTC) fashion.

> The term "state machine" can be substituted for "active object" above.

> So as you can probably see now, I'm trying to adhere to this definition,
> including run-to-completion, yet I also want to accomodate the need to break
> out of a long operation on a cancel request.

In that case, I think you have an ultimately unsolvable conflict of
goals on your hand. An event can either always be handled to
completion, or its handling can be interruptable by another event (the
"cancel request"). You can't have it both ways.

And you can't interrupt a state machine in the middle of a transition
and continue it later, an unknown number of times. If you could, it
would no longer be a state machine.

--
Hans-Bernhard Broeker ()
Even if all the snow were burnt, ashes would remain.

Good points. I'll continue to work on the design.

For anyone still interested in this topic, it turns out that it is indeed
possible to "have it both ways." And it actually turns out to be trivial,
when framed correctly. The best example is a state machine for a toaster
oven. When it is in the toasting state (which finishes only when it reaches
the correct "browning" level set by the dial), it is possible to respond to
a door-open even by exiting the toasting state (turning off the heating
elements, turning on the interior light, etc.), and then re-enter the
toasting state when the door closes. All this can be accomplished in a state
machine that is designed completely in accord with "run to completion"
principles.
Regards,
Mountain

>
> > So as you can probably see now, I'm trying to adhere to this definition,
> > including run-to-completion, yet I also want to accomodate the need to
break
> > out of a long operation on a cancel request.
>
> In that case, I think you have an ultimately unsolvable conflict of
> goals on your hand. An event can either always be handled to
> completion, or its handling can be interruptable by another event (the
> "cancel request"). You can't have it both ways.
>

Mountain Bikn' Guy <> wrote:
> For anyone still interested in this topic, it turns out that it is indeed
> possible to "have it both ways." And it actually turns out to be trivial,
> when framed correctly. The best example is a state machine for a toaster
> oven. When it is in the toasting state (which finishes only when it reaches
> the correct "browning" level set by the dial), it is possible to respond to
> a door-open even by exiting the toasting state (turning off the heating
> elements, turning on the interior light, etc.), and then re-enter the
> toasting state when the door closes. All this can be accomplished in a state
> machine that is designed completely in accord with "run to completion"
> principles.

Looks like your interpretation of at least one of the two key terms in
this, "state machine" and "run-to-completion", is different than mine,
then.

In your description of the RTC pattern, it said that individual states
of the statement do not share any information, and communicate only
through events. But the even "door being opened" comes from outside
the state machine, so it can't contain any internal information of the
current state of the state machine.

How, then, does your oven pass information about the target browning
level / remaining toasting time from the "toasting" across the "door
opened during toasting" and back to the "toasting" state, without
breaking either the definition of a state machine, or that of the RTC
pattern?

--
Hans-Bernhard Broeker ()
Even if all the snow were burnt, ashes would remain.

Hans-Bernhard Broeker wrote:
> Mountain Bikn' Guy <> wrote:
>
> > For anyone still interested in this topic, it turns out that it
> > is indeed possible to "have it both ways." And it actually turns
.... snip ...
>
> Looks like your interpretation of at least one of the two key
> terms in this, "state machine" and "run-to-completion", is
> different than mine, then.
>
> In your description of the RTC pattern, it said that individual
> states of the statement do not share any information, and
> communicate only through events. But the even "door being opened"
> comes from outside the state machine, so it can't contain any
> internal information of the current state of the state machine.
.... snip ...

I have no idea what esoteric principles you two are attempting to
use, but this toast problem via state machine requires a set of
states:

toastfor(XX)seconds or until interrupted or for 1 second, set next
state to toastfor(XX-1)seconds or .... Each state exits through a
dosomethingelsethennextstate routine.

nextstate := initialstate;
REPEAT
REPEAT
nextstate := donextstate(nextstate);
UNTIL interrupted or (nextstate = done);
IF interrupted THEN serviceinterrupt;
UNTIL nextstate = done;

The point being that the state machine timing controls the time
quantization of any interrupts.

--
Chuck F () ()
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!