Boost logo

Boost :

Subject: Re: [boost] Boost MSM parallel behavior with delayed self-transitions?
From: degski (degski_at_[hidden])
Date: 2017-03-21 14:05:24


On 21 March 2017 at 01:37, Danylo Malyuta via Boost <boost_at_[hidden]>
wrote:

> 1. Enter state State1
> 2. Enter state A and execute action_A. After 2 seconds, print "Trying
> again..." and re-execute state A (i.e. call its entry action). This loops
> forever...
> 3. At the same time as 2 (i.e. "in parallel"), enter state B and execute
> action_B. After 5 seconds, print "Trying again..." and re-execute state B
> (i.e. call its entry action). This loops forever...

I'm not an expert on SM's, but 1 state machine with two active states seems
to be contary tot the basic idea of a SM. Hierarchical state machines could
work, or instead, you could just implement a (one) loop (the AB-state) that
uses one clock and 2 times: a_triggered and b_triggered.

Work with one second intervals, put thread to sleep for one second (you
don't want to spin on this, 1 second is an eternity in CPU terms). After
one second thread will wake up and check whether A and/or B should
trigger. If yes, execute action A and/or B and update the relevant
a_triggered and/or b_triggered time respectively (set to current time), or,
if neither triggers, do nothing and put thread to sleep again (for 1
second), and so on and so on.

I realize this does not answer the question: "How to do this with
Boost.MSM". The above, on the oher hand, is simple to implement, while
Boost.MSM seems overkill to me (if your description of the problem is
comprehensive, that is).

degski


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk