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

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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



Re: Trying to adhere to RTC design pattern, but I'm not actually running to completion
wrote in comp.arch.embedded:

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Trying to adhere to RTC design pattern, but I'm not actually running to completion
Hi Jack,
Comments inline.
Regards,
Mountain

Quoted text here. Click to load it

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


Quoted text here. Click to load it



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

Quoted text here. Click to load it




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 ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: Trying to adhere to RTC design pattern, but I'm not actually running to completion
Good points. I'll continue to work on the design.



Re: Trying to adhere to RTC design pattern, but I'm not actually running to completion
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

Quoted text here. Click to load it
break



Re: Trying to adhere to RTC design pattern, but I'm not actually running to completion
Quoted text here. Click to load it

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 ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: Trying to adhere to RTC design pattern, but I'm not actually running to completion
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it
... 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 ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: Trying to adhere to RTC design pattern, but I'm not actually running to completion

Quoted text here. Click to load it
[...]

Exactly.  A *finite* set, to point right at the problem.  The original
posting said that wouldn't do, in the case at hand --- he wanted to be
able to run essentially infinite loops inside a state machine's
actions, which would explode to an infinite number of states under the
scheme you outlined.

The OP wants to actually interrupt a single state (or rather the
time-consuming procedure that implements the transition from one state
to some other), yet still claim that all actions always run to
completion.  Sounds very much like trying to both have the cake and
eat it, to me.

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

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

Quoted text here. Click to load it

The generic (and probably best) answer to your question is that this is
accomplished through the use of the UML transition to (deep) history pattern
in connection with UML statecharts. (However, in the case of the simple
example, I suspect that even the history pattern isn't really required -- at
least it isn't required in the simple examples I worked up.)



Re: Trying to adhere to RTC design pattern, but I'm not actually running to completion
Quoted text here. Click to load it

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.
 
Quoted text here. Click to load it

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

Re: Trying to adhere to RTC design pattern, but I'm not actually running to completion
Hi Thad,
Thanks for your reply.

Quoted text here. Click to load it
call a
sequence
Of
RTC

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



Site Timeline