Established Automata Theory does not deal much with how a state transition is triggered, but assumes that the output is a function of the input (and the state) and that they are some kind of values.

For an Event-Driven State Machine, the input is an event that triggers a state transition and the output is actions executed during the state transition. It can analogously to the mathematical model of a Finite-State Machine be described as a set of relations of the following form:

State(S) x Event(E) -> Actions(A), State(S')

These relations are interpreted as follows: if we are in state S and event E occurs, we are to perform actions A and make a transition to state S'. Notice that S' can be equal to S and that A can be empty.

As A and S' depend only on S and E, the kind of state machine described here is a Mealy machine (see, for example, the Wikipedia article "Mealy machine").

Like most gen_ behaviors, gen_statem keeps a server Data besides the state. Because of this, and as there is no restriction on the number of states (assuming that there is enough virtual machine memory) or on the number of distinct input events, a state machine implemented with this behavior is in fact Turing complete. But it feels mostly like an Event-Driven Mealy machine.

If your process logic is convenient to describe as a state machine, and you want any of these gen_statem key features:

If so, or if possibly needed in future versions, then you should consider using gen_statem over gen_server.

For simple state machines not needing these features gen_server works just fine. It also has got smaller call overhead, but we are talking about something like 2 vs 3.3 microseconds call roundtrip time here, so if the server callback does just a little bit more than just replying, or if the call is not extremely frequent, that difference will be hard to notice.

The callback module contains functions that implement the state machine. When an event occurs, the gen_statem behaviour engine calls a function in the callback module with the event, current state and server data. This function performs the actions for this event, and returns the new state and server data and also actions to be performed by the behaviour engine.

The behaviour engine holds the state machine state, server data, timer references, a queue of posponed messages and other metadata. It receives all process messages, handles the system messages, and calls the callback module with machine specific events.

The gen_statem behavior supports two callback modes:

The callback mode is selected at server start and may be changed with a code upgrade/downgrade.

See the section Event Handler that describes the event handling callback function(s).

The callback mode is selected by implementing a mandatory callback function Module:callback_mode() that returns one of the callback modes.

The Module:callback_mode() function may also return a list containing the callback mode and the atom state_enter in which case State Enter Calls are activated for the callback mode.

Which callback function that handles an event depends on the callback mode:

The state is either the name of the function itself or an argument to it. The other arguments are the EventType described in section Event Types, the event dependent EventContent, and the current server Data.

State enter calls are also handled by the event handler and have slightly different arguments. See the section State Enter Calls.

The event handler return values are defined in the description of Module:StateName/3 in the gen_statem manual page, but here is a more readable list:

In the first section Event-Driven State Machines actions were mentioned as a part of the general state machine model. These general actions are implemented with the code that callback module gen_statem executes in an event-handling callback function before returning to the gen_statem engine.

There are more specific state-transition actions that a callback function can command the gen_statem engine to do after the callback function return. These are commanded by returning a list of actions in the return value from the callback function. These are the possible state transition actions:

For details, see the gen_statem(3) manual page for type action(). You can, for example, reply to many callers, generate multiple next events, and set a time-out to use absolute instead of relative time (using the Opts field).

Events are categorized in different event types. Events of all types are for a given state handled in the same callback function, and that function gets EventType and EventContent as arguments.

The following is a complete list of event types and where they come from:

The gen_statem behavior can if this is enabled, regardless of callback mode, automatically call the state callback with special arguments whenever the state changes so you can write state enter actions near the rest of the state transition rules. It typically looks like this:

StateName(enter, OldState, Data) ->
    ... code for state enter actions here ...
    {keep_state, NewData};
StateName(EventType, EventContent, Data) ->
    ... code for actions here ...
    {next_state, NewStateName, NewData}.

Since the state enter call is not an event there are restrictions on the allowed return value and State Transition Actions. You may not change the state, postpone this non-event, or insert events.

The first state that is entered will get a state enter call with OldState equal to the current state.

You may repeat the state enter call using the {repeat_state,...} return value from the Event Handler. In this case OldState will also be equal to the current state.

Depending on how your state machine is specified, this can be a very useful feature, but it forces you to handle the state enter calls in all states. See also the State Enter Actions chapter.

A door with a code lock can be seen as a state machine. Initially, the door is locked. When someone presses a button, an event is generated. The pressed buttons are collected, up to the number of buttons in the correct code. If correct, the door is unlocked for 10 seconds. If not correct, we wait for a new button to be pressed.

This code lock state machine can be implemented using gen_statem with the following callback module:

The code is explained in the next sections.

In the example in the previous section, gen_statem is started by calling code_lock:start_link(Code):

start_link calls function gen_statem:start_link/4, which spawns and links to a new process, a gen_statem.

If name registration succeeds, the new gen_statem process calls callback function code_lock:init(Code). This function is expected to return {ok, State, Data}, where State is the initial state of the gen_statem, in this case locked; assuming that the door is locked to begin with. Data is the internal server data of the gen_statem. Here the server data is a map with key code that stores the correct button sequence, key length store its length, and key buttons that stores the collected buttons up to the same length.

Function gen_statem:start_link is synchronous. It does not return until the gen_statem is initialized and is ready to receive events.

Function gen_statem:start_link must be used if the gen_statem is part of a supervision tree, that is, started by a supervisor. Another function, gen_statem:start can be used to start a standalone gen_statem, that is, a gen_statem that is not part of a supervision tree.

Function Module:callback_mode/0 selects the CallbackMode for the callback module, in this case state_functions. That is, each state has got its own handler function:

The function notifying the code lock about a button event is implemented using gen_statem:cast/2:

The first argument is the name of the gen_statem and must agree with the name used to start it. So, we use the same macro ?NAME as when starting. {button,Button} is the event content.

The event is sent to the gen_statem. When the event is received, the gen_statem calls StateName(cast, Event, Data), which is expected to return a tuple {next_state, NewStateName, NewData}, or {next_state, NewStateName, NewData, Actions}. StateName is the name of the current state and NewStateName is the name of the next state to go to. NewData is a new value for the server data of the gen_statem, and Actions is a list of actions to be performed by the gen_statem engine.

In state locked, when a button is pressed, it is collected with the last pressed buttons up to the length of the correct code, and compared with the correct code. Depending on the result, the door is either unlocked and the gen_statem goes to state open, or the door remains in state locked.

When changing to state open, the collected buttons are reset, the lock unlocked, and a state timer for 10 s is started.

In state open, a button event is ignored by staying in the same state. This can also be done by returning {keep_state, Data} or in this case since Data unchanged even by returning keep_state_and_data.

When a correct code has been given, the door is unlocked and the following tuple is returned from locked/2:

10,000 is a time-out value in milliseconds. After this time (10 seconds), a time-out occurs. Then, StateName(state_timeout, lock, Data) is called. The time-out occurs when the door has been in state open for 10 seconds. After that the door is locked again:

The timer for a state time-out is automatically cancelled when the state machine changes states. You can restart a state time-out by setting it to a new time, which cancels the running timer and starts a new. This implies that you can cancel a state time-out by restarting it with time infinity.

Sometimes events can arrive in any state of the gen_statem. It is convenient to handle these in a common state handler function that all state functions call for events not specific to the state.

Consider a code_length/0 function that returns the length of the correct code. We dispatch all events that are not state-specific to the common function handle_common/3:

Another way to do it is through a convenience macro ?HANDLE_COMMON/0:

This example uses gen_statem:call/2, which waits for a reply from the server. The reply is sent with a {reply,From,Reply} tuple in an action list in the {keep_state, ...} tuple that retains the current state. This return form is convenient when you want to stay in the current state but do not know or care about what it is.

If the common event handler needs to know the current state a function handle_common/4 can be used instead:

If Callback Mode handle_event_function is used, all events are handled in Module:handle_event/4 and we can (but do not have to) use an event-centered approach where we first branch depending on event and then depending on state:

A time-out feature inherited from gen_statem's predecessor gen_fsm, is an event time-out, that is, if an event arrives the timer is cancelled. You get either an event or a time-out, but not both.

It is ordered by the state transition action {timeout,Time,EventContent}, or just an integer Time, even without the enclosing actions list (the latter is a form inherited from gen_fsm.

This type of time-out is useful for example to act on inactivity. Let us restart the code sequence if no button is pressed for say 30 seconds:

Whenever we receive a button event we start an event time-out of 30 seconds, and if we get an event type timeout we reset the remaining code sequence.

An event time-out is cancelled by any other event so you either get some other event or the time-out event. It is therefore not possible nor needed to cancel or restart an event time-out. Whatever event you act on has already cancelled the event time-out...

Note that an event time-out does not work well with when you have for example a status call as in All State Events, or handle unknown events, since all kinds of events will cancel the event time-out.

The previous example of state time-outs only work if the state machine stays in the same state during the time-out time. And event time-outs only work if no disturbing unrelated events occur.

You may want to start a timer in one state and respond to the time-out in another, maybe cancel the time-out without changing states, or perhaps run multiple time-outs in parallel. All this can be accomplished with generic time-outs. They may look a little bit like event time-outs but contain a name to allow for any number of them simultaneously and they are not automatically cancelled.

Here is how to accomplish the state time-out in the previous example by instead using a generic time-out named for example open:

Specific generic time-outs can just as State Time-Outs be restarted or cancelled by setting it to a new time or infinity.

In this particular case we do not need to cancel the timeout since the timeout event is the only possible reason to change the state from open to locked.

Instead of bothering with when to cancel a time-out, a late time-out event can be handled by ignoring it if it arrives in a state where it is known to be late.

The most versatile way to handle time-outs is to use Erlang Timers; see erlang:start_timer/3,4. Most time-out tasks can be performed with the time-out features in gen_statem, but an example of one that can not is if you should need the return value from erlang:cancel_timer(Tref), that is; the remaining time of the timer.

Here is how to accomplish the state time-out in the previous example by instead using an Erlang Timer:

Removing the timer key from the map when we change to state locked is not strictly necessary since we can only get into state open with an updated timer map value. But it can be nice to not have outdated values in the state Data!

If you need to cancel a timer because of some other event, you can use erlang:cancel_timer(Tref). Note that a time-out message cannot arrive after this, unless you have postponed it before (see the next section), so ensure that you do not accidentally postpone such messages. Also note that a time-out message may have arrived just before you cancelling it, so you may have to read out such a message from the process mailbox depending on the return value from erlang:cancel_timer(Tref).

Another way to handle a late time-out can be to not cancel it, but to ignore it if it arrives in a state where it is known to be late.

If you want to ignore a particular event in the current state and handle it in a future state, you can postpone the event. A postponed event is retried after the state has changed, that is, OldState =/= NewState.

Postponing is ordered by the state transition State Transition Action postpone.

In this example, instead of ignoring button events while in the open state, we can postpone them and they are queued and later handled in the locked state:

Since a postponed event is only retried after a state change, you have to think about where to keep a state data item. You can keep it in the server Data or in the State itself, for example by having two more or less identical states to keep a boolean value, or by using a complex state (see section Complex State) with Callback Mode handle_event_function. If a change in the value changes the set of events that is handled, then the value should be kept in the State. Otherwise no postponed events will be retried since only the server Data changes.

This is not important if you do not postpone events. But if you later decide to start postponing some events, then the design flaw of not having separate states when they should be, might become a hard to find bug.

Say you have a state machine specification that uses state enter actions. Allthough you can code this using inserted events (described in the next section), especially if just one or a few states has got state enter actions, this is a perfect use case for the built in State Enter Calls.

You return a list containing state_enter from your callback_mode/0 function and the gen_statem engine will call your state callback once with the arguments (enter, OldState, ...) whenever the state changes. Then you just need to handle these event-like calls in all states.

You can repeat the state enter code by returning one of {repeat_state, ...}, {repeat_state_and_data,_} or repeat_state_and_data that otherwise behaves exactly like their keep_state siblings. See the type state_callback_result() in the reference manual.

It can sometimes be beneficial to be able to generate events to your own state machine. This can be done with the State Transition Action {next_event,EventType,EventContent}.

You can generate events of any existing type, but the internal type can only be generated through action next_event. Hence, it cannot come from an external source, so you can be certain that an internal event is an event from your state machine to itself.

One example for this is to pre-process incoming data, for example decrypting chunks or collecting characters up to a line break.

Purists may argue that this should be modelled with a separate state machine that sends pre-processed events to the main state machine, but to decrease overhead the small pre-processing state machine can be implemented in the common state event handling of the main state machine using a few state data variables that then sends the pre-processed events as internal events to the main state machine. Using internal events also can make it easier to synchronize the state machines.

A variant of this is to use a Complex State with One Event Handler. The state is then modeled with for example a tuple {MainFSMState,SubFSMState}.

To illustrate this we make up an example where the buttons instead generate down and up (press and release) events, and the lock responds to an up event only after the corresponding down event.

If you start this program with code_lock:start([17]) you can unlock with code_lock:down(17), code_lock:up(17).

This section includes the example after most of the mentioned modifications and some more using state enter calls, which deserves a new state diagram:

Notice that this state diagram does not specify how to handle a button event in the state open. So, you need to read in some side notes, that is, here: that unspecified events shall be postponed (handled in some later state). Also, the state diagram does not show that the code_length/0 call must be handled in every state.

Notice that postponing buttons from the open state to the locked state feels like a strange thing to do for a code lock, but it at least illustrates event postponing.

The example servers so far in this chapter print the full internal state in the error log, for example, when killed by an exit signal or because of an internal error. This state contains both the code lock code and which digits that remain to unlock.

This state data can be regarded as sensitive, and maybe not what you want in the error log because of some unpredictable event.

Another reason to filter the state can be that the state is too large to print, as it fills the error log with uninteresting details.

To avoid this, you can format the internal state that gets in the error log and gets returned from sys:get_status/1,2 by implementing function Module:format_status/2, for example like this:

It is not mandatory to implement a Module:format_status/2 function. If you do not, a default implementation is used that does the same as this example function without filtering the Data term, that is, StateData = {State,Data}, in this example containing sensitive information.

The callback mode handle_event_function enables using a non-atom state as described in section Callback Modes, for example, a complex state term like a tuple.

One reason to use this is when you have a state item that when changed should cancel the State Time-Out, or one that affects the event handling in combination with postponing events. We will go for the latter and complicate the previous example by introducing a configurable lock button (this is the state item in question), which in the open state immediately locks the door, and an API function set_lock_button/1 to set the lock button.

Suppose now that we call set_lock_button while the door is open, and we have already postponed a button event that was the new lock button:

We could say that the button was pressed too early so it is not to be recognized as the lock button. Or we can make the lock button part of the state so when we then change the lock button in the locked state, the change becomes a state change and all postponed events are retried, therefore the lock is immediately locked!

We define the state as {StateName,LockButton}, where StateName is as before and LockButton is the current lock button:

If you have many servers in one node and they have some state(s) in their lifetime in which the servers can be expected to idle for a while, and the amount of heap memory all these servers need is a problem, then the memory footprint of a server can be mimimized by hibernating it through proc_lib:hibernate/3.

We can in this example hibernate in the {open,_} state, because what normally occurs in that state is that the state time-out after a while triggers a transition to {locked,_}:

The atom hibernate in the action list on the last line when entering the {open,_} state is the only change. If any event arrives in the {open,_}, state, we do not bother to rehibernate, so the server stays awake after any event.

To change that we would need to insert action hibernate in more places. For example, the state-independent set_lock_button operation would have to use hibernate but only in the {open,_} state, which would clutter the code.

Another not uncommon scenario is to use the Event Time-Out to trigger hibernation after a certain time of inactivity. There is also a server start option {hibernate_after, Timeout} for start/3,4 or start_link/3,4 that may be used to automatically hibernate the server.

This particular server probably does not use heap memory worth hibernating for. To gain anything from hibernation, your server would have to produce non-insignificant garbage during callback execution, for which this example server can serve as a bad example.