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

Reply to
Mountain Bikn' Guy
Loading thread data ...

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

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
 Click to see the full signature
Reply to
Jack Klein

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.

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.

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

Reply to
Thad Smith

Hi Jack, Comments inline. Regards, Mountain

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

Reply to
Mountain Bikn' Guy

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

formatting link
which is basically the UML definition of a statechart.

Regards, Mountain

Reply to
Mountain Bikn' Guy

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 (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

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

Reply to
Mountain Bikn' Guy

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

break

Reply to
Mountain Bikn' Guy

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 (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

... snip ...

... 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 (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
 Click to see the full signature
Reply to
CBFalconer

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

Reply to
Mountain Bikn' Guy

[...]

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 (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.