Big state machines
Mon Apr 18 21:35:07 CEST 2005
On Mon, Apr 18, 2005 at 12:47:33PM +0300, joel reymont wrote:
} A big thanks to all who replied. I had the insight over the weekend
} that as Ulf said the code can be rewritten with selective receive. I
} decided to stick with gen_fsm, though. I´ll post if I have problems.
A classical finite state machine has no state data. It only reacts to
input events performing an action such as sending a signal and moving
to another one of a finite number of states. The only memory it has is
it's program for the state it's in. Once it has moved to another state
it has no knowledge of what state it was last in or anything which has
The gen_fsm behaviour is an example of an extended communicating finite
state machine. The difference being that it has state data; it remembers
things (if we took away the StateData argument to the state handlers it
would be a classical FSM). This expands their utility but increases the
complexity. A simple use of state data would be to keep counters so that
we could execute exceptions such as maximum retries. On the other hand
you could take an FSM with ten states and reduce it to one by abusing the
If you can identify the natural FSMs in your problem and map them one to
one to gen_fsm processes it should be quite mangeable. If it seems
unmanageable you've probably overloaded it.
An advanced concept is that each of the states may itself be a state
machine. If you can map the main problem to a reasonably sozed state
machine you may be able to map the details onto sub state machines.
SDL is a useful modeling tool which maps well onto Erlang however it does
extend things further to use selective receive. SDL has a save which
says that it should leave any unmentioned events in the event queue. I
still map SDL onto gen_fsms though and use state data to retain the saved
signals. I've often wondered about building a new behaviour to handle
selective receive but have yet to investigate it.
More information about the erlang-questions