Hello all,
I have encountered a problem with the event queue. I have modified the
helloworld example (hello-6-events) to reproduce the problem (see
attachment).
The "Hello" component has 2 events: "the_event" and "the_second_event".
In the updateHook function of this component these events are emitted
2 times but each time with other data as argument.
1) emit "the_event" with argument "Hello"
2) emit "the_event" with argument "world"
3) emit "the_second_event" with argument "Hello"
4) emit "the_second_event" with argument "world"
The World component implements 2 asynchronous callback functions (one
for the "Hello" event and one for the "world" event). Each callback
function prints the
value of the event argument to the console.
When I run this modified example, I get this strange output:
10.020 [ Info ][World] Receiving Event: Second event: Hello
20.020 [ Info ][World] Receiving Event: hello
20.020 [ Info ][World] Receiving Event: world
20.020 [ Info ][World] Receiving Event: Second event: Hello
20.020 [ Info ][World] Receiving Event: Second event: World
30.020 [ Info ][World] Receiving Event: hello
30.020 [ Info ][World] Receiving Event: Second event: Hello
40.020 [ Info ][World] Receiving Event: hello
40.020 [ Info ][World] Receiving Event: Second event: Hello
50.020 [ Info ][World] Receiving Event: hello
50.020 [ Info ][World] Receiving Event: Second event: Hello
60.020 [ Info ][World] Receiving Event: hello
60.020 [ Info ][World] Receiving Event: Second event: Hello
70.020 [ Info ][World] Receiving Event: hello
70.020 [ Info ][World] Receiving Event: Second event: Hello
80.020 [ Info ][World] Receiving Event: hello
80.020 [ Info ][World] Receiving Event: Second event: Hello
90.020 [ Info ][World] Receiving Event: hello
90.020 [ Info ][World] Receiving Event: Second event: Hello
100.020 [ Info ][World] Receiving Event: hello
100.020 [ Info ][World] Receiving Event: Second event: Hello
110.020 [ Info ][World] Receiving Event: hello
110.020 [ Info ][World] Receiving Event: Second event: Hello
120.020 [ Info ][World] Receiving Event: hello
120.020 [ Info ][World] Receiving Event: Second event: Hello
130.020 [ Info ][World] Receiving Event: hello
130.020 [ Info ][World] Receiving Event: Second event: Hello
140.020 [ Info ][World] Receiving Event: hello
140.020 [ Info ][World] Receiving Event: world
140.020 [ Info ][World] Receiving Event: Second event: Hello
140.020 [ Info ][World] Receiving Event: Second event: World
150.020 [ Info ][World] Receiving Event: hello
150.020 [ Info ][World] Receiving Event: world
150.020 [ Info ][World] Receiving Event: Second event: Hello
150.020 [ Info ][World] Receiving Event: Second event: World
160.020 [ Info ][World] Receiving Event: hello
160.020 [ Info ][World] Receiving Event: world
160.020 [ Info ][World] Receiving Event: Second event: Hello
160.020 [ Info ][World] Receiving Event: Second event: World
170.020 [ Info ][World] Receiving Event: hello
170.020 [ Info ][World] Receiving Event: Second event: Hello
180.020 [ Info ][World] Receiving Event: hello
180.020 [ Info ][World] Receiving Event: Second event: Hello
190.020 [ Info ][World] Receiving Event: hello
190.020 [ Info ][World] Receiving Event: Second event: Hello
200.020 [ Info ][World] Receiving Event: hello
200.020 [ Info ][World] Receiving Event: Second event: Hello
210.020 [ Info ][World] Receiving Event: hello
210.020 [ Info ][World] Receiving Event: Second event: Hello
220.020 [ Info ][World] Receiving Event: hello
220.020 [ Info ][World] Receiving Event: Second event: Hello
230.020 [ Info ][World] Receiving Event: hello
Looks like the events with the "world" argument are lost most of the time.
Modifying the activity (Periodic/nonPeriodic) and the priority of the
World component does not change the behavior.
Tested with rtt-1.6 and trunk (gnulinux and xenomai target).
Steven
| Attachment | Size |
|---|---|
| HelloWorld.cpp | 7.06 KB |
Event emitted multiple times is lost in event queue
> Hello all,
> I have encountered a problem with the event queue. I have modified the
helloworld example (hello-6-events) to reproduce the problem (see
attachment).
> The "Hello" component has 2 events: "the_event" and "the_second_event".
There is no such thing as a "event queue" yet. Upon asynchronous connection
to an event a handler is created and placed in a list. When an event is then
fired a task gets triggered. This task (EventProcessor) checks each event
handler in the list if it has work todo. If that is the case then the event
callback you have connected is executed. So if you fire the same event more
than once before the EventProcessor gets round to execute it, it gets
executed only once.
An other thing you should take into account is the fact you pass araound
std::string's as arguments. Each time you fire an event memory will be
allocated to the string in. Memory allocation usualy kill real-time
behaviour. Also the RTT::log() is not such a good idea. This class too uses
std::string's to do its job, this too will kill your real-time behaviour.
You have to implement your event queue your self. At least in the old RTT
days.
Butch.
Event emitted multiple times is lost in event queue
On Mon, 21 Sep 2009, Butch Slayer wrote:
> > Hello all,
>
> > I have encountered a problem with the event queue. I have modified the helloworld example
> (hello-6-events) to reproduce the problem (see attachment).
> > The "Hello" component has 2 events: "the_event" and "the_second_event".
>
> There is no such thing as a "event queue" yet. Upon asynchronous connection to an event a
> handler is created and placed in a list. When an event is then fired a task gets triggered. This
> task (EventProcessor) checks each event handler in the list if it has work todo. If that is the
> case then the event callback you have connected is executed. So if you fire the same event more
> than once before the EventProcessor gets round to execute it, it gets executed only once.
>
> An other thing you should take into account is the fact you pass araound std::string's as
> arguments. Each time you fire an event memory will be allocated to the string in. Memory
> allocation usualy kill real-time behaviour. Also the RTT::log() is not such a good idea. This
> class too uses std::string's to do its job, this too will kill your real-time behaviour.
>
> You have to implement your event queue your self. At least in the old RTT days.
>
It would be interesting for us to get people's preferences on this topic:
are event queues a good idea? Or rather, in what use cases are they a good
idea? And what would their semantics have to be?
Herman
> Butch.
>
>
--
K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
EURON Coordinator (European Robotics Research Network) <http://www.euron.org>
Open Realtime Control Services <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>
Event emitted multiple times is lost in event queue
On Mon, Sep 21, 2009 at 10:55, Herman Bruyninckx
<Herman [dot] Bruyninckx [..] ...> wrote:
> On Mon, 21 Sep 2009, Butch Slayer wrote:
>
>> > Hello all,
>>
>> > I have encountered a problem with the event queue. I have modified the helloworld example
>> (hello-6-events) to reproduce the problem (see attachment).
>> > The "Hello" component has 2 events: "the_event" and "the_second_event".
>>
>> There is no such thing as a "event queue" yet. Upon asynchronous connection to an event a
>> handler is created and placed in a list. When an event is then fired a task gets triggered. This
>> task (EventProcessor) checks each event handler in the list if it has work todo. If that is the
>> case then the event callback you have connected is executed. So if you fire the same event more
>> than once before the EventProcessor gets round to execute it, it gets executed only once.
>>
>> An other thing you should take into account is the fact you pass araound std::string's as
>> arguments. Each time you fire an event memory will be allocated to the string in. Memory
>> allocation usualy kill real-time behaviour. Also the RTT::log() is not such a good idea. This
>> class too uses std::string's to do its job, this too will kill your real-time behaviour.
>>
>> You have to implement your event queue your self. At least in the old RTT days.
>>
> It would be interesting for us to get people's preferences on this topic:
> are event queues a good idea? Or rather, in what use cases are they a good
> idea? And what would their semantics have to be?
That events need to be queued in applications is a truth in
multi-threaded/process applications. The problem with queues is that
the RTT has no idea how large a queue should be, since this is a
system level property (or should we say:policy). We had a similar
problem with the buffered Data Flow and decided to make this explicit
when the connection was made. A good thing. It looks like the queue
size of 'incoming asynchronous stuff' (events belong to that category)
should be a component property, which you can tune when the component
is deployed.
To Steven: In RTT 1.x, the events are 'queued' in a way but only per
event type. Each component can keep track of 16 (hard coded)
asynchronous events at a time, but only the first instance is used in
case of overrun of an event of the same type (just like 'Butch'
explained). The work around for this in 1.x is to register a
synchronous callback to the event and use a 'BufferLockFree<T>' that
stores the event data. You need then to empty this buffer in your
updateHook() and emit an event with that data (or implement any policy
that is fit for your component), but only one emission per updateHook,
such that the statemachines can 'follow'.
No need to say that this will be fixed in RTT 2.0.
Peter
Event emitted multiple times is lost in event queue
2009/9/21 Peter Soetens <peter [..] ...>:
> On Mon, Sep 21, 2009 at 10:55, Herman Bruyninckx
> <Herman [dot] Bruyninckx [..] ...> wrote:
>> On Mon, 21 Sep 2009, Butch Slayer wrote:
>>
>>> > Hello all,
>>>
>>> > I have encountered a problem with the event queue. I have modified the helloworld example
>>> (hello-6-events) to reproduce the problem (see attachment).
>>> > The "Hello" component has 2 events: "the_event" and "the_second_event".
>>>
>>> There is no such thing as a "event queue" yet. Upon asynchronous connection to an event a
>>> handler is created and placed in a list. When an event is then fired a task gets triggered. This
>>> task (EventProcessor) checks each event handler in the list if it has work todo. If that is the
>>> case then the event callback you have connected is executed. So if you fire the same event more
>>> than once before the EventProcessor gets round to execute it, it gets executed only once.
>>>
>>> An other thing you should take into account is the fact you pass araound std::string's as
>>> arguments. Each time you fire an event memory will be allocated to the string in. Memory
>>> allocation usualy kill real-time behaviour. Also the RTT::log() is not such a good idea. This
>>> class too uses std::string's to do its job, this too will kill your real-time behaviour.
>>>
>>> You have to implement your event queue your self. At least in the old RTT days.
>>>
>> It would be interesting for us to get people's preferences on this topic:
>> are event queues a good idea? Or rather, in what use cases are they a good
>> idea? And what would their semantics have to be?
>
> That events need to be queued in applications is a truth in
> multi-threaded/process applications. The problem with queues is that
> the RTT has no idea how large a queue should be, since this is a
> system level property (or should we say:policy). We had a similar
> problem with the buffered Data Flow and decided to make this explicit
> when the connection was made. A good thing. It looks like the queue
> size of 'incoming asynchronous stuff' (events belong to that category)
> should be a component property, which you can tune when the component
> is deployed.
>
> To Steven: In RTT 1.x, the events are 'queued' in a way but only per
> event type. Each component can keep track of 16 (hard coded)
> asynchronous events at a time, but only the first instance is used in
> case of overrun of an event of the same type (just like 'Butch'
> explained).
But if the priority of the "world" component is higher than the
priority of the "Hello" component, why is the "World" component not
woken up when the "Hello" component emits an event?
In this case it shouldn't be a problem that the event queue can only
contain one event per event type. The "World" component should be
rescheduled when an event is emitted. But if I run this program under
xenomai, I only see the first event, the second event is still lost.
> The work around for this in 1.x is to register a
> synchronous callback to the event and use a 'BufferLockFree<T>' that
> stores the event data. You need then to empty this buffer in your
> updateHook() and emit an event with that data (or implement any policy
> that is fit for your component), but only one emission per updateHook,
> such that the statemachines can 'follow'.
Event emitted multiple times is lost in event queue
On Mon, Oct 5, 2009 at 09:06, Steven Kauffmann
<steven [dot] kauffmann [..] ...> wrote:
> 2009/9/21 Peter Soetens <peter [..] ...>:
>> On Mon, Sep 21, 2009 at 10:55, Herman Bruyninckx
>> <Herman [dot] Bruyninckx [..] ...> wrote:
>>> On Mon, 21 Sep 2009, Butch Slayer wrote:
>>>
>>>> > Hello all,
>>>>
>>>> > I have encountered a problem with the event queue. I have modified the helloworld example
>>>> (hello-6-events) to reproduce the problem (see attachment).
>>>> > The "Hello" component has 2 events: "the_event" and "the_second_event".
>>>>
>>>> There is no such thing as a "event queue" yet. Upon asynchronous connection to an event a
>>>> handler is created and placed in a list. When an event is then fired a task gets triggered. This
>>>> task (EventProcessor) checks each event handler in the list if it has work todo. If that is the
>>>> case then the event callback you have connected is executed. So if you fire the same event more
>>>> than once before the EventProcessor gets round to execute it, it gets executed only once.
>>>>
>>>> An other thing you should take into account is the fact you pass araound std::string's as
>>>> arguments. Each time you fire an event memory will be allocated to the string in. Memory
>>>> allocation usualy kill real-time behaviour. Also the RTT::log() is not such a good idea. This
>>>> class too uses std::string's to do its job, this too will kill your real-time behaviour.
>>>>
>>>> You have to implement your event queue your self. At least in the old RTT days.
>>>>
>>> It would be interesting for us to get people's preferences on this topic:
>>> are event queues a good idea? Or rather, in what use cases are they a good
>>> idea? And what would their semantics have to be?
>>
>> That events need to be queued in applications is a truth in
>> multi-threaded/process applications. The problem with queues is that
>> the RTT has no idea how large a queue should be, since this is a
>> system level property (or should we say:policy). We had a similar
>> problem with the buffered Data Flow and decided to make this explicit
>> when the connection was made. A good thing. It looks like the queue
>> size of 'incoming asynchronous stuff' (events belong to that category)
>> should be a component property, which you can tune when the component
>> is deployed.
>>
>> To Steven: In RTT 1.x, the events are 'queued' in a way but only per
>> event type. Each component can keep track of 16 (hard coded)
>> asynchronous events at a time, but only the first instance is used in
>> case of overrun of an event of the same type (just like 'Butch'
>> explained).
>
> But if the priority of the "world" component is higher than the
> priority of the "Hello" component, why is the "World" component not
> woken up when the "Hello" component emits an event?
>
> In this case it shouldn't be a problem that the event queue can only
> contain one event per event type. The "World" component should be
> rescheduled when an event is emitted. But if I run this program under
> xenomai, I only see the first event, the second event is still lost.
The only reason can be that the rescheduling did not happen when we
raised the semaphore on which the high priority thread was blocking.
Dit you check in /proc/xenomai/sched that the effective priorities are
what you expect ? Do you see mode switches while running your test
program ?
Peter
Event emitted multiple times is lost in event queue
On Mon, Sep 21, 2009 at 11:59 AM, Peter Soetens
<peter [..] ...> wrote:
> On Mon, Sep 21, 2009 at 10:55, Herman Bruyninckx
>> On Mon, 21 Sep 2009, Butch Slayer wrote:
>>> > I have encountered a problem with the event queue. I have modified the helloworld example
>>> (hello-6-events) to reproduce the problem (see attachment).
>>> > The "Hello" component has 2 events: "the_event" and "the_second_event".
>>>
>>> There is no such thing as a "event queue" yet. Upon asynchronous connection to an event a
>>> handler is created and placed in a list. When an event is then fired a task gets triggered. This
>>> task (EventProcessor) checks each event handler in the list if it has work todo. If that is the
>>> case then the event callback you have connected is executed. So if you fire the same event more
>>> than once before the EventProcessor gets round to execute it, it gets executed only once.
>>>
>>> You have to implement your event queue your self. At least in the old RTT days.
>>>
[...]
>
> That events need to be queued in applications is a truth in
> multi-threaded/process applications. The problem with queues is that
> the RTT has no idea how large a queue should be, since this is a
> system level property (or should we say:policy). We had a similar
> problem with the buffered Data Flow and decided to make this explicit
> when the connection was made. A good thing. It looks like the queue
> size of 'incoming asynchronous stuff' (events belong to that category)
> should be a component property, which you can tune when the component
> is deployed.
>
> To Steven: In RTT 1.x, the events are 'queued' in a way but only per
> event type. Each component can keep track of 16 (hard coded)
> asynchronous events at a time, but only the first instance is used in
> case of overrun of an event of the same type (just like 'Butch'
> explained). The work around for this in 1.x is to register a
> synchronous callback to the event and use a 'BufferLockFree<T>' that
> stores the event data. You need then to empty this buffer in your
> updateHook() and emit an event with that data (or implement any policy
> that is fit for your component), but only one emission per updateHook,
> such that the statemachines can 'follow'.
Can this scheme work if updateHook() is connected to a NonPeriodicActivity?
Klaas (took me a while to figure out who butch slayer was :-)
Event emitted multiple times is lost in event queue
On Thu, Sep 24, 2009 at 10:04, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
> On Mon, Sep 21, 2009 at 11:59 AM, Peter Soetens
>>
>> To Steven: In RTT 1.x, the events are 'queued' in a way but only per
>> event type. Each component can keep track of 16 (hard coded)
>> asynchronous events at a time, but only the first instance is used in
>> case of overrun of an event of the same type (just like 'Butch'
>> explained). The work around for this in 1.x is to register a
>> synchronous callback to the event and use a 'BufferLockFree<T>' that
>> stores the event data. You need then to empty this buffer in your
>> updateHook() and emit an event with that data (or implement any policy
>> that is fit for your component), but only one emission per updateHook,
>> such that the statemachines can 'follow'.
>
> Can this scheme work if updateHook() is connected to a NonPeriodicActivity?
I seen no reason why it wouldn't, but you'll need to apply the
this->getActivity()->trigger() trick to re-schedule updateHook() if
there are still events left in your buffer.
Peter
Event emitted multiple times is lost in event queue
On Thu, Sep 24, 2009 at 3:22 PM, Peter Soetens <peter [..] ...> wrote:
> On Thu, Sep 24, 2009 at 10:04, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
>> On Mon, Sep 21, 2009 at 11:59 AM, Peter Soetens
>>>
>>> To Steven: In RTT 1.x, the events are 'queued' in a way but only per
>>> event type. Each component can keep track of 16 (hard coded)
>>> asynchronous events at a time, but only the first instance is used in
>>> case of overrun of an event of the same type (just like 'Butch'
>>> explained). The work around for this in 1.x is to register a
>>> synchronous callback to the event and use a 'BufferLockFree<T>' that
>>> stores the event data. You need then to empty this buffer in your
>>> updateHook() and emit an event with that data (or implement any policy
>>> that is fit for your component), but only one emission per updateHook,
>>> such that the statemachines can 'follow'.
>>
>> Can this scheme work if updateHook() is connected to a NonPeriodicActivity?
>
> I seen no reason why it wouldn't, but you'll need to apply the
> this->getActivity()->trigger() trick to re-schedule updateHook() if
> there are still events left in your buffer.
But how will you be waken up if you the queue is empty and an event is
added in the BufferLockFree<T> for the first time?
Klaas
Event emitted multiple times is lost in event queue
>
>
> To Steven: In RTT 1.x, the events are 'queued' in a way but only per
> event type. Each component can keep track of 16 (hard coded)
> asynchronous events at a time, but only the first instance is used in
> case of overrun of an event of the same type (just like 'Butch'
> explained). The work around for this in 1.x is to register a
> synchronous callback to the event and use a 'BufferLockFree<T>' that
> stores the event data. You need then to empty this buffer in your
> updateHook() and emit an event with that data (or implement any policy
> that is fit for your component), but only one emission per updateHook,
> such that the statemachines can 'follow'.
>
> No need to say that this will be fixed in RTT 2.0.
>
> If I recollect correctly from RTT 2.0 discussions this could be implemented
using 'event driven data ports'?
Butch.
Event emitted multiple times is lost in event queue
On Mon, Sep 21, 2009 at 12:18, Butch Slayer <butch [dot] slayers [..] ...> wrote:
>>
>> To Steven: In RTT 1.x, the events are 'queued' in a way but only per
>> event type. Each component can keep track of 16 (hard coded)
>> asynchronous events at a time, but only the first instance is used in
>> case of overrun of an event of the same type (just like 'Butch'
>> explained). The work around for this in 1.x is to register a
>> synchronous callback to the event and use a 'BufferLockFree<T>' that
>> stores the event data. You need then to empty this buffer in your
>> updateHook() and emit an event with that data (or implement any policy
>> that is fit for your component), but only one emission per updateHook,
>> such that the statemachines can 'follow'.
>>
>> No need to say that this will be fixed in RTT 2.0.
>>
> If I recollect correctly from RTT 2.0 discussions this could be implemented
> using 'event driven data ports'?
Yes, but it still requires fixing the events anyway, because the event
is emitted right away when new data arrives, so overruns could still
happen (although each data sample is saved in a data flow buffer).
Peter
Event emitted multiple times is lost in event queue
On Mon, 21 Sep 2009, Peter Soetens wrote:
> On Mon, Sep 21, 2009 at 10:55, Herman Bruyninckx
> <Herman [dot] Bruyninckx [..] ...> wrote:
>> On Mon, 21 Sep 2009, Butch Slayer wrote:
>>
>>>> Hello all,
>>>
>>>> I have encountered a problem with the event queue. I have modified the helloworld example
>>> (hello-6-events) to reproduce the problem (see attachment).
>>>> The "Hello" component has 2 events: "the_event" and "the_second_event".
>>>
>>> There is no such thing as a "event queue" yet. Upon asynchronous connection to an event a
>>> handler is created and placed in a list. When an event is then fired a task gets triggered. This
>>> task (EventProcessor) checks each event handler in the list if it has work todo. If that is the
>>> case then the event callback you have connected is executed. So if you fire the same event more
>>> than once before the EventProcessor gets round to execute it, it gets executed only once.
>>>
>>> An other thing you should take into account is the fact you pass araound std::string's as
>>> arguments. Each time you fire an event memory will be allocated to the string in. Memory
>>> allocation usualy kill real-time behaviour. Also the RTT::log() is not such a good idea. This
>>> class too uses std::string's to do its job, this too will kill your real-time behaviour.
>>>
>>> You have to implement your event queue your self. At least in the old RTT days.
>>>
>> It would be interesting for us to get people's preferences on this topic:
>> are event queues a good idea? Or rather, in what use cases are they a good
>> idea? And what would their semantics have to be?
>
> That events need to be queued in applications is a truth in
> multi-threaded/process applications.
Not necessarily... I can think of use cases where you want (and can) handle
each event immediately.
> The problem with queues is that
> the RTT has no idea how large a queue should be, since this is a
> system level property (or should we say:policy). We had a similar
> problem with the buffered Data Flow and decided to make this explicit
> when the connection was made. A good thing. It looks like the queue
> size of 'incoming asynchronous stuff' (events belong to that category)
> should be a component property, which you can tune when the component
> is deployed.
I agree that event queueing has most properties in common with data flow
"queueing".
> To Steven: In RTT 1.x, the events are 'queued' in a way but only per
> event type. Each component can keep track of 16 (hard coded)
> asynchronous events at a time, but only the first instance is used in
> case of overrun of an event of the same type (just like 'Butch'
> explained).
Did you just reveal "Butch's" identity?! :-)
> The work around for this in 1.x is to register a
> synchronous callback to the event and use a 'BufferLockFree<T>' that
> stores the event data. You need then to empty this buffer in your
> updateHook() and emit an event with that data (or implement any policy
> that is fit for your component), but only one emission per updateHook,
> such that the statemachines can 'follow'.
>
> No need to say that this will be fixed in RTT 2.0.
>
> Peter
>
Herman
--
K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
EURON Coordinator (European Robotics Research Network) <http://www.euron.org>
Open Realtime Control Services <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>