Re: [Boost-users] Boost.MSM cc1plus.exe:: error: out of memory allocating 65532

Subject: Re: [Boost-users] Boost.MSM cc1plus.exe:: error: out of memory allocating 65532
From: RaRi (degoah_at_[hidden])
Date: 2013-02-28 16:43:23

Hi Christophe!

...yes, you told me that the submachines have no direct access to its parent state machine. Sorry for the confusion...

The reason why we are using a "global" event queue (each submachine has access to it) is because we don't think that it is not a good design to call process_event from within a submachine: doing so, we will lose the advantages of a hierachical statemachine design. Further, how you will stop a submachine in case it calls permantely its process_event method: doing so would cut the possibility to stop the complete statemachine from the outside world!

Our approach is to start an event collector, which is gathering events from different sources and puts it afterwards into the "global" event queue. In the next step an event dispatcher pops the events from our "global" queue of type std::queue <boost::variant <eventtype1, eventtype2, ..., eventtype44>> and forwards it to to the process_event method of the hierarchical Master or Slave state machines, which perform the appropriate transistions and actions. Note: within one state an event can be put to the "global" event queue, but it is in our opinion a bad design to call the process_event method of the current sub machine. We used the book" Practical UML Statecharts in C/C++: Event-Driven Programming for Embedded Systems - Miro Samek" as basis for such kind of design( not calling process_event event from within submachines). 

I would very appreciate your opinion regarding my comment above.

Regarding the " out of memory problem": Today I've splitted my library into two parts: one slave and one master shared library. So the slave state machine does only now 20 events and the master knows 24 events. We have now a better compilation performance, but the memory allocation is still big for master state machine: at the highest almost 900Mb memory is being allocated while the compilation on windows. In comparison to the approach with a slave and master state machine in one shared library we saved almost 400Mb memory allocation while compile time. This all is already compiled without debug information and it is still a massive memory consumption. 

Tomorrow I will have a look if I can reduce the number of events or maybe even the number of submachines...

Question: does the use of guards and actions in a transition table also produce compilation time (template invocations) in boost.msm like with events? Please say no, cause I still have to define actions and some guards into the state machines. If yes, so we have ultimatively to decide if it would be better to switch to another state machine library (state chart, etc.). Actually, I don't want this:)

Br, 

Rafael

"Christophe Henry-3 [via Boost]" <ml-node+s2283326n4643611h29_at_[hidden]> schrieb:

        

> Regarding my boost::variant: It is used to compose 44 different event 
> types. 
> Additionally this event type is passed as template parameter to the 
> stl::queue <> container , which is used as global event queue for all my 
> state machines (submachines). So each state of a submachine can put in a 
> corresponding event to that special/global event queue. Afterwards my 
> "event 
> dispatcher" gets from the global event queue the latest event and forwards 
> it to the process_event method. I use the approach with the global event 
> queue due to the fact, that the submachines in boost.msm are not able to 
> put 
> events into the event queue of the parent state machine (enclosing state 
> machine). (We already talk about this almost two month ago if you 
> remember...). 

Hi, 

wait, I never said anything like "the submachines in boost.msm are not able 
to put events into the event queue of the parent state machine"!!! All I 
said is that they don't know their parents. Actually they can and there are 
2 ways: 
- the UML conform. Use a pseudo exit, this will move the flow of control to 
the parent fsm, in the out transition you can call process_event, which will 
post... in the parent fsm queue. 
- C++ tricks: after creating the parent fsm, which also creates all 
submachines, you can pass to the submachine a pointer to the parent on which 
you can call process_event. You will have to forward-declare the parent fsm, 
but hell, it's still doable. Alternatively, you can use an event and pass 
the pointer in the event, or more cleanly, to avoid cycles, which are a bad 
design, pass instead a boost::function or type_erasure, which calls map to a 
process_event on the parent. 

I don't see a reason for a global queue (global is such a bad word...). 

Cheers, 
Christophe 

_______________________________________________ 
Boost-users mailing list 
[hidden email] 
http://lists.boost.org/mailman/listinfo.cgi/boost-users
                                   
        
        _____________________________________________
        

                

If you reply to this email, your message will be added to the discussion below:

                http://boost.2283326.n4.nabble.com/Boost-MSM-cc1plus-exe-error-out-of-memory-allocating-65532-tp4643468p4643611.html 	

        

                                 To unsubscribe from Boost.MSM cc1plus.exe:: error: out of memory allocating 65532, click here.
                NAML 	

--
View this message in context: http://boost.2283326.n4.nabble.com/Boost-MSM-cc1plus-exe-error-out-of-memory-allocating-65532-tp4643468p4643616.html
Sent from the Boost - Users mailing list archive at Nabble.com.