1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

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

Discussion in 'Embedded' started by Mountain Bikn' Guy, Dec 17, 2003.

  1. 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
     
    Mountain Bikn' Guy, Dec 17, 2003
    #1
    1. Advertising

  2. Mountain Bikn' Guy

    Jack Klein Guest

    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
     
    Jack Klein, Dec 17, 2003
    #2
    1. Advertising

  3. Mountain Bikn' Guy

    Thad Smith Guest

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

    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
     
    Thad Smith, Dec 17, 2003
    #3
  4. 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
     
    Mountain Bikn' Guy, Dec 17, 2003
    #4
  5. Re: Trying to adhere to RTC design pattern, but I'm not actually running to completion

    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, Dec 17, 2003
    #5
  6. 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 (-aachen.de)
    Even if all the snow were burnt, ashes would remain.
     
    Hans-Bernhard Broeker, Dec 17, 2003
    #6
  7. Good points. I'll continue to work on the design.
     
    Mountain Bikn' Guy, Dec 17, 2003
    #7
  8. 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, Dec 20, 2003
    #8
  9. 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 (-aachen.de)
    Even if all the snow were burnt, ashes would remain.
     
    Hans-Bernhard Broeker, Dec 20, 2003
    #9
  10. Mountain Bikn' Guy

    CBFalconer Guest

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

    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!
     
    CBFalconer, Dec 21, 2003
    #10

  11. >
    > 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?
    >


    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.)
     
    Mountain Bikn' Guy, Dec 25, 2003
    #11
  12. Re: Trying to adhere to RTC design pattern, but I'm not actually running to completion

    CBFalconer <> wrote:

    > 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:

    [...]

    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 (-aachen.de)
    Even if all the snow were burnt, ashes would remain.
     
    Hans-Bernhard Broeker, Dec 29, 2003
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. franz

    design pattern

    franz, Mar 4, 2004, in forum: Embedded
    Replies:
    0
    Views:
    340
    franz
    Mar 4, 2004
  2. Replies:
    3
    Views:
    401
  3. Dan Robinson

    Pocket pc style word completion

    Dan Robinson, Feb 23, 2005, in forum: Tablet PC
    Replies:
    12
    Views:
    281
    flibbertigibbet007
    Feb 23, 2005
  4. Replies:
    0
    Views:
    215
  5. Tim Wescott

    Name this design pattern

    Tim Wescott, Mar 22, 2013, in forum: Embedded
    Replies:
    5
    Views:
    181
    MikeWhy
    Apr 6, 2013
Loading...

Share This Page