StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POType_index use, destruction, and synchronization in the state machine implementation
primarykey
Id
20073758
data
AcceptedAnswerId
20079943
AnswerCount
1
ClosedDate
CommentCount
3
CommunityOwnedDate
CreationDate
2013-11-19T14:10:20.483
FavoriteCount
0
LastActivityDate
2014-09-06T01:44:40.107
LastEditDate
2014-09-06T01:44:40.107
LastEditorUserId
836097
OwnerUserId
836097
ParentId
0
PostTypeId
1
Score
0
ViewCount
333
LastEditorDisplayName
text
Body
In an ongoing project there is a need to have multiple finite state machines implemented. A common layer would be nice so that similar checks and balances can be developed. The state machines' requirements are diverse enough so I wanted to have data types to be determined outside of the FSM template as a user responsibility. Also I wanted to have persistent data totally controlled by an FSM implementation author. Finally, thread-safety is a must for state transition in the template. That resulted in what I think is a lean state transition code. The idea is that the FSM template should be both specialized and wrapped into a usable outer class by an FSM implementer. That wrapper class will be a full specific FSM implementation. The FSM template uses data types and logic defined outside of it, but those states and data should not be visible outside of that final wrapper implementation of an FSM. A few questions remain (I am very green by C++ standards). Here they are: <ol> <li>Is using <code>type_index</code> as a map key in this case an oddity or goes along with <code>type_index</code> design intent? Is it unique enough for this purpose?</li> <li>Is that right that the "magic" of <code>shared_ptr</code> will automatically and properly destroy all data instantiated in the wrapper class?</li> <li>Are there destuction order issue somewhere in this template and implementation?</li> <li>Is there a way to test proper destruction and it's order?</li> <li>Is there a way (or a reasonable need) to test that state transitions actually synchronize in the <code>FSM::operator()</code> method?</li> </ol> Below is the template itself and the main Turnstile class, toughly implementing that from <a href="http://en.wikipedia.org/wiki/Finite-state_machine#Example:_a_turnstile" rel="nofollow">the Wikipedia article</a>. The other six implementation files with specific types and state logic are at <a href="https://github.com/didenko/FSM/tree/c6b80473071cf906bb86dc525ac7d991b9834e01" rel="nofollow">my GitHub FSM repository</a> if needed. The FSM template below takes a vector of logic reacting to messages, with the head of the vector defining the initial state. It wraps each message actor in a state object, attaching state data an plumbing to it. When the FSM template runs a state it can also do sanit checks that the returned "next" state key is valied (future, left out for briefness here). Here is the template: <pre><code>#pragma once #include <memory> #include <string> #include <vector> #include <map> #include <typeindex> #include <mutex> namespace tools { template <typename Message, typename Content> class FSM { public: class React { public: virtual std::type_index operator()( const Message & msg, std::shared_ptr<Content> ) { return std::type_index(typeid(this)); }; }; typedef std::vector<std::shared_ptr<React>> Flux; FSM( Flux & flux, std::shared_ptr<Content> ctnt ) : current( std::type_index( typeid( *( flux.at(0) ) ) ) ) , content( ctnt ) { for ( auto rct: flux ) { states[ std::type_index( typeid( *rct ) ) ] = State( rct, content ); }; }; void operator()( const Message & msg ) { std::lock_guard<std::mutex> lock( fsm_mutex ); current = states.at( current )( msg ); }; private: class State { public: State( std::shared_ptr<React> rct, std::shared_ptr<Content> ctnt ) : content( ctnt ), react( rct ) {}; State() : content( nullptr ), react( nullptr ) {}; std::type_index operator()( const Message & message ) { return (*react)( message, content ); } private: std::shared_ptr<Content> content; std::shared_ptr<React> react; }; std::mutex fsm_mutex; std::shared_ptr<Content> content; std::type_index current; std::map<std::type_index, State> states; }; } </code></pre> The implementation class header: <pre><code>#pragma once #include "TurnstileTypes.h" namespace tools { namespace test { namespace fsm { // Implementation of the Turnstile FSM example from http://en.wikipedia.org/wiki/Finite_state_machine#Example:_a_turnstile // Added RESET event to better test state. class Turnstile { public: Turnstile(void); void operator()( const TurnstileEvent & msg ); unsigned long Pushed(); unsigned long Paid(); std::string Now(); private: TurnstileFSM::Flux flux; std::unique_ptr<TurnstileFSM> fsm; std::shared_ptr<TurnstileData> stats; }; } } } </code></pre> The implementation class body: <pre><code>#include "TurnstileTypes.h" #include "TurnstileLocked.h" #include "TurnstileUnlocked.h" #include "Turnstile.h" namespace tools { namespace test { namespace fsm { Turnstile::Turnstile(void) : stats( std::make_shared<TurnstileData>() ) { flux.push_back( std::make_shared<Locked>() ); flux.push_back( std::make_shared<Unlocked>() ); fsm = std::unique_ptr<TurnstileFSM>( new TurnstileFSM( flux, stats ) ); }; void Turnstile::operator()( const TurnstileEvent & msg ) { (*fsm)( msg ); }; unsigned long Turnstile::Pushed() { return stats->pushes; }; unsigned long Turnstile::Paid() { return stats->coins; }; std::string Turnstile::Now() { return stats->state_name; }; } } } </code></pre> Thank you very much for the answers! [update 131120] It may be helpful to mention, that <code>FSM.h</code> is not meant to be a library with a "public interface". More so it is a boilerplate code to get an FSM author going. The actual user FSM interface is defined by that FSM implementation - in the attached example it is in <code>Turnstile.h</code>. As such, the FSM.h template kept be very short, and intended to be read and understood by an FSM author. I would also expect them (myself for now) to understand the documented pitfalls of the template - like the fact that sending a message to any FSM while it is in a <code>State()()</code>method will dead-lock. Which can be caused by a chain of calls. <a href="https://plus.google.com/+VladDidenko/posts/4Aijg6v1wvg" rel="nofollow">Thanks to Florian Philipp comment on Google+</a> for pointing that out. There is also an intent to have least knowledge in FSM about <code>Message</code> and <code>Content</code> types, so that FSM authors have most flexibility while implementing - that includes getting information out of content by something like accessors. That flexibility comes with responsibility of not changing the content.
Tags
<c++><templates><c++11>
Title
Type_index use, destruction, and synchronization in the state machine implementation
singulars
PostAcceptedAnswerId
1. PO
 singulars
 PostTypePostTypeId
 PTAnswer
PostParentId
1. This table or related slice is empty.
PostTypePostTypeId
1. PTQuestion
UserLastEditorUserId
1. USVlad Didenko
UserOwnerUserId
1. USVlad Didenko
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. PO
 singulars
 PostTypePostTypeId
 PTAnswer
VotesPostIdCreationDate
1. This table or related slice is empty.
CommentsPostId

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.