[msm] orthogonal region and event consume
Hello Christophe, I'm using Boost.MSM version 1.49.0. I bumped on a suspicious behavior. See the attached diagram and code. When Event1 occurs in State1, Action1 is invoked. I think the event isn't consumed correctly. If the transition from State1 to State2 connect State2 directly instead of Entry1, the event seems to be consumed. What do you think? Thanks, Takatoshi
I analyzed this problem deeply. It doesn't relate to orthogonal regions. My understanding is that Boost.Msm requires the same event for transitions that to entry pseudo state and from entry pseudo state. So, in simple_entry.png(attached diagram), the transition from Entry1 requires Event1. But this requirement is sometimes problematic. Because submachines sometimes shouldn't know the outside information such as Event1. So, I chose msm::front::none instead of Event1 (entry_pseudo_event.cpp). msm::front::none event approach has two problems. One is preserving outer event. And then the event is handled similar as the deferred event. The other is there is no way to get the outer event in the submachine. I believe that the former should be fixed. But I found another solution. See the entry_pseudo_event_template.cpp. The event that corresponds to the transition from the entry pseudo state is injected as a template parameter. So, submachine doesn't need to know the Event1. This approach solves the both above problems. Thanks, Takatoshi On Fri, May 25, 2012 at 5:48 PM, Takatoshi Kondo <redboltz@gmail.com> wrote:
Hello Christophe,
I'm using Boost.MSM version 1.49.0. I bumped on a suspicious behavior. See the attached diagram and code. When Event1 occurs in State1, Action1 is invoked.
I think the event isn't consumed correctly.
If the transition from State1 to State2 connect State2 directly instead of Entry1, the event seems to be consumed.
What do you think?
Thanks, Takatoshi
Hello, i just recognized, that std::swap is not overload for boost::shared_ptr, meaning that using swap with std namespace ends up with unexpected results in respect to performance. Is this by intent ? Regards, ILo.
On Saturday, May 26, 2012 04:54 PM, Ingo Loehken wrote:
Hello,
i just recognized, that std::swap is not overload for boost::shared_ptr, meaning that using swap with std namespace ends up with unexpected results in respect to performance.
Is this by intent ?
If you look at the synopsis: http://www.boost.org/doc/libs/1_49_0/libs/smart_ptr/shared_ptr.htm#Synopsis You'll see a member swap and a free function swap in the boost namespace, this free function is intended to be found with ADL. There is a note on that page: "[swap is defined in the same namespace as shared_ptr as this is currently the only legal way to supply a swap function that has a chance to be used by the standard library.]" If you look at the implementation of boost::swap you'll see something like: namespace boost { void swap(T& a, T& b) { using std::swap; swap(a, b); } } Which allows you to swap with ADL or std::swap fallback. I don't think you want to explicitly call ::std::swap from user code. Details: http://www.boost.org/doc/libs/1_49_0/libs/utility/swap.html Ben
Hello, I wrote a patch. If an event that corresponds to the transition from an entry pseudo state is not equal to boost::msm::front::none, then do self->process_event(evt.m_event); Else doesn't do it. This patch brings dependency that from msm::back to msm::front. If it is not suitable, msm::front::none may move to msm/common.hpp. Thanks, Takatoshi On Sat, May 26, 2012 at 3:40 PM, Takatoshi Kondo <redboltz@gmail.com> wrote:
I analyzed this problem deeply. It doesn't relate to orthogonal regions. My understanding is that Boost.Msm requires the same event for transitions that to entry pseudo state and from entry pseudo state. So, in simple_entry.png(attached diagram), the transition from Entry1 requires Event1.
But this requirement is sometimes problematic. Because submachines sometimes shouldn't know the outside information such as Event1. So, I chose msm::front::none instead of Event1 (entry_pseudo_event.cpp).
msm::front::none event approach has two problems. One is preserving outer event. And then the event is handled similar as the deferred event. The other is there is no way to get the outer event in the submachine.
I believe that the former should be fixed. But I found another solution. See the entry_pseudo_event_template.cpp.
The event that corresponds to the transition from the entry pseudo state is injected as a template parameter. So, submachine doesn't need to know the Event1. This approach solves the both above problems.
Thanks, Takatoshi
On Fri, May 25, 2012 at 5:48 PM, Takatoshi Kondo <redboltz@gmail.com> wrote:
Hello Christophe,
I'm using Boost.MSM version 1.49.0. I bumped on a suspicious behavior. See the attached diagram and code. When Event1 occurs in State1, Action1 is invoked.
I think the event isn't consumed correctly.
If the transition from State1 to State2 connect State2 directly instead of Entry1, the event seems to be consumed.
What do you think?
Thanks, Takatoshi
I had gotten an incoming event confused with an outgoing event of entry pseudo state. Please ignore my patch. Regards, Takatoshi On Sat, May 26, 2012 at 11:43 PM, Takatoshi Kondo <redboltz@gmail.com> wrote:
Hello,
I wrote a patch. If an event that corresponds to the transition from an entry pseudo state is not equal to boost::msm::front::none, then do self->process_event(evt.m_event); Else doesn't do it.
This patch brings dependency that from msm::back to msm::front. If it is not suitable, msm::front::none may move to msm/common.hpp.
Thanks, Takatoshi
On Sat, May 26, 2012 at 3:40 PM, Takatoshi Kondo <redboltz@gmail.com> wrote:
I analyzed this problem deeply. It doesn't relate to orthogonal regions. My understanding is that Boost.Msm requires the same event for transitions that to entry pseudo state and from entry pseudo state. So, in simple_entry.png(attached diagram), the transition from Entry1 requires Event1.
But this requirement is sometimes problematic. Because submachines sometimes shouldn't know the outside information such as Event1. So, I chose msm::front::none instead of Event1 (entry_pseudo_event.cpp).
msm::front::none event approach has two problems. One is preserving outer event. And then the event is handled similar as the deferred event. The other is there is no way to get the outer event in the submachine.
I believe that the former should be fixed. But I found another solution. See the entry_pseudo_event_template.cpp.
The event that corresponds to the transition from the entry pseudo state is injected as a template parameter. So, submachine doesn't need to know the Event1. This approach solves the both above problems.
Thanks, Takatoshi
On Fri, May 25, 2012 at 5:48 PM, Takatoshi Kondo <redboltz@gmail.com> wrote:
Hello Christophe,
I'm using Boost.MSM version 1.49.0. I bumped on a suspicious behavior. See the attached diagram and code. When Event1 occurs in State1, Action1 is invoked.
I think the event isn't consumed correctly.
If the transition from State1 to State2 connect State2 directly instead of Entry1, the event seems to be consumed.
What do you think?
Thanks, Takatoshi
Hello, I think that I found the solution. So, I summarize the problem and solution into trac ticket. https://svn.boost.org/trac/boost/ticket/6951 Thanks, Takatoshi On Tue, May 29, 2012 at 1:47 PM, Takatoshi Kondo <redboltz@gmail.com> wrote:
I had gotten an incoming event confused with an outgoing event of entry pseudo state. Please ignore my patch.
Regards, Takatoshi
On Sat, May 26, 2012 at 11:43 PM, Takatoshi Kondo <redboltz@gmail.com> wrote:
Hello,
I wrote a patch. If an event that corresponds to the transition from an entry pseudo state is not equal to boost::msm::front::none, then do self->process_event(evt.m_event); Else doesn't do it.
This patch brings dependency that from msm::back to msm::front. If it is not suitable, msm::front::none may move to msm/common.hpp.
Thanks, Takatoshi
On Sat, May 26, 2012 at 3:40 PM, Takatoshi Kondo <redboltz@gmail.com> wrote:
I analyzed this problem deeply. It doesn't relate to orthogonal regions. My understanding is that Boost.Msm requires the same event for transitions that to entry pseudo state and from entry pseudo state. So, in simple_entry.png(attached diagram), the transition from Entry1 requires Event1.
But this requirement is sometimes problematic. Because submachines sometimes shouldn't know the outside information such as Event1. So, I chose msm::front::none instead of Event1 (entry_pseudo_event.cpp).
msm::front::none event approach has two problems. One is preserving outer event. And then the event is handled similar as the deferred event. The other is there is no way to get the outer event in the submachine.
I believe that the former should be fixed. But I found another solution. See the entry_pseudo_event_template.cpp.
The event that corresponds to the transition from the entry pseudo state is injected as a template parameter. So, submachine doesn't need to know the Event1. This approach solves the both above problems.
Thanks, Takatoshi
On Fri, May 25, 2012 at 5:48 PM, Takatoshi Kondo <redboltz@gmail.com> wrote:
Hello Christophe,
I'm using Boost.MSM version 1.49.0. I bumped on a suspicious behavior. See the attached diagram and code. When Event1 occurs in State1, Action1 is invoked.
I think the event isn't consumed correctly.
If the transition from State1 to State2 connect State2 directly instead of Entry1, the event seems to be consumed.
What do you think?
Thanks, Takatoshi
Hi Takatoshi,
Hello Christophe,
I'm using Boost.MSM version 1.49.0. I bumped on a suspicious behavior. See the attached diagram and code. When Event1 occurs in State1, Action1 is invoked.
I think the event isn't consumed correctly.
This is actually the desired behavior. It is also documented, but it's easy to miss it, the doc is getting quite big. See: http://svn.boost.org/svn/boost/trunk/libs/msm/doc/HTML/ch03s02.html#d0e852 "both transitions must be triggered by the same event".
If the transition from State1 to State2 connect State2 directly instead of Entry1, the event seems to be consumed.
What do you think?
This is coherent with MSM's style. A pseudo entry is defined as a connection between a transition outside the submachine and a transition inside. Logically, to process the inside transition, MSM will need to call process_event(Event1), thus triggering Action1 too. Another behavior would be surprising because it is also mandated that every region gets a chance to process any event processed on a submachine. Forbidding this would be nonstandard, wouldn't it? Another standard-conform solution would be to mandate that, none would be the only acceptable event in the transition outgoing from the pseudo entry and this would be pretty sad because: - it would break a lot of code - Event1's data would be lost I read your ticket. Note that it's not UML-conform to have 2 transitions originating from Entry1 (11-08-06.pdf §15.3.8 page 551). After reading the Standard again twice, I realized that no example provided there displays any event on both transitions, which is really bad if it's what they mean. I need to have a look at other literature. Concretely, what is the problem you're having so I can see what can be done? IIUC yur patch consists of "cheating" with the queue but it has 2 disadvantages: - it costs run-time (ouch!) - I bet there are cases where the queue is not in the state you'd want. I suppose it would be possible to treat none on the outgoing transition with a special behavior but I need to be convinced it's worth the pain and compile-time. What is your use case?
Thanks, Takatoshi
Regards, Christophe
Hi Christophe, Thanks you for your reply. On Wed, May 30, 2012 at 5:17 AM, Christophe Henry <christophe.j.henry@googlemail.com> wrote:
Hi Takatoshi,
Hello Christophe,
I'm using Boost.MSM version 1.49.0. I bumped on a suspicious behavior. See the attached diagram and code. When Event1 occurs in State1, Action1 is invoked.
I think the event isn't consumed correctly.
This is actually the desired behavior. It is also documented, but it's easy to miss it, the doc is getting quite big. See: http://svn.boost.org/svn/boost/trunk/libs/msm/doc/HTML/ch03s02.html#d0e852 "both transitions must be triggered by the same event".
If the transition from State1 to State2 connect State2 directly instead of Entry1, the event seems to be consumed.
What do you think?
This is coherent with MSM's style. A pseudo entry is defined as a connection between a transition outside the submachine and a transition inside. Logically, to process the inside transition, MSM will need to call process_event(Event1), thus triggering Action1 too. Another behavior would be surprising because it is also mandated that every region gets a chance to process any event processed on a submachine. Forbidding this would be nonstandard, wouldn't it?
Another standard-conform solution would be to mandate that, none would be the only acceptable event in the transition outgoing from the pseudo entry and this would be pretty sad because: - it would break a lot of code - Event1's data would be lost
I read your ticket. Note that it's not UML-conform to have 2 transitions originating from Entry1 (11-08-06.pdf §15.3.8 page 551). After reading the Standard again twice, I realized that no example provided there displays any event on both transitions, which is really bad if it's what they mean. I need to have a look at other literature.
I read the section that you mentioned carefully. My interpretation of UML specification is different from yours. It's really difficult to explain my interpretation. So, I draw the diagram. See the attached file. Am I misunderstanding?
Concretely, what is the problem you're having so I can see what can be done? IIUC yur patch consists of "cheating" with the queue but it has 2 disadvantages: - it costs run-time (ouch!) - I bet there are cases where the queue is not in the state you'd want.
Indeed. I agree that the solution that depends on the queue is not good.
I suppose it would be possible to treat none on the outgoing transition with a special behavior but I need to be convinced it's worth the pain and compile-time. What is your use case?
My goal is to improve sub-machines' re-usability. If we want to reuse sub-machines in another state machines, sub-machines shouldn't know the outside information. See my second mail in this thread. My solution using templates (entry_pseudo_event_template.cpp) requires the template parameters same as the number of entry point pseudo states in sub-machine. It's acceptable but if outgoing transition would be able to use none, I would remove the template parameters. In the above case, it is not required to support multiple incoming transitions to one entry pseudo state. Because the instances of sub-machine are different. I don't have any practical use case that requires multiple incoming transitions to one entry pseudo state for now. Thanks, Takatoshi
Thanks, Takatoshi
Regards, Christophe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi Takatoshi,
I read your ticket. Note that it's not UML-conform to have 2 transitions originating from Entry1 (11-08-06.pdf §15.3.8 page 551). After reading the Standard again twice, I realized that no example provided there displays any event on both transitions, which is really bad if it's what they mean. I need to have a look at other literature.
I read the section that you mentioned carefully. My interpretation of UML specification is different from yours. It's really difficult to explain my interpretation. So, I draw the diagram. See the attached file. Am I misunderstanding?
I will not pretend I have the perfect understanding of the Standard. Here's my take. I also saw the sentence on top of your diagram and didn't fully understand it when reading the Standard. There is also the following sentence in the Standard: "An entry pseudostate is used to join an external transition terminating on that entry point to an internal transition emanating from that entry point". Which sounds logical because on your diagram the regions would not be orthogonal. This means you cannot have transitions triggered by different events leading to the entry point, not can you have different transitions leaving it. You will need more entry points. Caution: I am far from being sure I got it right. That's why I precised my definition of it in the doc. The implemented solution has the advantage that you have the normal transition handling, including multiple transitions and guards, events with data, base events, etc. What you don't have is entry in multiple regions, which only the fork currently provides, at the cost of lesser encapsulation. Correct or not, this is the part of the Standard I chose to implement pseudo entries. To be honest, I'm not of fan of pseudo entries. I prefer the vastly superior solution of entering a submachine the "normal" way, then letting a templatized, enable_if'd on_entry of the submachine do something clever with the event at compile-time.
My goal is to improve sub-machines' re-usability. If we want to reuse sub-machines in another state machines, sub-machines shouldn't know the outside information.
I agree but is it the case? I mean, if you send normal events to your submachine through your outer machine, it also needs to know them, right? I understand this as: "hi, I'm a submachine and I provide the following entry points: Entry1 requires Event1, Entry2 requires Event2, etc.". A bit like function parameters.
See my second mail in this thread. My solution using templates (entry_pseudo_event_template.cpp) requires the template parameters same as the number of entry point pseudo states in sub-machine. It's acceptable but if outgoing transition would be able to use none, I would remove the template parameters.
In the above case, it is not required to support multiple incoming transitions to one entry pseudo state. Because the instances of sub-machine are different.
In this case, maybe I could interest you in defining a base event class for Event1 and Event2, then making this base event the event triggering the inside transition. Your first example would be changed this way: struct BaseEvent {}; struct Event1: public BaseEvent {}; ... msmf::Row < Entry1, BaseEvent, State2_2, msmf::none, msmf::none > Regards, Christophe
participants (4)
-
Ben Pope -
Christophe Henry -
Ingo Loehken -
Takatoshi Kondo