https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=703
Summary: TimerComponent commands do not work as are running in
a non-periodic activity
Product: OCL
Version: trunk
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P3
Component: Timer
AssignedTo: orocos-dev [..] ...
ReportedBy: kiwi [dot] net [..] ...
CC: orocos-dev [..] ...
Estimated Hours: 0.0
The TimerComponent has "wait" and "waitFor" commands. These don't work in the
`tests/timer` program. I think this is because the TimerComponent uses a
non-periodic activity to drive the timer, which does not yield to the command
processor anywhere. Hence, methods such as "arm" work, however, commands like
"wait" do not (the taskbrowser simply responds "queued" and the actual command
does not get called).
Has this ever worked, or am I missing something?
If the above conjecture is correct, how could you use "wait" commands in a
program script?
Stephen
[Bug 703] TimerComponent commands do not work as are running in
https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=703
--- Comment #11 from Peter Soetens <peter [..] ...> 2009-09-14 14:21:48 ---
I've traced the bug into the C++ statemachine class for scripting that is
reacting to old events. There is a short-circuit in the code that enables
reactions to all event transitions of your whole script. For example, in your
script, we will get three times informed that timeout happened: for each
transition Timer.timeout() statement once, and also for each 'else' branch of
such a statement. Once we make a transition from 3 to 4, there are still 2 out
of 3 events in the queue. The queue is not cleared (we can't do that because
any number of events may be in the event processor) and state 4 sees the two
remaining events. The 'filter' algorithm should detect that these two were
left-overs from state 3, but they slip through, because state 4 reacts to the
same event as three (only the payload differs, but that is interpreted by your
application logic, not by the state machine implementation)
I'm not expecting anyone to understand this :-)
I'm still assessing which is the fasted path to solution.
Peter
[Bug 703] TimerComponent commands do not work as are running in
On Sep 14, 2009, at 08:21 , Peter Soetens wrote:
> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=703
>
>
>
>
>
> --- Comment #11 from Peter Soetens <peter [..] ...>
> 2009-09-14 14:21:48 ---
> I've traced the bug into the C++ statemachine class for scripting
> that is
> reacting to old events. There is a short-circuit in the code that
> enables
> reactions to all event transitions of your whole script. For
> example, in your
> script, we will get three times informed that timeout happened: for
> each
> transition Timer.timeout() statement once, and also for each 'else'
> branch of
> such a statement. Once we make a transition from 3 to 4, there are
> still 2 out
> of 3 events in the queue. The queue is not cleared (we can't do that
> because
> any number of events may be in the event processor) and state 4 sees
> the two
> remaining events. The 'filter' algorithm should detect that these
> two were
> left-overs from state 3, but they slip through, because state 4
> reacts to the
> same event as three (only the payload differs, but that is
> interpreted by your
> application logic, not by the state machine implementation)
>
> I'm not expecting anyone to understand this :-)
I _think_ I actually understand that ...! :-)
> I'm still assessing which is the fasted path to solution.
I leave it in your capable hands ...
S
[Bug 703] TimerComponent commands do not work as are running in
(bugzilla is a bit down for the moment)
This patch fixes the 'bug' in StateMachine.cpp. All event handlers
were enabled, as such states could react to events that happened in
previous states (ie before the state was entered).
I'm not sure if there is any standard that says that you can't react
to 'old' events or at which point in time you are allowed to catch an
event. The implementation assumed that a state could react to events
of any age... (but also that the age of an event was pretty arbitrary)
This patch might actually break code that somehow relied on reacting
to events that happened when the SM was still in a previous state. For
example:
In state 1:
event(a).raised
event(b).raised
event(c).raised
==> process event(a) and make transition to state 2
In state 2:
==> process event(b) and make transition to state 3
In state 3:
==> process event(c) and make transition to state 4
etc...
This patch will drop (b) and (c). I'm not sure we want that... State
machine purists ?
Peter
On Mon, Sep 14, 2009 at 14:25, S Roderick <kiwi [dot] net [..] ...> wrote:
> On Sep 14, 2009, at 08:21 , Peter Soetens wrote:
>
>> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=703
>>
>>
>>
>>
>>
>> --- Comment #11 from Peter Soetens <peter [..] ...> 2009-09-14
>> 14:21:48 ---
>> I've traced the bug into the C++ statemachine class for scripting that is
>> reacting to old events. There is a short-circuit in the code that enables
>> reactions to all event transitions of your whole script. For example, in
>> your
>> script, we will get three times informed that timeout happened: for each
>> transition Timer.timeout() statement once, and also for each 'else' branch
>> of
>> such a statement. Once we make a transition from 3 to 4, there are still 2
>> out
>> of 3 events in the queue. The queue is not cleared (we can't do that
>> because
>> any number of events may be in the event processor) and state 4 sees the
>> two
>> remaining events. The 'filter' algorithm should detect that these two were
>> left-overs from state 3, but they slip through, because state 4 reacts to
>> the
>> same event as three (only the payload differs, but that is interpreted by
>> your
>> application logic, not by the state machine implementation)
>>
>> I'm not expecting anyone to understand this :-)
>
> I _think_ I actually understand that ...! :-)
>
>> I'm still assessing which is the fasted path to solution.
>
> I leave it in your capable hands ...
> S
>
>
[Bug 703] TimerComponent commands do not work as are running in
On Mon, Sep 14, 2009 at 15:24, Peter Soetens <peter [..] ...> wrote:
> (bugzilla is a bit down for the moment)
>
> This patch fixes the 'bug' in StateMachine.cpp. All event handlers
> were enabled, as such states could react to events that happened in
> previous states (ie before the state was entered).
>
> I'm not sure if there is any standard that says that you can't react
> to 'old' events or at which point in time you are allowed to catch an
> event. The implementation assumed that a state could react to events
> of any age... (but also that the age of an event was pretty arbitrary)
>
> This patch might actually break code that somehow relied on reacting
> to events that happened when the SM was still in a previous state. For
> example:
>
> In state 1:
> event(a).raised
> event(b).raised
> event(c).raised
> ==> process event(a) and make transition to state 2
> In state 2:
> ==> process event(b) and make transition to state 3
> In state 3:
> ==> process event(c) and make transition to state 4
> etc...
>
> This patch will drop (b) and (c). I'm not sure we want that...
I'm not entirely correct here. The situation that the test exposes is:
In state 1:
event(a).raised
==> process event(a) and make transition to state 2
In state 2:
==> process event(a) and make transition to state 3 (maybe)
In state 3:
==> process event(a) and make transition to state 4 (maybe)
Logically, we think that once (a) has been consumed in state 1, the
other states can no longer react to it. In the RTT, each state
receives the event, and they all get a chance to react to it (for an
arbitrary amount of time). The arbitrarity in RTT is mainly determined
by the fact that 3 has a bigger chance reacting to it than 4, because
there was a transition from a previous state very close to the
reception of the event, and the event handler lived long enough in the
queue to be alive in state 3.
Com'on Markus, show some UML ball-rolling...and tell us low-level C++
programmers what is The Right Thing To Do.
Peter
>
> Peter
>
> On Mon, Sep 14, 2009 at 14:25, S Roderick <kiwi [dot] net [..] ...> wrote:
>> On Sep 14, 2009, at 08:21 , Peter Soetens wrote:
>>
>>> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=703
>>>
>>>
>>>
>>>
>>>
>>> --- Comment #11 from Peter Soetens <peter [..] ...> 2009-09-14
>>> 14:21:48 ---
>>> I've traced the bug into the C++ statemachine class for scripting that is
>>> reacting to old events. There is a short-circuit in the code that enables
>>> reactions to all event transitions of your whole script. For example, in
>>> your
>>> script, we will get three times informed that timeout happened: for each
>>> transition Timer.timeout() statement once, and also for each 'else' branch
>>> of
>>> such a statement. Once we make a transition from 3 to 4, there are still 2
>>> out
>>> of 3 events in the queue. The queue is not cleared (we can't do that
>>> because
>>> any number of events may be in the event processor) and state 4 sees the
>>> two
>>> remaining events. The 'filter' algorithm should detect that these two were
>>> left-overs from state 3, but they slip through, because state 4 reacts to
>>> the
>>> same event as three (only the payload differs, but that is interpreted by
>>> your
>>> application logic, not by the state machine implementation)
>>>
>>> I'm not expecting anyone to understand this :-)
>>
>> I _think_ I actually understand that ...! :-)
>>
>>> I'm still assessing which is the fasted path to solution.
>>
>> I leave it in your capable hands ...
>> S
>>
>>
>
[Bug 703] TimerComponent commands do not work as are running in
On Mon, Sep 14, 2009 at 03:37:37PM +0200, Peter Soetens wrote:
> On Mon, Sep 14, 2009 at 15:24, Peter Soetens <peter [..] ...> wrote:
> > (bugzilla is a bit down for the moment)
> >
> > This patch fixes the 'bug' in StateMachine.cpp. All event handlers
> > were enabled, as such states could react to events that happened in
> > previous states (ie before the state was entered).
> >
> > I'm not sure if there is any standard that says that you can't react
> > to 'old' events or at which point in time you are allowed to catch an
> > event. The implementation assumed that a state could react to events
> > of any age... (but also that the age of an event was pretty arbitrary)
> >
> > This patch might actually break code that somehow relied on reacting
> > to events that happened when the SM was still in a previous state. For
> > example:
> >
> > In state 1:
> > event(a).raised
> > event(b).raised
> > event(c).raised
> > ==> process event(a) and make transition to state 2
> > In state 2:
> > ==> process event(b) and make transition to state 3
> > In state 3:
> > ==> process event(c) and make transition to state 4
> > etc...
> >
> > This patch will drop (b) and (c). I'm not sure we want that...
>
> I'm not entirely correct here. The situation that the test exposes is:
>
> In state 1:
> event(a).raised
> ==> process event(a) and make transition to state 2
> In state 2:
> ==> process event(a) and make transition to state 3 (maybe)
> In state 3:
> ==> process event(a) and make transition to state 4 (maybe)
>
>
> Logically, we think that once (a) has been consumed in state 1, the
> other states can no longer react to it. In the RTT, each state
> receives the event, and they all get a chance to react to it (for an
Err, but only one state is active at a time and therefore only
transitions emanating from that state can be triggered by an event. I
don't get it?!
> arbitrary amount of time). The arbitrarity in RTT is mainly determined
> by the fact that 3 has a bigger chance reacting to it than 4, because
> there was a transition from a previous state very close to the
> reception of the event, and the event handler lived long enough in the
> queue to be alive in state 3.
What determines the lifetime of the event handler?
> Com'on Markus, show some UML ball-rolling...and tell us low-level C++
> programmers what is The Right Thing To Do.
Well, UML uses an event queue in which events are stored and processed
one by one, which is reacting to old events (I don't agree however
that this is a Good Thing).
Markus
[Bug 703] TimerComponent commands do not work as are running in
On Mon, Sep 14, 2009 at 4:09 PM, Markus Klotzbuecher
<markus [dot] klotzbuecher [..] ...> wrote:
> On Mon, Sep 14, 2009 at 03:37:37PM +0200, Peter Soetens wrote:
>> On Mon, Sep 14, 2009 at 15:24, Peter Soetens <peter [..] ...> wrote:
>> > (bugzilla is a bit down for the moment)
>> >
>> > This patch fixes the 'bug' in StateMachine.cpp. All event handlers
>> > were enabled, as such states could react to events that happened in
>> > previous states (ie before the state was entered).
>> >
>> > I'm not sure if there is any standard that says that you can't react
>> > to 'old' events or at which point in time you are allowed to catch an
>> > event. The implementation assumed that a state could react to events
>> > of any age... (but also that the age of an event was pretty arbitrary)
>> >
>> > This patch might actually break code that somehow relied on reacting
>> > to events that happened when the SM was still in a previous state. For
>> > example:
>> >
>> > In state 1:
>> > event(a).raised
>> > event(b).raised
>> > event(c).raised
>> > ==> process event(a) and make transition to state 2
>> > In state 2:
>> > ==> process event(b) and make transition to state 3
>> > In state 3:
>> > ==> process event(c) and make transition to state 4
>> > etc...
>> >
>> > This patch will drop (b) and (c). I'm not sure we want that...
FWIW, if you would drop these, I think RTT FSMs would be non-UML conformant.
>> I'm not entirely correct here. The situation that the test exposes is:
>>
>> In state 1:
>> event(a).raised
>> ==> process event(a) and make transition to state 2
>> In state 2:
>> ==> process event(a) and make transition to state 3 (maybe)
>> In state 3:
>> ==> process event(a) and make transition to state 4 (maybe)
>>
>>
>> Logically, we think that once (a) has been consumed in state 1, the
>> other states can no longer react to it. In the RTT, each state
>> receives the event, and they all get a chance to react to it (for an
>
> Err, but only one state is active at a time and therefore only
> transitions emanating from that state can be triggered by an event. I
> don't get it?!
Me neither :-(
AFAIR, UML has the notion of deferred events (and each _state_ can
decide which events are deferred). The semantics of this
construction are that, when you are in state A, and event EA happens,
and this doesn't trigger a transition from state A, event EA will
remain in the "queue" and passed to the next state once event EB
occurs which _does_ trigger a transition to the next state.
However, EA is "consumed" in this case and should not trigger any
further transitions anymore (I think).
>> arbitrary amount of time). The arbitrarity in RTT is mainly determined
>> by the fact that 3 has a bigger chance reacting to it than 4, because
>> there was a transition from a previous state very close to the
>> reception of the event, and the event handler lived long enough in the
>> queue to be alive in state 3.
>
> What determines the lifetime of the event handler?
>
>> Com'on Markus, show some UML ball-rolling...and tell us low-level C++
>> programmers what is The Right Thing To Do.
>
> Well, UML uses an event queue in which events are stored and processed
> one by one, which is reacting to old events (I don't agree however
> that this is a Good Thing).
What do you mean with "old" events above Markus?
Klaas
[Bug 703] TimerComponent commands do not work as are running in
On Tue, Sep 22, 2009 at 03:35:29PM +0200, Klaas Gadeyne wrote:
> On Mon, Sep 14, 2009 at 4:09 PM, Markus Klotzbuecher
> <markus [dot] klotzbuecher [..] ...> wrote:
> > On Mon, Sep 14, 2009 at 03:37:37PM +0200, Peter Soetens wrote:
> >> On Mon, Sep 14, 2009 at 15:24, Peter Soetens <peter [..] ...> wrote:
> >> > (bugzilla is a bit down for the moment)
> >> >
> >> > This patch fixes the 'bug' in StateMachine.cpp. All event handlers
> >> > were enabled, as such states could react to events that happened in
> >> > previous states (ie before the state was entered).
> >> >
> >> > I'm not sure if there is any standard that says that you can't react
> >> > to 'old' events or at which point in time you are allowed to catch an
> >> > event. The implementation assumed that a state could react to events
> >> > of any age... (but also that the age of an event was pretty arbitrary)
> >> >
> >> > This patch might actually break code that somehow relied on reacting
> >> > to events that happened when the SM was still in a previous state. For
> >> > example:
> >> >
> >> > In state 1:
> >> > event(a).raised
> >> > event(b).raised
> >> > event(c).raised
> >> > ==> process event(a) and make transition to state 2
> >> > In state 2:
> >> > ==> process event(b) and make transition to state 3
> >> > In state 3:
> >> > ==> process event(c) and make transition to state 4
> >> > etc...
> >> >
> >> > This patch will drop (b) and (c). I'm not sure we want that...
>
> FWIW, if you would drop these, I think RTT FSMs would be non-UML conformant.
Yes (which is not really an issue, as the current FSM is not UML
conformant anyway: e.g. the order of execution of transition programs
differs).
> >> I'm not entirely correct here. The situation that the test exposes is:
> >>
> >> In state 1:
> >> event(a).raised
> >> ==> process event(a) and make transition to state 2
> >> In state 2:
> >> ==> process event(a) and make transition to state 3 (maybe)
> >> In state 3:
> >> ==> process event(a) and make transition to state 4 (maybe)
> >>
> >>
> >> Logically, we think that once (a) has been consumed in state 1, the
> >> other states can no longer react to it. In the RTT, each state
> >> receives the event, and they all get a chance to react to it (for an
> >
> > Err, but only one state is active at a time and therefore only
> > transitions emanating from that state can be triggered by an event. I
> > don't get it?!
>
> Me neither :-(
> AFAIR, UML has the notion of deferred events (and each _state_ can
> decide which events are deferred). The semantics of this
> construction are that, when you are in state A, and event EA happens,
> and this doesn't trigger a transition from state A, event EA will
> remain in the "queue" and passed to the next state once event EB
> occurs which _does_ trigger a transition to the next state.
> However, EA is "consumed" in this case and should not trigger any
> further transitions anymore (I think).
Exactly, that's what UML does.
> >> arbitrary amount of time). The arbitrarity in RTT is mainly determined
> >> by the fact that 3 has a bigger chance reacting to it than 4, because
> >> there was a transition from a previous state very close to the
> >> reception of the event, and the event handler lived long enough in the
> >> queue to be alive in state 3.
> >
> > What determines the lifetime of the event handler?
> >
> >> Com'on Markus, show some UML ball-rolling...and tell us low-level C++
> >> programmers what is The Right Thing To Do.
> >
> > Well, UML uses an event queue in which events are stored and processed
> > one by one, which is reacting to old events (I don't agree however
> > that this is a Good Thing).
>
> What do you mean with "old" events above Markus?
Events which linger about in the event queue because the event
selection function (variation point!) select other events first.
Markus
[Bug 703] TimerComponent commands do not work as are running in
On Tue, Sep 22, 2009 at 4:53 PM, Markus Klotzbuecher
<markus [dot] klotzbuecher [..] ...> wrote:
> On Tue, Sep 22, 2009 at 03:35:29PM +0200, Klaas Gadeyne wrote:
>> On Mon, Sep 14, 2009 at 4:09 PM, Markus Klotzbuecher
>> <markus [dot] klotzbuecher [..] ...> wrote:
>> > On Mon, Sep 14, 2009 at 03:37:37PM +0200, Peter Soetens wrote:
>> >> On Mon, Sep 14, 2009 at 15:24, Peter Soetens <peter [..] ...> wrote:
>> >> > (bugzilla is a bit down for the moment)
>> >> >
>> >> > This patch fixes the 'bug' in StateMachine.cpp. All event handlers
>> >> > were enabled, as such states could react to events that happened in
>> >> > previous states (ie before the state was entered).
>> >> >
>> >> > I'm not sure if there is any standard that says that you can't react
>> >> > to 'old' events or at which point in time you are allowed to catch an
>> >> > event. The implementation assumed that a state could react to events
>> >> > of any age... (but also that the age of an event was pretty arbitrary)
>> >> >
>> >> > This patch might actually break code that somehow relied on reacting
>> >> > to events that happened when the SM was still in a previous state. For
>> >> > example:
>> >> >
>> >> > In state 1:
>> >> > event(a).raised
>> >> > event(b).raised
>> >> > event(c).raised
>> >> > ==> process event(a) and make transition to state 2
>> >> > In state 2:
>> >> > ==> process event(b) and make transition to state 3
>> >> > In state 3:
>> >> > ==> process event(c) and make transition to state 4
>> >> > etc...
>> >> >
>> >> > This patch will drop (b) and (c). I'm not sure we want that...
>>
>> FWIW, if you would drop these, I think RTT FSMs would be non-UML conformant.
>
> Yes (which is not really an issue, as the current FSM is not UML
> conformant anyway: e.g. the order of execution of transition programs
> differs).
>
>> >> I'm not entirely correct here. The situation that the test exposes is:
>> >>
>> >> In state 1:
>> >> event(a).raised
>> >> ==> process event(a) and make transition to state 2
>> >> In state 2:
>> >> ==> process event(a) and make transition to state 3 (maybe)
>> >> In state 3:
>> >> ==> process event(a) and make transition to state 4 (maybe)
>> >>
>> >>
>> >> Logically, we think that once (a) has been consumed in state 1, the
>> >> other states can no longer react to it. In the RTT, each state
>> >> receives the event, and they all get a chance to react to it (for an
>> >
>> > Err, but only one state is active at a time and therefore only
>> > transitions emanating from that state can be triggered by an event. I
>> > don't get it?!
>>
>> Me neither :-(
>> AFAIR, UML has the notion of deferred events (and each _state_ can
>> decide which events are deferred). The semantics of this
>> construction are that, when you are in state A, and event EA happens,
>> and this doesn't trigger a transition from state A, event EA will
>> remain in the "queue" and passed to the next state once event EB
>> occurs which _does_ trigger a transition to the next state.
>> However, EA is "consumed" in this case and should not trigger any
>> further transitions anymore (I think).
>
> Exactly, that's what UML does.
>
>> >> arbitrary amount of time). The arbitrarity in RTT is mainly determined
>> >> by the fact that 3 has a bigger chance reacting to it than 4, because
>> >> there was a transition from a previous state very close to the
>> >> reception of the event, and the event handler lived long enough in the
>> >> queue to be alive in state 3.
>> >
>> > What determines the lifetime of the event handler?
>> >
>> >> Com'on Markus, show some UML ball-rolling...and tell us low-level C++
>> >> programmers what is The Right Thing To Do.
>> >
>> > Well, UML uses an event queue in which events are stored and processed
>> > one by one, which is reacting to old events (I don't agree however
>> > that this is a Good Thing).
>>
>> What do you mean with "old" events above Markus?
>
> Events which linger about in the event queue because the event
> selection function (variation point!) select other events first.
As I am a slow understander: Can you illustrate the behavior with an example?
TIA
Klaas
[Bug 703] TimerComponent commands do not work as are running in
On Tue, Sep 22, 2009 at 07:52:33PM +0200, Klaas Gadeyne wrote:
> On Tue, Sep 22, 2009 at 4:53 PM, Markus Klotzbuecher
> <markus [dot] klotzbuecher [..] ...> wrote:
> > On Tue, Sep 22, 2009 at 03:35:29PM +0200, Klaas Gadeyne wrote:
> >> On Mon, Sep 14, 2009 at 4:09 PM, Markus Klotzbuecher
> >> <markus [dot] klotzbuecher [..] ...> wrote:
> >> > On Mon, Sep 14, 2009 at 03:37:37PM +0200, Peter Soetens wrote:
> >> >> On Mon, Sep 14, 2009 at 15:24, Peter Soetens <peter [..] ...> wrote:
> >> >> > (bugzilla is a bit down for the moment)
...
> >> >> arbitrary amount of time). The arbitrarity in RTT is mainly determined
> >> >> by the fact that 3 has a bigger chance reacting to it than 4, because
> >> >> there was a transition from a previous state very close to the
> >> >> reception of the event, and the event handler lived long enough in the
> >> >> queue to be alive in state 3.
> >> >
> >> > What determines the lifetime of the event handler?
> >> >
> >> >> Com'on Markus, show some UML ball-rolling...and tell us low-level C++
> >> >> programmers what is The Right Thing To Do.
> >> >
> >> > Well, UML uses an event queue in which events are stored and processed
> >> > one by one, which is reacting to old events (I don't agree however
> >> > that this is a Good Thing).
> >>
> >> What do you mean with "old" events above Markus?
> >
> > Events which linger about in the event queue because the event
> > selection function (variation point!) select other events first.
>
> As I am a slow understander: Can you illustrate the behavior with an example?
Yes. Consider error handling. You have the following events in your
queue:
1. a user request to do something
2. a fatal error signalled by a high level coordinator requiring an emergency stop
Which one should be handled? Of course the emergency stop. But this is
hard to express in pure UML, due to the "one event at a time"
variation point and the unspecified dequeuing mechanism. Especially if
the queue suddenly gets flooded by events (and I think this is likely
in a robotic system) many unimportant events could be processed before
the important one.
There's actually a bit more to it, but I'm still in the process of
thinking it out.
Markus
[Bug 703] TimerComponent commands do not work as are running in
On Wed, Sep 23, 2009 at 10:08 AM, Markus Klotzbuecher
<markus [dot] klotzbuecher [..] ...> wrote:
> On Tue, Sep 22, 2009 at 07:52:33PM +0200, Klaas Gadeyne wrote:
>> On Tue, Sep 22, 2009 at 4:53 PM, Markus Klotzbuecher
>> <markus [dot] klotzbuecher [..] ...> wrote:
>> > On Tue, Sep 22, 2009 at 03:35:29PM +0200, Klaas Gadeyne wrote:
>> >> On Mon, Sep 14, 2009 at 4:09 PM, Markus Klotzbuecher
>> >> <markus [dot] klotzbuecher [..] ...> wrote:
>> >> > On Mon, Sep 14, 2009 at 03:37:37PM +0200, Peter Soetens wrote:
>> >> >> On Mon, Sep 14, 2009 at 15:24, Peter Soetens <peter [..] ...> wrote:
>> >> >> > (bugzilla is a bit down for the moment)
> ...
>
>> >> >> arbitrary amount of time). The arbitrarity in RTT is mainly determined
>> >> >> by the fact that 3 has a bigger chance reacting to it than 4, because
>> >> >> there was a transition from a previous state very close to the
>> >> >> reception of the event, and the event handler lived long enough in the
>> >> >> queue to be alive in state 3.
>> >> >
>> >> > What determines the lifetime of the event handler?
>> >> >
>> >> >> Com'on Markus, show some UML ball-rolling...and tell us low-level C++
>> >> >> programmers what is The Right Thing To Do.
>> >> >
>> >> > Well, UML uses an event queue in which events are stored and processed
>> >> > one by one, which is reacting to old events (I don't agree however
>> >> > that this is a Good Thing).
>> >>
>> >> What do you mean with "old" events above Markus?
>> >
>> > Events which linger about in the event queue because the event
>> > selection function (variation point!) select other events first.
>>
>> As I am a slow understander: Can you illustrate the behavior with an example?
>
> Yes. Consider error handling. You have the following events in your
> queue:
>
> 1. a user request to do something
> 2. a fatal error signalled by a high level coordinator requiring an emergency stop
>
> Which one should be handled? Of course the emergency stop. But this is
> hard to express in pure UML, due to the "one event at a time"
> variation point and the unspecified dequeuing mechanism. Especially if
> the queue suddenly gets flooded by events (and I think this is likely
> in a robotic system) many unimportant events could be processed before
> the important one.
>
> There's actually a bit more to it, but I'm still in the process of
> thinking it out.
AFAIR, the dequeuing mechanism is a variation point, so that seems to
be taken into account?
A very (==too) quick check in the v2.2 superstructure spec, p 565
seems to confirm that:
<quote>
Event occurrences are detected, dispatched, and then processed by the
state machine, one at a time. The order of
dequeuing is not defined, leaving open the possibility of modeling
different priority-based schemes.
<quote>
Klaas
[Bug 703] TimerComponent commands do not work as are running in
On Wed, Sep 23, 2009 at 01:28:02PM +0200, Klaas Gadeyne wrote:
> On Wed, Sep 23, 2009 at 10:08 AM, Markus Klotzbuecher
> <markus [dot] klotzbuecher [..] ...> wrote:
> > On Tue, Sep 22, 2009 at 07:52:33PM +0200, Klaas Gadeyne wrote:
> >> On Tue, Sep 22, 2009 at 4:53 PM, Markus Klotzbuecher
> >> <markus [dot] klotzbuecher [..] ...> wrote:
> >> > On Tue, Sep 22, 2009 at 03:35:29PM +0200, Klaas Gadeyne wrote:
> >> >> On Mon, Sep 14, 2009 at 4:09 PM, Markus Klotzbuecher
> >> >> <markus [dot] klotzbuecher [..] ...> wrote:
> >> >> > On Mon, Sep 14, 2009 at 03:37:37PM +0200, Peter Soetens wrote:
> >> >> >> On Mon, Sep 14, 2009 at 15:24, Peter Soetens <peter [..] ...> wrote:
> >> >> >> > (bugzilla is a bit down for the moment)
> > ...
> >
> >> >> >> arbitrary amount of time). The arbitrarity in RTT is mainly determined
> >> >> >> by the fact that 3 has a bigger chance reacting to it than 4, because
> >> >> >> there was a transition from a previous state very close to the
> >> >> >> reception of the event, and the event handler lived long enough in the
> >> >> >> queue to be alive in state 3.
> >> >> >
> >> >> > What determines the lifetime of the event handler?
> >> >> >
> >> >> >> Com'on Markus, show some UML ball-rolling...and tell us low-level C++
> >> >> >> programmers what is The Right Thing To Do.
> >> >> >
> >> >> > Well, UML uses an event queue in which events are stored and processed
> >> >> > one by one, which is reacting to old events (I don't agree however
> >> >> > that this is a Good Thing).
> >> >>
> >> >> What do you mean with "old" events above Markus?
> >> >
> >> > Events which linger about in the event queue because the event
> >> > selection function (variation point!) select other events first.
> >>
> >> As I am a slow understander: Can you illustrate the behavior with an example?
> >
> > Yes. Consider error handling. You have the following events in your
> > queue:
> >
> > 1. a user request to do something
> > 2. a fatal error signalled by a high level coordinator requiring an emergency stop
> >
> > Which one should be handled? Of course the emergency stop. But this is
> > hard to express in pure UML, due to the "one event at a time"
> > variation point and the unspecified dequeuing mechanism. Especially if
> > the queue suddenly gets flooded by events (and I think this is likely
> > in a robotic system) many unimportant events could be processed before
> > the important one.
> >
> > There's actually a bit more to it, but I'm still in the process of
> > thinking it out.
>
> AFAIR, the dequeuing mechanism is a variation point, so that seems to
> be taken into account?
Yes, but I consider that to be more a problem than a solution. Of
course you can implement a priority based mechanism here. But our goal
is to be robust against different variation point implementations, so
defining such a specialized mechanism is not really an option.
> A very (==too) quick check in the v2.2 superstructure spec, p 565
> seems to confirm that:
> <quote>
> Event occurrences are detected, dispatched, and then processed by the
> state machine, one at a time. The order of
> dequeuing is not defined, leaving open the possibility of modeling
> different priority-based schemes.
> <quote>
Markus
[Bug 703] TimerComponent commands do not work as are running in
On Wed, Sep 23, 2009 at 4:16 PM, Markus Klotzbuecher
<markus [dot] klotzbuecher [..] ...> wrote:
> On Wed, Sep 23, 2009 at 01:28:02PM +0200, Klaas Gadeyne wrote:
>> On Wed, Sep 23, 2009 at 10:08 AM, Markus Klotzbuecher
>> <markus [dot] klotzbuecher [..] ...> wrote:
>> > On Tue, Sep 22, 2009 at 07:52:33PM +0200, Klaas Gadeyne wrote:
>> >> On Tue, Sep 22, 2009 at 4:53 PM, Markus Klotzbuecher
>> >> <markus [dot] klotzbuecher [..] ...> wrote:
>> >> > On Tue, Sep 22, 2009 at 03:35:29PM +0200, Klaas Gadeyne wrote:
>> >> >> On Mon, Sep 14, 2009 at 4:09 PM, Markus Klotzbuecher
>> >> >> <markus [dot] klotzbuecher [..] ...> wrote:
>> >> >> > On Mon, Sep 14, 2009 at 03:37:37PM +0200, Peter Soetens wrote:
>> >> >> >> On Mon, Sep 14, 2009 at 15:24, Peter Soetens <peter [..] ...> wrote:
>> >> >> >> > (bugzilla is a bit down for the moment)
>> > ...
>> >
>> >> >> >> arbitrary amount of time). The arbitrarity in RTT is mainly determined
>> >> >> >> by the fact that 3 has a bigger chance reacting to it than 4, because
>> >> >> >> there was a transition from a previous state very close to the
>> >> >> >> reception of the event, and the event handler lived long enough in the
>> >> >> >> queue to be alive in state 3.
>> >> >> >
>> >> >> > What determines the lifetime of the event handler?
>> >> >> >
>> >> >> >> Com'on Markus, show some UML ball-rolling...and tell us low-level C++
>> >> >> >> programmers what is The Right Thing To Do.
>> >> >> >
>> >> >> > Well, UML uses an event queue in which events are stored and processed
>> >> >> > one by one, which is reacting to old events (I don't agree however
>> >> >> > that this is a Good Thing).
>> >> >>
>> >> >> What do you mean with "old" events above Markus?
>> >> >
>> >> > Events which linger about in the event queue because the event
>> >> > selection function (variation point!) select other events first.
>> >>
>> >> As I am a slow understander: Can you illustrate the behavior with an example?
>> >
>> > Yes. Consider error handling. You have the following events in your
>> > queue:
>> >
>> > 1. a user request to do something
>> > 2. a fatal error signalled by a high level coordinator requiring an emergency stop
>> >
>> > Which one should be handled? Of course the emergency stop. But this is
>> > hard to express in pure UML, due to the "one event at a time"
>> > variation point and the unspecified dequeuing mechanism. Especially if
>> > the queue suddenly gets flooded by events (and I think this is likely
>> > in a robotic system) many unimportant events could be processed before
>> > the important one.
>> >
>> > There's actually a bit more to it, but I'm still in the process of
>> > thinking it out.
>>
>> AFAIR, the dequeuing mechanism is a variation point, so that seems to
>> be taken into account?
>
> Yes, but I consider that to be more a problem than a solution. Of
> course you can implement a priority based mechanism here. But our goal
> is to be robust against different variation point implementations, so
> defining such a specialized mechanism is not really an option.
I don't understand what you mean with "our goal is to be robust
against different variation point implementations"?
AFAIS, you can just make sure that the FSM implementation in the
orocos RTT implements this "variation point" in a way that it fulfils
the requirements of robotic applications?
But I'm probably missing something here...
Klaas
>> A very (==too) quick check in the v2.2 superstructure spec, p 565
>> seems to confirm that:
>> <quote>
>> Event occurrences are detected, dispatched, and then processed by the
>> state machine, one at a time. The order of
>> dequeuing is not defined, leaving open the possibility of modeling
>> different priority-based schemes.
>> <quote>
>
> Markus
>
[Bug 703] TimerComponent commands do not work as are running in
On Wed, Sep 23, 2009 at 05:13:38PM +0200, Klaas Gadeyne wrote:
> On Wed, Sep 23, 2009 at 4:16 PM, Markus Klotzbuecher
> <markus [dot] klotzbuecher [..] ...> wrote:
> > On Wed, Sep 23, 2009 at 01:28:02PM +0200, Klaas Gadeyne wrote:
> >> On Wed, Sep 23, 2009 at 10:08 AM, Markus Klotzbuecher
> >> <markus [dot] klotzbuecher [..] ...> wrote:
> >> > On Tue, Sep 22, 2009 at 07:52:33PM +0200, Klaas Gadeyne wrote:
> >> >> On Tue, Sep 22, 2009 at 4:53 PM, Markus Klotzbuecher
> >> >> <markus [dot] klotzbuecher [..] ...> wrote:
> >> >> > On Tue, Sep 22, 2009 at 03:35:29PM +0200, Klaas Gadeyne wrote:
> >> >> >> On Mon, Sep 14, 2009 at 4:09 PM, Markus Klotzbuecher
> >> >> >> <markus [dot] klotzbuecher [..] ...> wrote:
> >> >> >> > On Mon, Sep 14, 2009 at 03:37:37PM +0200, Peter Soetens wrote:
> >> >> >> >> On Mon, Sep 14, 2009 at 15:24, Peter Soetens <peter [..] ...> wrote:
> >> >> >> >> > (bugzilla is a bit down for the moment)
> >> > ...
> >> >
> >> >> >> >> arbitrary amount of time). The arbitrarity in RTT is mainly determined
> >> >> >> >> by the fact that 3 has a bigger chance reacting to it than 4, because
> >> >> >> >> there was a transition from a previous state very close to the
> >> >> >> >> reception of the event, and the event handler lived long enough in the
> >> >> >> >> queue to be alive in state 3.
> >> >> >> >
> >> >> >> > What determines the lifetime of the event handler?
> >> >> >> >
> >> >> >> >> Com'on Markus, show some UML ball-rolling...and tell us low-level C++
> >> >> >> >> programmers what is The Right Thing To Do.
> >> >> >> >
> >> >> >> > Well, UML uses an event queue in which events are stored and processed
> >> >> >> > one by one, which is reacting to old events (I don't agree however
> >> >> >> > that this is a Good Thing).
> >> >> >>
> >> >> >> What do you mean with "old" events above Markus?
> >> >> >
> >> >> > Events which linger about in the event queue because the event
> >> >> > selection function (variation point!) select other events first.
> >> >>
> >> >> As I am a slow understander: Can you illustrate the behavior with an example?
> >> >
> >> > Yes. Consider error handling. You have the following events in your
> >> > queue:
> >> >
> >> > 1. a user request to do something
> >> > 2. a fatal error signalled by a high level coordinator requiring an emergency stop
> >> >
> >> > Which one should be handled? Of course the emergency stop. But this is
> >> > hard to express in pure UML, due to the "one event at a time"
> >> > variation point and the unspecified dequeuing mechanism. Especially if
> >> > the queue suddenly gets flooded by events (and I think this is likely
> >> > in a robotic system) many unimportant events could be processed before
> >> > the important one.
> >> >
> >> > There's actually a bit more to it, but I'm still in the process of
> >> > thinking it out.
> >>
> >> AFAIR, the dequeuing mechanism is a variation point, so that seems to
> >> be taken into account?
> >
> > Yes, but I consider that to be more a problem than a solution. Of
> > course you can implement a priority based mechanism here. But our goal
> > is to be robust against different variation point implementations, so
> > defining such a specialized mechanism is not really an option.
>
> I don't understand what you mean with "our goal is to be robust
> against different variation point implementations"?
Existing tools and their users make different assumptions about how
variation points are implemented. But we do not want to create a new
flavor, instead we want a state machine which has been defined for the
RTT to work elsewhere too, precisely because it does not assume any
particular implementation of variation points.
> AFAIS, you can just make sure that the FSM implementation in the
> orocos RTT implements this "variation point" in a way that it fulfils
> the requirements of robotic applications?
Yes, if there is no other way out. But wouldn't it be desireable to
fulfil these without having to fill in a variation point "in a very
special way"?
> But I'm probably missing something here...
Not really :-)
Markus
[Bug 703] TimerComponent commands do not work as are running in
On Wed, Sep 23, 2009 at 5:45 PM, Markus Klotzbuecher
<markus [dot] klotzbuecher [..] ...> wrote:
[...]
>> >> > ...
>> >> >> >> >> arbitrary amount of time). The arbitrarity in RTT is mainly determined
>> >> >> >> >> by the fact that 3 has a bigger chance reacting to it than 4, because
>> >> >> >> >> there was a transition from a previous state very close to the
>> >> >> >> >> reception of the event, and the event handler lived long enough in the
>> >> >> >> >> queue to be alive in state 3.
>> >> >> >> >
>> >> >> >> > What determines the lifetime of the event handler?
>> >> >> >> >
>> >> >> >> >> Com'on Markus, show some UML ball-rolling...and tell us low-level C++
>> >> >> >> >> programmers what is The Right Thing To Do.
>> >> >> >> >
>> >> >> >> > Well, UML uses an event queue in which events are stored and processed
>> >> >> >> > one by one, which is reacting to old events (I don't agree however
>> >> >> >> > that this is a Good Thing).
>> >> >> >>
>> >> >> >> What do you mean with "old" events above Markus?
>> >> >> >
>> >> >> > Events which linger about in the event queue because the event
>> >> >> > selection function (variation point!) select other events first.
>> >> >>
>> >> >> As I am a slow understander: Can you illustrate the behavior with an example?
>> >> >
>> >> > Yes. Consider error handling. You have the following events in your
>> >> > queue:
>> >> >
>> >> > 1. a user request to do something
>> >> > 2. a fatal error signalled by a high level coordinator requiring an emergency stop
>> >> >
>> >> > Which one should be handled? Of course the emergency stop. But this is
>> >> > hard to express in pure UML, due to the "one event at a time"
>> >> > variation point and the unspecified dequeuing mechanism. Especially if
>> >> > the queue suddenly gets flooded by events (and I think this is likely
>> >> > in a robotic system) many unimportant events could be processed before
>> >> > the important one.
>> >> >
>> >> > There's actually a bit more to it, but I'm still in the process of
>> >> > thinking it out.
>> >>
>> >> AFAIR, the dequeuing mechanism is a variation point, so that seems to
>> >> be taken into account?
>> >
>> > Yes, but I consider that to be more a problem than a solution. Of
>> > course you can implement a priority based mechanism here. But our goal
>> > is to be robust against different variation point implementations, so
>> > defining such a specialized mechanism is not really an option.
>>
>> I don't understand what you mean with "our goal is to be robust
>> against different variation point implementations"?
>
> Existing tools and their users make different assumptions about how
> variation points are implemented. But we do not want to create a new
> flavor, instead we want a state machine which has been defined for the
> RTT to work elsewhere too, precisely because it does not assume any
> particular implementation of variation points.
>
>> AFAIS, you can just make sure that the FSM implementation in the
>> orocos RTT implements this "variation point" in a way that it fulfils
>> the requirements of robotic applications?
>
> Yes, if there is no other way out. But wouldn't it be desireable to
> fulfil these without having to fill in a variation point "in a very
> special way"?
Sure, although
- filling in a variation point (other on this list will prefer the
terms hotspot or implementation detail ;-P will always be "a very
special way".
- I think the use emergency use case (very relevant to
robotics/mechatronics) you just sketched above cannot be solved
_without_ assigning priorities to events
So I don't consider this "prioritized event queue" "a bad thing".
Klaas
[Bug 703] TimerComponent commands do not work as are running in
On Thu, Sep 24, 2009 at 09:09:48AM +0200, Klaas Gadeyne wrote:
> On Wed, Sep 23, 2009 at 5:45 PM, Markus Klotzbuecher
> <markus [dot] klotzbuecher [..] ...> wrote:
> [...]
> >> >> > ...
> >> >> >> >> >> arbitrary amount of time). The arbitrarity in RTT is mainly determined
> >> >> >> >> >> by the fact that 3 has a bigger chance reacting to it than 4, because
> >> >> >> >> >> there was a transition from a previous state very close to the
> >> >> >> >> >> reception of the event, and the event handler lived long enough in the
> >> >> >> >> >> queue to be alive in state 3.
> >> >> >> >> >
> >> >> >> >> > What determines the lifetime of the event handler?
> >> >> >> >> >
> >> >> >> >> >> Com'on Markus, show some UML ball-rolling...and tell us low-level C++
> >> >> >> >> >> programmers what is The Right Thing To Do.
> >> >> >> >> >
> >> >> >> >> > Well, UML uses an event queue in which events are stored and processed
> >> >> >> >> > one by one, which is reacting to old events (I don't agree however
> >> >> >> >> > that this is a Good Thing).
> >> >> >> >>
> >> >> >> >> What do you mean with "old" events above Markus?
> >> >> >> >
> >> >> >> > Events which linger about in the event queue because the event
> >> >> >> > selection function (variation point!) select other events first.
> >> >> >>
> >> >> >> As I am a slow understander: Can you illustrate the behavior with an example?
> >> >> >
> >> >> > Yes. Consider error handling. You have the following events in your
> >> >> > queue:
> >> >> >
> >> >> > 1. a user request to do something
> >> >> > 2. a fatal error signalled by a high level coordinator requiring an emergency stop
> >> >> >
> >> >> > Which one should be handled? Of course the emergency stop. But this is
> >> >> > hard to express in pure UML, due to the "one event at a time"
> >> >> > variation point and the unspecified dequeuing mechanism. Especially if
> >> >> > the queue suddenly gets flooded by events (and I think this is likely
> >> >> > in a robotic system) many unimportant events could be processed before
> >> >> > the important one.
> >> >> >
> >> >> > There's actually a bit more to it, but I'm still in the process of
> >> >> > thinking it out.
> >> >>
> >> >> AFAIR, the dequeuing mechanism is a variation point, so that seems to
> >> >> be taken into account?
> >> >
> >> > Yes, but I consider that to be more a problem than a solution. Of
> >> > course you can implement a priority based mechanism here. But our goal
> >> > is to be robust against different variation point implementations, so
> >> > defining such a specialized mechanism is not really an option.
> >>
> >> I don't understand what you mean with "our goal is to be robust
> >> against different variation point implementations"?
> >
> > Existing tools and their users make different assumptions about how
> > variation points are implemented. But we do not want to create a new
> > flavor, instead we want a state machine which has been defined for the
> > RTT to work elsewhere too, precisely because it does not assume any
> > particular implementation of variation points.
> >
> >> AFAIS, you can just make sure that the FSM implementation in the
> >> orocos RTT implements this "variation point" in a way that it fulfils
> >> the requirements of robotic applications?
> >
> > Yes, if there is no other way out. But wouldn't it be desireable to
> > fulfil these without having to fill in a variation point "in a very
> > special way"?
>
> Sure, although
> - filling in a variation point (other on this list will prefer the
> terms hotspot or implementation detail ;-P will always be "a very
> special way".
Yes, but it would be desireable not to depend on any particular
hotspot implementation.
> - I think the use emergency use case (very relevant to
> robotics/mechatronics) you just sketched above cannot be solved
> _without_ assigning priorities to events
Unless you can assign priorites in a different manner!
> So I don't consider this "prioritized event queue" "a bad thing".
Not bad, just ugly ;-)
Markus
[Bug 703] TimerComponent commands do not work as are running in
On Sep 22, 2009, at 09:35 , Klaas Gadeyne wrote:
> On Mon, Sep 14, 2009 at 4:09 PM, Markus Klotzbuecher
> <markus [dot] klotzbuecher [..] ...> wrote:
>> On Mon, Sep 14, 2009 at 03:37:37PM +0200, Peter Soetens wrote:
>>> On Mon, Sep 14, 2009 at 15:24, Peter Soetens <peter [..] ...
>>> > wrote:
>>>> (bugzilla is a bit down for the moment)
>>>>
>>>> This patch fixes the 'bug' in StateMachine.cpp. All event handlers
>>>> were enabled, as such states could react to events that happened in
>>>> previous states (ie before the state was entered).
>>>>
>>>> I'm not sure if there is any standard that says that you can't
>>>> react
>>>> to 'old' events or at which point in time you are allowed to
>>>> catch an
>>>> event. The implementation assumed that a state could react to
>>>> events
>>>> of any age... (but also that the age of an event was pretty
>>>> arbitrary)
>>>>
>>>> This patch might actually break code that somehow relied on
>>>> reacting
>>>> to events that happened when the SM was still in a previous
>>>> state. For
>>>> example:
>>>>
>>>> In state 1:
>>>> event(a).raised
>>>> event(b).raised
>>>> event(c).raised
>>>> ==> process event(a) and make transition to state 2
>>>> In state 2:
>>>> ==> process event(b) and make transition to state 3
>>>> In state 3:
>>>> ==> process event(c) and make transition to state 4
>>>> etc...
>>>>
>>>> This patch will drop (b) and (c). I'm not sure we want that...
>
> FWIW, if you would drop these, I think RTT FSMs would be non-UML
> conformant.
Is UML compliance a goal?
>>> I'm not entirely correct here. The situation that the test exposes
>>> is:
>>>
>>> In state 1:
>>> event(a).raised
>>> ==> process event(a) and make transition to state 2
>>> In state 2:
>>> ==> process event(a) and make transition to state 3 (maybe)
>>> In state 3:
>>> ==> process event(a) and make transition to state 4 (maybe)
>>>
>>>
>>> Logically, we think that once (a) has been consumed in state 1, the
>>> other states can no longer react to it. In the RTT, each state
>>> receives the event, and they all get a chance to react to it (for an
>>
>> Err, but only one state is active at a time and therefore only
>> transitions emanating from that state can be triggered by an event. I
>> don't get it?!
>
> Me neither :-(
> AFAIR, UML has the notion of deferred events (and each _state_ can
> decide which events are deferred). The semantics of this
> construction are that, when you are in state A, and event EA happens,
> and this doesn't trigger a transition from state A, event EA will
> remain in the "queue" and passed to the next state once event EB
> occurs which _does_ trigger a transition to the next state.
> However, EA is "consumed" in this case and should not trigger any
> further transitions anymore (I think).
Interesting. Intuitively, I would not have thought of that. And I
don't think I've ever written state machines with that kind of
deferred event in mind. Have any of you used this facility?
In your example Klass, can state A not use EA as a transition but
indicate to not defer it (ie just have it consumed)? Or is that
something that state B does upon entry - indicate what deferred states
it is interested? If EA is not used by state A nor state B, then does
it just sit in the deferred queue forever? What is the events lifetime?
>>> arbitrary amount of time). The arbitrarity in RTT is mainly
>>> determined
>>> by the fact that 3 has a bigger chance reacting to it than 4,
>>> because
>>> there was a transition from a previous state very close to the
>>> reception of the event, and the event handler lived long enough in
>>> the
>>> queue to be alive in state 3.
>>
>> What determines the lifetime of the event handler?
>>
>>> Com'on Markus, show some UML ball-rolling...and tell us low-level C
>>> ++
>>> programmers what is The Right Thing To Do.
>>
>> Well, UML uses an event queue in which events are stored and
>> processed
>> one by one, which is reacting to old events (I don't agree however
>> that this is a Good Thing).
>
> What do you mean with "old" events above Markus?
In Klass' example, if you take EA as an "old" event when state B is
entered, then I would personally agree that this is not a good thing.
Having future states reacting to "arbitrarily old" events could make
for some very interesting behaviour to debug. But like I said, I never
write state machines with this in mind so it is obviously a different
mindset to me.
Stephen
[Bug 703] TimerComponent commands do not work as are running in
On Tue, Sep 22, 2009 at 3:42 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
> On Sep 22, 2009, at 09:35 , Klaas Gadeyne wrote:
>
>> On Mon, Sep 14, 2009 at 4:09 PM, Markus Klotzbuecher
>> <markus [dot] klotzbuecher [..] ...> wrote:
>>>
>>> On Mon, Sep 14, 2009 at 03:37:37PM +0200, Peter Soetens wrote:
>>>>
>>>> On Mon, Sep 14, 2009 at 15:24, Peter Soetens <peter [..] ...>
>>>> wrote:
>>>>>
>>>>> (bugzilla is a bit down for the moment)
>>>>>
>>>>> This patch fixes the 'bug' in StateMachine.cpp. All event handlers
>>>>> were enabled, as such states could react to events that happened in
>>>>> previous states (ie before the state was entered).
>>>>>
>>>>> I'm not sure if there is any standard that says that you can't react
>>>>> to 'old' events or at which point in time you are allowed to catch an
>>>>> event. The implementation assumed that a state could react to events
>>>>> of any age... (but also that the age of an event was pretty arbitrary)
>>>>>
>>>>> This patch might actually break code that somehow relied on reacting
>>>>> to events that happened when the SM was still in a previous state. For
>>>>> example:
>>>>>
>>>>> In state 1:
>>>>> event(a).raised
>>>>> event(b).raised
>>>>> event(c).raised
>>>>> ==> process event(a) and make transition to state 2
>>>>> In state 2:
>>>>> ==> process event(b) and make transition to state 3
>>>>> In state 3:
>>>>> ==> process event(c) and make transition to state 4
>>>>> etc...
>>>>>
>>>>> This patch will drop (b) and (c). I'm not sure we want that...
>>
>> FWIW, if you would drop these, I think RTT FSMs would be non-UML
>> conformant.
>
> Is UML compliance a goal?
>
>>>> I'm not entirely correct here. The situation that the test exposes is:
>>>>
>>>> In state 1:
>>>> event(a).raised
>>>> ==> process event(a) and make transition to state 2
>>>> In state 2:
>>>> ==> process event(a) and make transition to state 3 (maybe)
>>>> In state 3:
>>>> ==> process event(a) and make transition to state 4 (maybe)
>>>>
>>>>
>>>> Logically, we think that once (a) has been consumed in state 1, the
>>>> other states can no longer react to it. In the RTT, each state
>>>> receives the event, and they all get a chance to react to it (for an
>>>
>>> Err, but only one state is active at a time and therefore only
>>> transitions emanating from that state can be triggered by an event. I
>>> don't get it?!
>>
>> Me neither :-(
>> AFAIR, UML has the notion of deferred events (and each _state_ can
>> decide which events are deferred). The semantics of this
>> construction are that, when you are in state A, and event EA happens,
>> and this doesn't trigger a transition from state A, event EA will
>> remain in the "queue" and passed to the next state once event EB
>> occurs which _does_ trigger a transition to the next state.
>> However, EA is "consumed" in this case and should not trigger any
>> further transitions anymore (I think).
>
> Interesting. Intuitively, I would not have thought of that. And I don't
> think I've ever written state machines with that kind of deferred event in
> mind. Have any of you used this facility?
No (I only wrote this down, because it was the thing that came closest
to the behavior Peter described)
> In your example Klass, can state A not use EA as a transition but indicate
> to not defer it (ie just have it consumed)? Or is that something that state
> B does upon entry - indicate what deferred states it is interested?
AFAIK (please check the spec :-) it should be specified by state A,
and state B cannot specify it (however, I don't know wether it makes
much sense to consider states in a FSM as "independent entities".
> If EA is
> not used by state A nor state B, then does it just sit in the deferred queue
> forever? What is the events lifetime?
If it is not used in B (for transitions), nor indicated as "to remain
deferred" by B, it will vanish from the queue.
>>>> arbitrary amount of time). The arbitrarity in RTT is mainly determined
>>>> by the fact that 3 has a bigger chance reacting to it than 4, because
>>>> there was a transition from a previous state very close to the
>>>> reception of the event, and the event handler lived long enough in the
>>>> queue to be alive in state 3.
>>>
>>> What determines the lifetime of the event handler?
>>>
>>>> Com'on Markus, show some UML ball-rolling...and tell us low-level C++
>>>> programmers what is The Right Thing To Do.
>>>
>>> Well, UML uses an event queue in which events are stored and processed
>>> one by one, which is reacting to old events (I don't agree however
>>> that this is a Good Thing).
>>
>> What do you mean with "old" events above Markus?
>
> In Klass' example, if you take EA as an "old" event when state B is entered,
> then I would personally agree that this is not a good thing. Having future
> states reacting to "arbitrarily old" events could make for some very
> interesting behaviour to debug. But like I said, I never write state
> machines with this in mind so it is obviously a different mindset to me.
Klaaaaaaaaaaaaaas
[Bug 703] TimerComponent commands do not work as are running in
On Tue, Sep 22, 2009 at 03:42:55PM +0200, S Roderick wrote:
> On Sep 22, 2009, at 09:35 , Klaas Gadeyne wrote:
...
> >>>> This patch will drop (b) and (c). I'm not sure we want that...
> >
> > FWIW, if you would drop these, I think RTT FSMs would be non-UML
> > conformant.
>
> Is UML compliance a goal?
Let's put it this way: the FSM I'm working on don't try to violate UML
without reason :-)
> >>> I'm not entirely correct here. The situation that the test exposes
> >>> is:
> >>>
> >>> In state 1:
> >>> event(a).raised
> >>> ==> process event(a) and make transition to state 2
> >>> In state 2:
> >>> ==> process event(a) and make transition to state 3 (maybe)
> >>> In state 3:
> >>> ==> process event(a) and make transition to state 4 (maybe)
> >>>
> >>>
> >>> Logically, we think that once (a) has been consumed in state 1, the
> >>> other states can no longer react to it. In the RTT, each state
> >>> receives the event, and they all get a chance to react to it (for an
> >>
> >> Err, but only one state is active at a time and therefore only
> >> transitions emanating from that state can be triggered by an event. I
> >> don't get it?!
> >
> > Me neither :-(
> > AFAIR, UML has the notion of deferred events (and each _state_ can
> > decide which events are deferred). The semantics of this
> > construction are that, when you are in state A, and event EA happens,
> > and this doesn't trigger a transition from state A, event EA will
> > remain in the "queue" and passed to the next state once event EB
> > occurs which _does_ trigger a transition to the next state.
> > However, EA is "consumed" in this case and should not trigger any
> > further transitions anymore (I think).
>
> Interesting. Intuitively, I would not have thought of that. And I
> don't think I've ever written state machines with that kind of
> deferred event in mind. Have any of you used this facility?
>
> In your example Klass, can state A not use EA as a transition but
> indicate to not defer it (ie just have it consumed)? Or is that
In UML you could add an internal transition with a "nop" program. Do
you have a concrete use for this?
> something that state B does upon entry - indicate what deferred states
> it is interested? If EA is not used by state A nor state B, then does
> it just sit in the deferred queue forever? What is the events lifetime?
This is unspecified in UML...
> >>> arbitrary amount of time). The arbitrarity in RTT is mainly
> >>> determined
> >>> by the fact that 3 has a bigger chance reacting to it than 4,
> >>> because
> >>> there was a transition from a previous state very close to the
> >>> reception of the event, and the event handler lived long enough in
> >>> the
> >>> queue to be alive in state 3.
> >>
> >> What determines the lifetime of the event handler?
> >>
> >>> Com'on Markus, show some UML ball-rolling...and tell us low-level C
> >>> ++
> >>> programmers what is The Right Thing To Do.
> >>
> >> Well, UML uses an event queue in which events are stored and
> >> processed
> >> one by one, which is reacting to old events (I don't agree however
> >> that this is a Good Thing).
> >
> > What do you mean with "old" events above Markus?
>
> In Klass' example, if you take EA as an "old" event when state B is
> entered, then I would personally agree that this is not a good thing.
> Having future states reacting to "arbitrarily old" events could make
> for some very interesting behaviour to debug. But like I said, I never
> write state machines with this in mind so it is obviously a different
> mindset to me.
You're absolutely right, that is a problem of UML FSM!
Markus
[Bug 703] TimerComponent commands do not work as are running in
https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=703
--- Comment #10 from Peter Soetens <peter [..] ...> 2009-09-14 13:43:44 ---
(In reply to comment #9)
> The modified functionality works, except for something the state machine test
> brings up. I think that timeout events are lingering around, and are causing
> state transitions later on. Otherwise, my understanding is incorrect of state
> machine and event interactions in Orocos.
>
>
> The above is with ID_TIMEOUT=4 and ID_EXTRA=4 in the state machine file. The
> TEST_3 state should not just breeze through - the timeout transition should not
> occur on first entering that state, as the timer with ID=4 should have expired
> and posted its event back in TEST_2 state as part of the waitFor(). Right?
>
> Similarly, set ID_EXTRA=5 in the state machine file, re-make (to get the state
> machine file copied to the build dir) and re-run the test, and you get
>
>
> Now state TEST_3 does what I expect, but TEST_4 is now also getting an immediate
> timeout event transition and not waiting on its timer (I think this is the same
> problem as above, just moved to a later state).
>
> Am I missing something here?
I'm looking into it. It looks like the event is delivered twice (or processed
twice).
Peter
[Bug 703] TimerComponent commands do not work as are running in
https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=703
--- Comment #9 from S Roderick <kiwi [dot] net [..] ...> 2009-09-11 21:25:48 ---
The modified functionality works, except for something the state machine test
brings up. I think that timeout events are lingering around, and are causing
state transitions later on. Otherwise, my understanding is incorrect of state
machine and event interactions in Orocos.
The above is with ID_TIMEOUT=4 and ID_EXTRA=4 in the state machine file. The
TEST_3 state should not just breeze through - the timeout transition should not
occur on first entering that state, as the timer with ID=4 should have expired
and posted its event back in TEST_2 state as part of the waitFor(). Right?
Similarly, set ID_EXTRA=5 in the state machine file, re-make (to get the state
machine file copied to the build dir) and re-run the test, and you get
Now state TEST_3 does what I expect, but TEST_4 is now also getting an
immediate timeout event transition and not waiting on its timer (I think this
is the same problem as above, just moved to a later state).
Am I missing something here?
[Bug 703] TimerComponent commands do not work as are running in
https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=703
--- Comment #8 from S Roderick <kiwi [dot] net [..] ...> 2009-09-11 21:18:06 ---
Created an attachment (id=498)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=498)
State machine file
[Bug 703] TimerComponent commands do not work as are running in
https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=703
--- Comment #7 from S Roderick <kiwi [dot] net [..] ...> 2009-09-11 21:17:52 ---
Created an attachment (id=497)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=497)
Test TimerComponent using state machine
[Bug 703] TimerComponent commands do not work as are running in
https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=703
--- Comment #6 from S Roderick <kiwi [dot] net [..] ...> 2009-09-11 21:17:19 ---
Created an attachment (id=496)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=496)
Partial patch to add new test case
[Bug 703] TimerComponent commands do not work as are running in
https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=703
--- Comment #5 from S Roderick <kiwi [dot] net [..] ...> 2009-09-11 21:13:47 ---
Created an attachment (id=495)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=495)
Add error log messages if Timer is passed an invalid ID
IMHO it shouldn't just silently ignore this. The user should be informed.
[Bug 703] TimerComponent commands do not work as are running in
https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=703
--- Comment #4 from S Roderick <kiwi [dot] net [..] ...> 2009-09-11 21:13:01 ---
Created an attachment (id=494)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=494)
Derive Timer publicly from RunnableInterface
To support OCL changes
[Bug 703] TimerComponent commands do not work as are running in
https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=703
S Roderick <kiwi [dot] net [..] ...> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #492 is|0 |1
obsolete| |
--- Comment #3 from S Roderick <kiwi [dot] net [..] ...> 2009-09-11 21:07:09 ---
Created an attachment (id=493)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=493)
Modified patch to correctly create thread for timer
Had to modify initial refactoring patch as it wasn't creating the thread for
timer, due to lack of scheduler/priority arguments to Timer::Timer().
Also removed some obsolete code, and function definitions that were never
implemented.
Verified on macosx Leopard with git RTT.
[Bug 703] TimerComponent commands do not work as are running in
https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=703
--- Comment #2 from Peter Soetens <peter [..] ...> 2009-09-11 14:17:39 ---
Created an attachment (id=492)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=492)
initial refactoring as proposed in the comment
I didn't test it (it compiles) and it requires that Timer inherits 'public'
from RunnableInterface instead of protected.
It also does not allow to set the priority and scheduler for the timer
activity. We could change them to match the component's priority/scheduler in
configureHook though (needs stop/start cycle of SingleThread).
I made the timer a member, since having it as a base class only adds more
management code/mess.
[Bug 703] TimerComponent commands do not work as are running in
https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=703
--- Comment #2 from Peter Soetens <peter [..] ...> 2009-09-11 14:17:39 ---
Created an attachment (id=492)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=492)
initial refactoring as proposed in the comment
I didn't test it (it compiles) and it requires that Timer inherits 'public'
from RunnableInterface instead of protected.
It also does not allow to set the priority and scheduler for the timer
activity. We could change them to match the component's priority/scheduler in
configureHook though (needs stop/start cycle of SingleThread).
I made the timer a member, since having it as a base class only adds more
management code/mess.
[Bug 703] TimerComponent commands do not work as are running in
On Sep 11, 2009, at 08:17 , Peter Soetens wrote:
> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=703
>
>
>
>
>
> --- Comment #2 from Peter Soetens <peter [..] ...>
> 2009-09-11 14:17:39 ---
> Created an attachment (id=492)
> --> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=492)
> initial refactoring as proposed in the comment
>
> I didn't test it (it compiles) and it requires that Timer inherits
> 'public'
> from RunnableInterface instead of protected.
>
> It also does not allow to set the priority and scheduler for the timer
> activity. We could change them to match the component's priority/
> scheduler in
> configureHook though (needs stop/start cycle of SingleThread).
>
> I made the timer a member, since having it as a base class only adds
> more
> management code/mess.
I can't "git apply" nor "patch" apply this patch to either trunk-SVN
nor git. I don't see a reason why they are failing to apply, but
nothing seems to work.
What is the origin of this patch?
S
[Bug 703] TimerComponent commands do not work as are running in
On Fri, Sep 11, 2009 at 15:17, S Roderick <kiwi [dot] net [..] ...> wrote:
> On Sep 11, 2009, at 08:17 , Peter Soetens wrote:
>
> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=703
>>
>>
>>
>>
>>
>> --- Comment #2 from Peter Soetens <peter [..] ...> 2009-09-11
>> 14:17:39 ---
>> Created an attachment (id=492)
>> --> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=492)
>> initial refactoring as proposed in the comment
>>
>> I didn't test it (it compiles) and it requires that Timer inherits
>> 'public'
>> from RunnableInterface instead of protected.
>>
>> It also does not allow to set the priority and scheduler for the timer
>> activity. We could change them to match the component's priority/scheduler
>> in
>> configureHook though (needs stop/start cycle of SingleThread).
>>
>> I made the timer a member, since having it as a base class only adds more
>> management code/mess.
>>
>
> I can't "git apply" nor "patch" apply this patch to either trunk-SVN nor
> git. I don't see a reason why they are failing to apply, but nothing seems
> to work.
>
> What is the origin of this patch?
>
Whoops. ocl-2.0-mainline. Out of habbit. It refers to os::Timer instead of
RTT::Timer. I backported it in attachment.
Peter
[Bug 703] TimerComponent commands do not work as are running in
https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=703
Peter Soetens <peter [..] ...> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |peter [..] ...
--- Comment #1 from Peter Soetens <peter [..] ...> 2009-09-11 13:38:16 ---
(In reply to comment #0)
> The TimerComponent has "wait" and "waitFor" commands. These don't work in the
> `tests/timer` program. I think this is because the TimerComponent uses a
> non-periodic activity to drive the timer, which does not yield to the command
> processor anywhere. Hence, methods such as "arm" work, however, commands like
> "wait" do not (the taskbrowser simply responds "queued" and the actual command
> does not get called).
>
> Has this ever worked, or am I missing something?
>
> If the above conjecture is correct, how could you use "wait" commands in a
> program script?
You're correct. It has never worked, and wait/waitFor is broken.
A possible solution is to let Timer's thread be as-is, and let the user specify
an additional thread to the TimerComponent (standard practice for TaskContexts,
and in 1.10, this thread would even be correctly an Activity object.). This
additional thread would then exist merely to process the wait commands, and
it's updateHook() would be empty.
Good idea ?
Peter
[Bug 703] TimerComponent commands do not work as are running in
On Sep 11, 2009, at 07:38 , Peter Soetens wrote:
> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=703
>
>
> Peter Soetens <peter [..] ...> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |
> peter [..] ...
>
>
>
>
> --- Comment #1 from Peter Soetens <peter [..] ...>
> 2009-09-11 13:38:16 ---
> (In reply to comment #0)
>> The TimerComponent has "wait" and "waitFor" commands. These don't
>> work in the
>> `tests/timer` program. I think this is because the TimerComponent
>> uses a
>> non-periodic activity to drive the timer, which does not yield to
>> the command
>> processor anywhere. Hence, methods such as "arm" work, however,
>> commands like
>> "wait" do not (the taskbrowser simply responds "queued" and the
>> actual command
>> does not get called).
>>
>> Has this ever worked, or am I missing something?
>>
>> If the above conjecture is correct, how could you use "wait"
>> commands in a
>> program script?
>
> You're correct. It has never worked, and wait/waitFor is broken.
>
> A possible solution is to let Timer's thread be as-is, and let the
> user specify
> an additional thread to the TimerComponent (standard practice for
> TaskContexts,
> and in 1.10, this thread would even be correctly an Activity
> object.). This
> additional thread would then exist merely to process the wait
> commands, and
> it's updateHook() would be empty.
>
> Good idea ?
So the additional thread/activity would be specified how? How would
this work with the deployer? This additional thread would be nothing
more than a periodic activity running commands, right?
An alternative might be to explicitly separate the TimerComponent into
two components; one that executes timers, and the other that executes
the commands like wait. While the separation of concerns here is
driven by system capabilities rather than functional requirements, it
does make each component easily deployable and parameterized.
We ended up explicitly embedding the TimerComponent into a parent
component, and just brought out to the parent's interface the
necessary wait(), arm(), etc, that we needed in our state machine. Bit
of a pain, but workable.
Stephen