[boost] Re: Re: Re: Some questions on the FSM submission

From: Andreas Huber (ah2003_at_[hidden])
Date: 2003-06-07 05:08:31

Scott Woods wrote:
>> this is a product i used a few years ago. its a pretty complete
>> "implementation"
>> of SDL - you draw SDL, push a button and it generates the target
>> system
>> in C (that's what the brochures say ;-). it is very much targeted at
>> large communities of FSMs.
>>
>> the sort of thing that i queried a while ago (and i think related to
>> what chris was
>> asking) was; "where is the [separate] definition of the protocols"?
>> right or wrong
>> i believe that FSMs interact through sending of signals
>> (presentation of events?).
>> this interaction is a protocol and a protocol has its own
>> "existence" - it is not
>> owned by the FSMs. neither UML or SDL highlights this. using SDL i
>> was certainly able to implement protocols but it would have been a
>> royal pain to uplift that "protocol" and reuse it in another project.
>
> Hmmmm. Apologies. Just had a read of some of the UML material and have
> to take this back. My knowledge of UML needs updating. It looks like
> OMG is competing with ITU pretty damn successfully these days.
>
> Putting that fight aside for a moment (UML vs SDL) the separation of
> protocol from FSMs is maybe a concept of interest to you and your
> library. But truly see this as just "future" stuff. Looking forward
> to current functionality.

I don't know what part in the UML specs you're referring to (I don't really
know UML apart from class diagrams and state charts). A quick search did not
reveal much apart from protocol state machines which AFAICT don't have
anything to do with FSM interaction.

SDL defines channels, gates and connections which sort of define a protocol.
To me, these primitives are only necessary to *document* which FSM is
talking to which other FSM. There's little semantics behind them. Maybe I'm
seeing this too easy but I think in C++ all you need for inter-FSM
communication is:

1. Events that can carry parameters
2. A call-back mechanism a la boost::function, so that an FSM that is
answering a request does not have to know who it is answering to.

Let's assume we already have a thread-enabled boost::fsm. We would then have
something like

concurrent_state_machine::queue_event( const intrusive_ptr< const event_base
> & )

Now if FSM A wants to send a request to FSM B and make B send an event back
as soon as the request is processed, we could write something like this

*B.hpp*:

struct Answer : fsm::event< Answer >
{
  /* answer params */
};

struct Request : fsm::event< Request >
{
  /* request parameters */
  boost::function< void ( const intrusive_ptr< const Answer > & ) >
callback;
};

struct B : fsm::concurrent_state_machine< B, /* ... */ >
{
  static B & instance();
};

*B.cpp*:

// X is some state of B
fsm::result X::react( const Request & req )
{
  // ...
  intrusive_ptr< const Answer > pAnswer( new Answer() );
  req.callback( pAnswer );
}

*A.cpp*:

#include "B.hpp"

// somewhere inside A's logic:

boost::intrusive_ptr< Request > pRequest = new Request();
// set params
A & machine = context< A >();
pRequest->callback = boost::bind( &A::queue_event, machine, _1 );

B::instance().queue_event( pRequest );

So, IMO there's no need for boost::fsm to provide communication protocol
primitives, because their functionality is pretty orthogonal to what my
library does. Users would want to use what they're accustomed to. Most would
presumably use boost::function.

Regards,

Andreas