Hi Jody, Thanks for your review! Jody Hagins wrote:
I think the documentation is relatively complete. However, I am not exactly thrilled by the requirement on the reader to understand UML diagrams. On the other hand, this library is intended to represent UML in C++ (at least to my understanding), so I'm not sure what else can be done. A link to a basic tutorial on UML state machine diagrams would be appropriate in the "UML to boost::fsm Mapping Summary." I know you link to the 730 page OMG document on UML, but I'd also like to see something that describes the basic UML for state charts.
http://www.objectmentor.com/resources/articles/umlfsm.pdf doesn't do the trick (linked from the tutorial under Audience)?
* The library documentation contains few not yet solved issues (name, separating the library into two parts, exception handling). What is you opinion here?
I think it is obvious that the library should be separated, though I do not think this issue itself should be a stumbling block for acceptance. Exception handling is very important, and I do not buy the rationale that allowing destructors to throw is not a problem in practice.
I'm basically saying that you *usually* don't need to propagate exceptions out of exit actions. But sometimes you still need to do it and then you can use two stage exit.
I also do not think I really understand "two stage exit."
Two stage exit means that you now have two functions that are called whenever a state is exited. If present, exit() is called first and the states' destructor is called second. If you need to signal an exit action failure, you can do so by propagating an exception out of exit().
* Are there performance bottlenecks? Does the library design fit requirements of real-time systems? How is it useable for embedded systems? Is the documentation clear on performance tradeoffs?
I think we have to define real-time. Traditionally, real-time systems have hard completion time requirements (e.g., the XYZ event must be processed in under 50ms). Even though I have performance issues with this library, I think it can still be utilized in many real-time situations. Andreas has stated several times that the dispatch time will be small compared to the handling time.
What I meant was that if you have a typical hierarchical FSM with *empty* actions, then the time used to find the transition triggered by the current event (dispatch time) is typically small compared to what it takes to execute that transition (exit the original state configuration and enter the target state configuration). Even more so if you add non-trivial actions.
However, I find this argument a bit lacking, especially for hard real-time requirements, where each cycle taken for dispatch is stolen from the reaction handler.
I hope the argument makes more sense with the explanation above.
My current application requirements do not fit the traditional definition of real-time. However, my SMs need to be as fast as possible, because in a real sense, my code is competing with other code. Without going into too much detail, when an "opportunity" is available, it is only available to the first one to see it, respond, and take that opportunity. Thus, my real-time requirement is that I have to be faster than anyone else playing my game. I think using this library would put me at a disadvantage in that particular space.
Agreed, given that there are no other bottlenecks (network latency, etc.).
However, I do have some applications in which this library could be used successfully (if I were inclined to learn enough UML to make sense of all the details).
The documentation is clear enough about the performance issues. In fact, it may be too clear, as some people seem to see problems that may not exist in most applications.
I'm having exactly this gut-feeling ever since the performance discussion started and I'm really relieved that at least someone else thinks this way :-).
One last thing on performance, since it has been a hot topic in relation to this library. I do not think it has sufficient performance to warrant use in all my applications, and I assume the same for many others. However, it does have sufficient performance to be used in a large number of applications. If the docuemntation is clear (which it is), then users can decide when/how it can be used. I could make similar performance claims agains almost every boost library (and I have made them on this list about shared_ptr and signals). However, that does not mean we should eliminate those libraries from boost, nor does it mean that they should never have been accepted (but I would like to see a larger commitment to address performance issues in all currently accepted libraries). I would, however, like to see a separate submission which has a focus on performance,
I'd like to see that too.
and I would really like to see the performance issue of this library revisited, especially with input from some of the folks here who claim expertise in that area.
I'm willing to do that, see below.
* Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion.
Yes, with two conditions.
1. The name should definitely be changed.
Agreed.
I am not sure, however, what a new name should be. I tend to favor one of Andreas' alternatives: umlfsm.
Ugh, I'm not so fond of that name. I'd prefer Alexander's "Boost.Statechart".
2. I also think there should be some commitment to revisit the performance issues. I am not sure how this works, but I'd be satisfied with a commitment from Andreas, possibly accompanied by a request to the Boost community for assitance. I am not certain that an acceptable solution can be found, but I think the issue at least needs to be addressed again, specifically with input from the Boost community.
That's fine with me. I think it would be easiest if interested people contact me directly, so that we can look at ways to improve the performance. If we find ways to improve it *considerably* that require only small or no interface changes (and all the requirements are still satisfied), I will implement them (and I'm happy not to add the library until they are implemented). I'll leave it up to the interested people to define the acceptance process in case no ways to improve the performance are found within a certain time frame. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.