|
Boost : |
From: Peters, Richard (richard.peters_at_[hidden])
Date: 2008-03-18 08:51:15
Hello,
While using the Boost.StateChart library, I noticed strange behaviour
when orthogonal states are used. Supposed I have a state machine with
state A, which contains a state B, and state B has two orthogonal states
C and D. Suppose A handles some event E, and D is able to handle the
same event E.
Now if the statemachine is in state C and D and I send event E, this can
happen: E is sent to C, which is unable to handle E. E gets forwarded to
B, and then to A. There, it is handled by A.
I would expect this behaviour: E is sent to C, it is unable to handle
it, and then the event E is forwarded to the next orthogonal state in B,
which is D. Then, D is able to handle it. This way, event E ends up
handled by D instead of by A.
The statechart reference states the current behaviour as the correct
behaviour: Class template state_machine, void process_event specifies in
point 3: "Select an arbitrary but in this reaction search not yet
visited state from all the currently active innermost states." and in
4a: "Searches a reaction suitable for currentEvent, starting with the
current innermost state and moving outward until a state defining a
reaction for the event is found."
So, the implementation matches the specification. But what is the reason
that it is not specified that first all orthogonal states are tried
before moving outward in search for a reaction? Is this the way the UML
standard specifies it? I tried to read the UML standard, but I can't
find something relevant for propagating events.
best regards,
Richard Peters
This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law.
If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited.
If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message.
Thank you for your co-operation.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk