Motherboard Forums


Reply
Thread Tools Display Modes

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

 
 
Mountain Bikn' Guy
Guest
Posts: n/a
 
      12-17-2003, 02:41 AM
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 With Quote
 
 
 
 
Jack Klein
Guest
Posts: n/a
 
      12-17-2003, 04:56 AM
On Wed, 17 Dec 2003 02:41:43 GMT, "Mountain Bikn' Guy" <(E-Mail Removed)>
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
 
Reply With Quote
 
 
 
 
Thad Smith
Guest
Posts: n/a
 
      12-17-2003, 07:43 AM
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
 
Reply With Quote
 
Mountain Bikn' Guy
Guest
Posts: n/a
 
      12-17-2003, 02:41 PM
Hi Jack,
Comments inline.
Regards,
Mountain

"Jack Klein" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> 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



 
Reply With Quote
 
Mountain Bikn' Guy
Guest
Posts: n/a
 
      12-17-2003, 02:46 PM
Hi Thad,
Thanks for your reply.

"Thad Smith" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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


 
Reply With Quote
 
Hans-Bernhard Broeker
Guest
Posts: n/a
 
      12-17-2003, 03:22 PM
Mountain Bikn' Guy <(E-Mail Removed)> 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 ((E-Mail Removed)-aachen.de)
Even if all the snow were burnt, ashes would remain.
 
Reply With Quote
 
Mountain Bikn' Guy
Guest
Posts: n/a
 
      12-17-2003, 06:04 PM
Good points. I'll continue to work on the design.


 
Reply With Quote
 
Mountain Bikn' Guy
Guest
Posts: n/a
 
      12-20-2003, 02:47 PM
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.
>



 
Reply With Quote
 
Hans-Bernhard Broeker
Guest
Posts: n/a
 
      12-20-2003, 05:42 PM
Mountain Bikn' Guy <(E-Mail Removed)> 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 ((E-Mail Removed)-aachen.de)
Even if all the snow were burnt, ashes would remain.
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      12-21-2003, 03:36 AM
Hans-Bernhard Broeker wrote:
> Mountain Bikn' Guy <(E-Mail Removed)> 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 ((E-Mail Removed)) ((E-Mail Removed))
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!


 
Reply With Quote
 
 
 
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Tab-completion with shift key (tcsh, leopard 10.5.2) Jonathan Joseph Apple 6 05-27-2008 07:29 PM
Customizing XCode's code completion Martin Apple 0 04-03-2007 09:24 PM
Pocket pc style word completion Dan Robinson Tablet PC 12 02-23-2005 08:49 PM


All times are GMT. The time now is 01:05 PM.


Welcome!
Welcome to Motherboard Point
 

Advertisment