The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

can state machine be paused and resumed?

I have a process which needs to respond to external messages, the type of processing will depend on what state the process is currently in.  Obviously I started refreshing my memory of state machines.

However, I've hit a snag and google doesn't seem to be of much help.

While my process is going through its states, it can be paused and resumed.  In other words, each state has a transition to the "paused" state.  It has a bad design smell since I have never seen state machines that look like fishing nets but I don't think I'm breaking the mathematical model.

The problem is how to get out of the "pause" state.  Since the process could have been paused from any state, I need to remember which state to get back to.  However, at least from what I recall, FSMs can't "remember" the previous state!

Obviously I can just add one line of Java which does remember the previous state, but I'd like to get some opinions here.  If I didn't have to hack, I would keep future refactoring in mind...including automatic generation of my state machines.  If I didn't have to hack, I could simply draw a state diagram on paper, show it to others without having to add caveats (which undermines the ability of state diagrams simple, and pretty much complete pictures of the underlying architecture).
falcon Send private email
Tuesday, October 16, 2007
 
 
I'm not really sure if this is of any use to you, but I made a mental note to look at this next time I had to touch any finite state machines in Java.

http://fsmgenerator.sourceforge.net/

Has popped up yet, so I'm not particularly familiar with using it, but may help you on the clean design front.
I'll do it tomorrow... Send private email
Tuesday, October 16, 2007
 
 
I don't think the pause state should be modeled as a state inside your FSM. It's more of a meta state that the machine is in, with the previous state being stored so that it can resume. If you do have the pause state then you run into the issue of how does it know which state to get back to. It would need to be a PDA in order to do that.

Think about running a debugger on a program with a breakpoint, the app doesn't keep track of where it was broken or where to go back to when it hits the breakpoint, the debugger stores that information so you can resume execution when you want to. Your FSM is the program running and the debugger is the framework that controls the execution of the FSM.
Jason Moore Send private email
Wednesday, October 17, 2007
 
 
If your finite state machine has states S1, S2, and S3, and then you want to add pause and resume funtionality to it, you now have S1, S2, S3, PauseS1, PauseS2, and PauseS3.
Patrick McKenzie (Bingo Card Creator) Send private email
Wednesday, October 17, 2007
 
 
Maybe you should be looking at a workflow engine, rather than an fsm.
Troels Knak-Nielsen Send private email
Wednesday, October 17, 2007
 
 
Don't change state if your paused signal is active.
You're not paranoid if ...
Wednesday, October 17, 2007
 
 
Maybe you can have a different paused substate of each major state.

Or have two state machines: one is the major state machine, and the other is the active/paused state machine, and events passed pass through (and may be eaten by) the active/paused state machine on their way through to the major state machine.
Christopher Wells Send private email
Wednesday, October 17, 2007
 
 
For simplicity, it seems like a good idea to treat the "Pause" state as a 'super-state' "above" the level of the State Machine itself.

If the only place you can go after a 'Pause' is directly back to the state 'Paused' from, then having 'Pause' 'remember' that state and restore it should keep the diagram (and the processing) more clear and straighforward.

The "canonical" way of handling this is to have an additional "pause state" for each of your original states.  I don't think that adds much to the diagram, and it probably complicates the state machine code itself.

And yes, you're departing from a 'pure' State Machine when you do this -- but since it simplifies the problem, I think it's a justifiable departure.

Be careful this doesn't become a slippery slope, though.  Next they'll want to 'return' to ANY state from "Pause", or change some data while IN "Pause", and pretty soon you'll have a real mess on your hands.
AllanL5
Wednesday, October 17, 2007
 
 
Thanks folks, lots of great responses.  I think it is better to model the pause/resume functionality outside my state machine.
falcon Send private email
Wednesday, October 17, 2007
 
 
If you're paused, why leave the current state?
xampl Send private email
Wednesday, October 17, 2007
 
 
Some state machine frameworks have support for deep history states. That might fit your need.

Thursday, October 18, 2007
 
 
Don't think of pause as a state ... think of it as not executing state transitions.  If you turn off the state machine (with persistence), it will naturally hold it's last state.
Steve Moyer Send private email
Thursday, October 18, 2007
 
 
A "pause" state means, your FSM is already in one state (out of S1,S2..Sn) and is waiting for the variables of the transition function to be satisfied for it to move to the next state. I don't think pause is a state. Thats all I remember about FSMs.
Askar Zaidi Send private email
Thursday, October 18, 2007
 
 
From the way you describe it, pause is not just another state but rather a super state.. thus you don't have to model it right now. Imagine your state machine is running on a single threaded CPU; it will be suspended/paused while running another task & you probably don't care; it just always restarts where you are at without the state machine being aware.

However, and it is a big 'however' be very careful of creep. In my example of a task being suspended & restarted, that is fine from diagram point of view, but in the real world machine, if your FSM is controlling fuel injectors in a car engine every 10 milliseconds and the pause is 20 milliseconds... then the pause state is critical.

Also, having seen a nasty bug in Windows CE + Casio hand-helds where the hardware would sleep & then wakeup with some events getting lost, then you really might find yourself sooner or later having to deal with a real pause state, where on wakeup you need to do house keeping (i.e. you may need to check that the end-of-month has not passed while paused)
Grant Black Send private email
Monday, November 12, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz