Re: [boost] FSM Review Reminder

From: Rajpal Dangi (rajpal.dangi_at_[hidden])
Date: 2008-08-08 13:52:50

Hi All,
    Is it possible to use FSM in multithreaded application i.e. each
worker thread executing its own statemachine? I would have assumed to
accomplish so but doubt occurred after reading FSM docs 
"Users should consider Boost.FSM if
    * the state machine don't need to be executed in a separate thread"

Is there any problem if each thread has a separate FSM instance and
process events as per its context?

Thanks,

Raj

 

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Martin Vuille
Sent: Friday, August 08, 2008 4:36 AM
To: boost-announce_at_[hidden]; boost_at_[hidden]
Subject: [boost] FSM Review Reminder

The formal review for Andrey Semashev's Finite State Machines (FSM)
library is scheduled for August 11th to 20th.

The documentation (overview and reference) is available online:
http://boost-extension.redshoelace.com/docs/boost/fsm/doc/state_machine.
html
http://boost-extension.redshoelace.com/docs/boost/fsm/doc/reference.html

Quoting from the documentation:

"The main goals of the library are:

* Simplicity. It should be very simple to create state machine
  using this library. 
* Performance. The state machine infrastructure should not be very
  time and memory-consuming in order to be applicable in more use
  cases. 
* Extensibility. A developer may want to add more states to the
  existing state machine, and this addition should be relatively
  safe since it shouldn't interfere with the existing states. The
  developer should also be able to specify additional transitions
  and events for the machine with minimum modifications to the
  existing code."

"Boost.FSM vs. Boost.Statechart

There is another library in Boost that provides similar functionality:
Boost.Statechart. Although it currently covers almost all major
Boost.FSM features and provides ones that are not supported in this
library, Boost.Statechart is more targeted to creation of big and
complex state machines with possibility of distributed development. But
this does not come at no price and Statechart has little tools for
compile-time programming and does not provide as much run-time
performance as Boost.FSM does. So there are main guidelines for users to
make a decision between Boost.FSM and Boost.Statechart: [...]"

"The following compilers are known to have problems or most likely will
have ones:

* Microsoft Visual C++ 6.0 and 7.0. Most probably will fail to
  compile due to lack of partial template specialization support.
* Borland C++ Builder 5.5.1 (free version). Fails to compile due
  to lack of partial template specialization and in-class using
  declarations support. Some other minor problems also have been
  noticed. Newer versions of the compiler have not been tested.
* OpenWatcom 1.5. Fails to compile due to problems with Boost.MPL
  code. Newer versions of the compiler have not been tested.
* SunPro C++ Compiler 5.5 for Solaris (SPARC). Most likely will
  show problems with function overload resolution. Newer versions
  of the compiler have not been tested."

The current submission is available from the sandbox vault at
http://tinyurl.com/yjozfn (or
http://www.boostpro.com/vault/index.php?action=downloadfile&filename=FSM
.zip
&directory=&PHPSESSID=48493076c1ea60ae316f7b60f15b9ed1,
if you prefer.)

MV

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost