Hey,
I'm building a component using several EventPorts (toolchain-2.3).
I've made custom methods for all of them, so as to clearly monitor
which port received an update.
Apparently (I just found out in the documentation), the EventPort will
not only trigger my custom method, but also execute the component's
UpdateHook() afterwards. What's the reasoning behind calling
UpdateHook() here? As I wrote my own method, I didn't expect the
UpdateHook() getting executed as well.
This is however good behaviour for some of my ports (I was calling
UpdateHook manually anyway), but surely not for all. Is there a way I
can disable calling it?
Documentation from DataFlowInterface.hpp:
/**
* Add an Event triggering Port to the interface of this task and
* add a Service with the same name of the port.
* When data arrives on this port your TaskContext will be woken up
* and updateHook will be executed.
* @param port The port to add.
* @param callback (Optional) provide a function which will be called
* when new data arrives on this port. The callback function will
* be called in sequence with updateHook(), so asynchronously with
* regard to the arrival of data on the port.
* @return \a port
*/
base::InputPortInterface& addEventPort(base::InputPortInterface& port,
base::InputPortInterface::NewDataOnPortEvent::SlotFunction callback =
base ::InputPortInterface::NewDataOnPortEvent::SlotFunction() );
regards,
Steven
EventPort with custom method calls updateHook
On Sun, 20 Mar 2011, Steven Bellens wrote:
> Hey,
>
> I'm building a component using several EventPorts (toolchain-2.3).
> I've made custom methods for all of them, so as to clearly monitor
> which port received an update.
> Apparently (I just found out in the documentation), the EventPort will
> not only trigger my custom method, but also execute the component's
> UpdateHook() afterwards. What's the reasoning behind calling
> UpdateHook() here?
Events are _the_ mechanism for asynchronous Coordination, that means that
it is in their semantics to allow the receiving component to react to an
event.
> As I wrote my own method, I didn't expect the UpdateHook() getting
> executed as well.
The semantics is exactly that of an interrupt service in Operating Systems:
- the event handling (= your method) does the minimally required data
handling (typically, setting/getting some parameters);
- the Component is woken up to give it the opportunity to do its thing with
the newly set parameters.
In case you do the latter inside the former, you are making a separation of
concerns violation: the event handler should not know about what the
Component it is attached to will do with the event.
> This is however good behaviour for some of my ports (I was calling
> UpdateHook manually anyway), but surely not for all. Is there a way I
> can disable calling it?
What would be the use case in which a Component receives an event, but does
not get the chance to do something with it?
If there is some Configuration to be done, then that is at the event
handling level: how many events to handle before the Component is updated?
> Documentation from DataFlowInterface.hpp:
> /**
> * Add an Event triggering Port to the interface of this task and
> * add a Service with the same name of the port.
> * When data arrives on this port your TaskContext will be woken up
> * and updateHook will be executed.
> * @param port The port to add.
> * @param callback (Optional) provide a function which will be called
> * when new data arrives on this port. The callback function will
> * be called in sequence with updateHook(), so asynchronously with
> * regard to the arrival of data on the port.
> * @return \a port
> */
> base::InputPortInterface& addEventPort(base::InputPortInterface& port,
> base::InputPortInterface::NewDataOnPortEvent::SlotFunction callback =
> base ::InputPortInterface::NewDataOnPortEvent::SlotFunction() );
>
>
> regards,
>
> Steven
Herman
EventPort with custom method calls updateHook
On Sun, 20 Mar 2011, Steven Bellens wrote:
> Hey,
>
> I'm building a component using several EventPorts (toolchain-2.3).
> I've made custom methods for all of them, so as to clearly monitor
> which port received an update.
> Apparently (I just found out in the documentation), the EventPort will
> not only trigger my custom method, but also execute the component's
> UpdateHook() afterwards. What's the reasoning behind calling
> UpdateHook() here?
Events are _the_ mechanism for asynchronous Coordination, that means that
it is in their semantics to allow the receiving component to react to an
event.
> As I wrote my own method, I didn't expect the UpdateHook() getting
> executed as well.
The semantics is exactly that of an interrupt service in Operating Systems:
- the event handling (= your method) does the minimally required data
handling (typically, setting/getting some parameters);
- the Component is woken up to give it the opportunity to do its thing with
the newly set parameters.
In case you do the latter inside the former, you are making a separation of
concerns violation: the event handler should not know about what the
Component it is attached to will do with the event.
> This is however good behaviour for some of my ports (I was calling
> UpdateHook manually anyway), but surely not for all. Is there a way I
> can disable calling it?
What would be the use case in which a Component receives an event, but does
not get the chance to do something with it?
If there is some Configuration to be done, then that is at the event
handling level: how many events to handle before the Component is updated?
> Documentation from DataFlowInterface.hpp:
> /**
> * Add an Event triggering Port to the interface of this task and
> * add a Service with the same name of the port.
> * When data arrives on this port your TaskContext will be woken up
> * and updateHook will be executed.
> * @param port The port to add.
> * @param callback (Optional) provide a function which will be called
> * when new data arrives on this port. The callback function will
> * be called in sequence with updateHook(), so asynchronously with
> * regard to the arrival of data on the port.
> * @return \a port
> */
> base::InputPortInterface& addEventPort(base::InputPortInterface& port,
> base::InputPortInterface::NewDataOnPortEvent::SlotFunction callback =
> base ::InputPortInterface::NewDataOnPortEvent::SlotFunction() );
>
>
> regards,
>
> Steven
Herman
EventPort with custom method calls updateHook
2011/3/20 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
> On Sun, 20 Mar 2011, Steven Bellens wrote:
>
>> Hey,
>>
>> I'm building a component using several EventPorts (toolchain-2.3).
>> I've made custom methods for all of them, so as to clearly monitor
>> which port received an update.
>> Apparently (I just found out in the documentation), the EventPort will
>> not only trigger my custom method, but also execute the component's
>> UpdateHook() afterwards. What's the reasoning behind calling
>> UpdateHook() here?
>
> Events are _the_ mechanism for asynchronous Coordination, that means that
> it is in their semantics to allow the receiving component to react to an
> event.
>
>> As I wrote my own method, I didn't expect the UpdateHook() getting
>> executed as well.
>
> The semantics is exactly that of an interrupt service in Operating Systems:
> - the event handling (= your method) does the minimally required data
> handling (typically, setting/getting some parameters);
> - the Component is woken up to give it the opportunity to do its thing with
> the newly set parameters.
>
> In case you do the latter inside the former, you are making a separation of
> concerns violation: the event handler should not know about what the
> Component it is attached to will do with the event.
>
>> This is however good behaviour for some of my ports (I was calling
>> UpdateHook manually anyway), but surely not for all. Is there a way I
>> can disable calling it?
>
> What would be the use case in which a Component receives an event, but does
> not get the chance to do something with it?
The component involved is a pose controller component, receiving
current pose measurements and a goal pose and outputting control
signals (it's also accepting goal velocities, but that's not relevant
here).
The methods connected to these EventPorts read in the new values each
time a new measurement or goal is received => after these methods I do
want UpdateHook() to execute to update the control signals.
To monitor whether new measurements are received in time, I hooked up
the controller component to a TimerComponent and implemented a
watchdog (which get's executed every time the TimerComponent triggers
the watchdog EventPort). If no new measurements are received withing
e.g. 0.1s, the ControlMode is changed. So for this method I had in
mind:
- if no new measurements are received in time - change the controlMode
=> now I want updateHook to be called of course.
- as long as new measurements are received in time - don't do anything
=> don't call the updateHook here, as nor the measurements nor the
goal state have changed.
I know it's not a terrible thing UpdateHook() get's called here as
well, but it makes the watchdog pretty intrusive, which is not how it
should be.
Regards,
Steven
>
> If there is some Configuration to be done, then that is at the event
> handling level: how many events to handle before the Component is updated?
>
>> Documentation from DataFlowInterface.hpp:
>> /**
>> * Add an Event triggering Port to the interface of this task and
>> * add a Service with the same name of the port.
>> * When data arrives on this port your TaskContext will be woken up
>> * and updateHook will be executed.
>> * @param port The port to add.
>> * @param callback (Optional) provide a function which will be called
>> * when new data arrives on this port. The callback function will
>> * be called in sequence with updateHook(), so asynchronously with
>> * regard to the arrival of data on the port.
>> * @return \a port
>> */
>> base::InputPortInterface& addEventPort(base::InputPortInterface& port,
>> base::InputPortInterface::NewDataOnPortEvent::SlotFunction callback =
>> base ::InputPortInterface::NewDataOnPortEvent::SlotFunction() );
>>
>>
>> regards,
>>
>> Steven
>
> Herman
>
EventPort with custom method calls updateHook
2011/3/20 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
> On Sun, 20 Mar 2011, Steven Bellens wrote:
>
>> Hey,
>>
>> I'm building a component using several EventPorts (toolchain-2.3).
>> I've made custom methods for all of them, so as to clearly monitor
>> which port received an update.
>> Apparently (I just found out in the documentation), the EventPort will
>> not only trigger my custom method, but also execute the component's
>> UpdateHook() afterwards. What's the reasoning behind calling
>> UpdateHook() here?
>
> Events are _the_ mechanism for asynchronous Coordination, that means that
> it is in their semantics to allow the receiving component to react to an
> event.
>
>> As I wrote my own method, I didn't expect the UpdateHook() getting
>> executed as well.
>
> The semantics is exactly that of an interrupt service in Operating Systems:
> - the event handling (= your method) does the minimally required data
> handling (typically, setting/getting some parameters);
> - the Component is woken up to give it the opportunity to do its thing with
> the newly set parameters.
>
> In case you do the latter inside the former, you are making a separation of
> concerns violation: the event handler should not know about what the
> Component it is attached to will do with the event.
>
>> This is however good behaviour for some of my ports (I was calling
>> UpdateHook manually anyway), but surely not for all. Is there a way I
>> can disable calling it?
>
> What would be the use case in which a Component receives an event, but does
> not get the chance to do something with it?
The component involved is a pose controller component, receiving
current pose measurements and a goal pose and outputting control
signals (it's also accepting goal velocities, but that's not relevant
here).
The methods connected to these EventPorts read in the new values each
time a new measurement or goal is received => after these methods I do
want UpdateHook() to execute to update the control signals.
To monitor whether new measurements are received in time, I hooked up
the controller component to a TimerComponent and implemented a
watchdog (which get's executed every time the TimerComponent triggers
the watchdog EventPort). If no new measurements are received withing
e.g. 0.1s, the ControlMode is changed. So for this method I had in
mind:
- if no new measurements are received in time - change the controlMode
=> now I want updateHook to be called of course.
- as long as new measurements are received in time - don't do anything
=> don't call the updateHook here, as nor the measurements nor the
goal state have changed.
I know it's not a terrible thing UpdateHook() get's called here as
well, but it makes the watchdog pretty intrusive, which is not how it
should be.
Regards,
Steven
>
> If there is some Configuration to be done, then that is at the event
> handling level: how many events to handle before the Component is updated?
>
>> Documentation from DataFlowInterface.hpp:
>> /**
>> * Add an Event triggering Port to the interface of this task and
>> * add a Service with the same name of the port.
>> * When data arrives on this port your TaskContext will be woken up
>> * and updateHook will be executed.
>> * @param port The port to add.
>> * @param callback (Optional) provide a function which will be called
>> * when new data arrives on this port. The callback function will
>> * be called in sequence with updateHook(), so asynchronously with
>> * regard to the arrival of data on the port.
>> * @return \a port
>> */
>> base::InputPortInterface& addEventPort(base::InputPortInterface& port,
>> base::InputPortInterface::NewDataOnPortEvent::SlotFunction callback =
>> base ::InputPortInterface::NewDataOnPortEvent::SlotFunction() );
>>
>>
>> regards,
>>
>> Steven
>
> Herman
>
EventPort with custom method calls updateHook
On Sun, 20 Mar 2011, Steven Bellens wrote:
> 2011/3/20 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
>> On Sun, 20 Mar 2011, Steven Bellens wrote:
>>
>>> Hey,
>>>
>>> I'm building a component using several EventPorts (toolchain-2.3).
>>> I've made custom methods for all of them, so as to clearly monitor
>>> which port received an update.
>>> Apparently (I just found out in the documentation), the EventPort will
>>> not only trigger my custom method, but also execute the component's
>>> UpdateHook() afterwards. What's the reasoning behind calling
>>> UpdateHook() here?
>>
>> Events are _the_ mechanism for asynchronous Coordination, that means that
>> it is in their semantics to allow the receiving component to react to an
>> event.
>>
>>> As I wrote my own method, I didn't expect the UpdateHook() getting
>>> executed as well.
>>
>> The semantics is exactly that of an interrupt service in Operating Systems:
>> - the event handling (= your method) does the minimally required data
>> handling (typically, setting/getting some parameters);
>> - the Component is woken up to give it the opportunity to do its thing with
>> the newly set parameters.
>>
>> In case you do the latter inside the former, you are making a separation of
>> concerns violation: the event handler should not know about what the
>> Component it is attached to will do with the event.
>>
>>> This is however good behaviour for some of my ports (I was calling
>>> UpdateHook manually anyway), but surely not for all. Is there a way I
>>> can disable calling it?
>>
>> What would be the use case in which a Component receives an event, but does
>> not get the chance to do something with it?
>
> The component involved is a pose controller component, receiving
> current pose measurements and a goal pose and outputting control
> signals (it's also accepting goal velocities, but that's not relevant
> here).
> The methods connected to these EventPorts read in the new values each
> time a new measurement or goal is received => after these methods I do
> want UpdateHook() to execute to update the control signals.
Yes, that's indeed the semantically intended behaviour of an event.
> To monitor whether new measurements are received in time, I hooked up
> the controller component to a TimerComponent and implemented a
> watchdog (which get's executed every time the TimerComponent triggers
> the watchdog EventPort). If no new measurements are received withing
> e.g. 0.1s, the ControlMode is changed. So for this method I had in
> mind:
> - if no new measurements are received in time - change the controlMode
> => now I want updateHook to be called of course.
> - as long as new measurements are received in time - don't do anything
> => don't call the updateHook here, as nor the measurements nor the
> goal state have changed.
The _responsibility_ to change or not change belongs to the _controller
component_ (and most probably, to its Coordination state machine), not to
the event handler! The way you do it now is a violation of the "5Cs"
separation of concerns. Some potential problems with your approach, that
are not there in the architecture I propose are:
- when the designers want to change the discrete Coordination behaviour of
their control component, they should be able to do that by looking at
only one single place, namely the Coordination FSM. (And not in every event
handler that the component might be subscribed to.)
- the controller might want to know how many times it has already been
receiving data in time, or how many times it has already missed data,
etc. This bookkeeping (and the possible decision making around it) belongs
in the controller component, and not in the event handler.
> I know it's not a terrible thing UpdateHook() get's called here as
> well, but it makes the watchdog pretty intrusive, which is not how it
> should be.
What do you mean with "pretty intrusive"? And watchdogs _should_ be
"intrusive" since that's the key essence of their existence :-)
> Regards,
>
> Steven
Herman
EventPort with custom method calls updateHook
On Sun, 20 Mar 2011, Steven Bellens wrote:
> 2011/3/20 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
>> On Sun, 20 Mar 2011, Steven Bellens wrote:
>>
>>> Hey,
>>>
>>> I'm building a component using several EventPorts (toolchain-2.3).
>>> I've made custom methods for all of them, so as to clearly monitor
>>> which port received an update.
>>> Apparently (I just found out in the documentation), the EventPort will
>>> not only trigger my custom method, but also execute the component's
>>> UpdateHook() afterwards. What's the reasoning behind calling
>>> UpdateHook() here?
>>
>> Events are _the_ mechanism for asynchronous Coordination, that means that
>> it is in their semantics to allow the receiving component to react to an
>> event.
>>
>>> As I wrote my own method, I didn't expect the UpdateHook() getting
>>> executed as well.
>>
>> The semantics is exactly that of an interrupt service in Operating Systems:
>> - the event handling (= your method) does the minimally required data
>> handling (typically, setting/getting some parameters);
>> - the Component is woken up to give it the opportunity to do its thing with
>> the newly set parameters.
>>
>> In case you do the latter inside the former, you are making a separation of
>> concerns violation: the event handler should not know about what the
>> Component it is attached to will do with the event.
>>
>>> This is however good behaviour for some of my ports (I was calling
>>> UpdateHook manually anyway), but surely not for all. Is there a way I
>>> can disable calling it?
>>
>> What would be the use case in which a Component receives an event, but does
>> not get the chance to do something with it?
>
> The component involved is a pose controller component, receiving
> current pose measurements and a goal pose and outputting control
> signals (it's also accepting goal velocities, but that's not relevant
> here).
> The methods connected to these EventPorts read in the new values each
> time a new measurement or goal is received => after these methods I do
> want UpdateHook() to execute to update the control signals.
Yes, that's indeed the semantically intended behaviour of an event.
> To monitor whether new measurements are received in time, I hooked up
> the controller component to a TimerComponent and implemented a
> watchdog (which get's executed every time the TimerComponent triggers
> the watchdog EventPort). If no new measurements are received withing
> e.g. 0.1s, the ControlMode is changed. So for this method I had in
> mind:
> - if no new measurements are received in time - change the controlMode
> => now I want updateHook to be called of course.
> - as long as new measurements are received in time - don't do anything
> => don't call the updateHook here, as nor the measurements nor the
> goal state have changed.
The _responsibility_ to change or not change belongs to the _controller
component_ (and most probably, to its Coordination state machine), not to
the event handler! The way you do it now is a violation of the "5Cs"
separation of concerns. Some potential problems with your approach, that
are not there in the architecture I propose are:
- when the designers want to change the discrete Coordination behaviour of
their control component, they should be able to do that by looking at
only one single place, namely the Coordination FSM. (And not in every event
handler that the component might be subscribed to.)
- the controller might want to know how many times it has already been
receiving data in time, or how many times it has already missed data,
etc. This bookkeeping (and the possible decision making around it) belongs
in the controller component, and not in the event handler.
> I know it's not a terrible thing UpdateHook() get's called here as
> well, but it makes the watchdog pretty intrusive, which is not how it
> should be.
What do you mean with "pretty intrusive"? And watchdogs _should_ be
"intrusive" since that's the key essence of their existence :-)
> Regards,
>
> Steven
Herman
EventPort with custom method calls updateHook
2011/3/20 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
> On Sun, 20 Mar 2011, Steven Bellens wrote:
>
>> 2011/3/20 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
>>> On Sun, 20 Mar 2011, Steven Bellens wrote:
>>>
>>>> Hey,
>>>>
>>>> I'm building a component using several EventPorts (toolchain-2.3).
>>>> I've made custom methods for all of them, so as to clearly monitor
>>>> which port received an update.
>>>> Apparently (I just found out in the documentation), the EventPort will
>>>> not only trigger my custom method, but also execute the component's
>>>> UpdateHook() afterwards. What's the reasoning behind calling
>>>> UpdateHook() here?
>>>
>>> Events are _the_ mechanism for asynchronous Coordination, that means that
>>> it is in their semantics to allow the receiving component to react to an
>>> event.
>>>
>>>> As I wrote my own method, I didn't expect the UpdateHook() getting
>>>> executed as well.
>>>
>>> The semantics is exactly that of an interrupt service in Operating Systems:
>>> - the event handling (= your method) does the minimally required data
>>> handling (typically, setting/getting some parameters);
>>> - the Component is woken up to give it the opportunity to do its thing with
>>> the newly set parameters.
>>>
>>> In case you do the latter inside the former, you are making a separation of
>>> concerns violation: the event handler should not know about what the
>>> Component it is attached to will do with the event.
>>>
>>>> This is however good behaviour for some of my ports (I was calling
>>>> UpdateHook manually anyway), but surely not for all. Is there a way I
>>>> can disable calling it?
>>>
>>> What would be the use case in which a Component receives an event, but does
>>> not get the chance to do something with it?
>>
>> The component involved is a pose controller component, receiving
>> current pose measurements and a goal pose and outputting control
>> signals (it's also accepting goal velocities, but that's not relevant
>> here).
>> The methods connected to these EventPorts read in the new values each
>> time a new measurement or goal is received => after these methods I do
>> want UpdateHook() to execute to update the control signals.
>
> Yes, that's indeed the semantically intended behaviour of an event.
>
>> To monitor whether new measurements are received in time, I hooked up
>> the controller component to a TimerComponent and implemented a
>> watchdog (which get's executed every time the TimerComponent triggers
>> the watchdog EventPort). If no new measurements are received withing
>> e.g. 0.1s, the ControlMode is changed. So for this method I had in
>> mind:
>> - if no new measurements are received in time - change the controlMode
>> => now I want updateHook to be called of course.
>> - as long as new measurements are received in time - don't do anything
>> => don't call the updateHook here, as nor the measurements nor the
>> goal state have changed.
>
> The _responsibility_ to change or not change belongs to the _controller
> component_ (and most probably, to its Coordination state machine), not to
> the event handler! The way you do it now is a violation of the "5Cs"
> separation of concerns. Some potential problems with your approach, that
> are not there in the architecture I propose are:
> - when the designers want to change the discrete Coordination behaviour of
> their control component, they should be able to do that by looking at
> only one single place, namely the Coordination FSM. (And not in every event
> handler that the component might be subscribed to.)
> - the controller might want to know how many times it has already been
> receiving data in time, or how many times it has already missed data,
> etc. This bookkeeping (and the possible decision making around it) belongs
> in the controller component, and not in the event handler.
I can do the decision making in the UpdateHook() (based on the flag
set in the watchdog event method), but then still this UpdateHook()
will get called with every watchdog trigger, which is still unneeded.
I could add some extra variables to keep track of why UpdateHook()
gets called and let it do nothing if the watchdog method called it
(and no ControlMode change is needed) (=> this would be the decision
making), but it looks like a lot of overhead to me, considering the
original problem?
Alternatively, I can remove the separate Event triggered methods and
check them all in UpdateHook() and take appropriate actions there? But
I actually like the fact of making seperate methods for every
EventPort.
I know there are various solutions, just wondering which is the best one...
>
>> I know it's not a terrible thing UpdateHook() get's called here as
>> well, but it makes the watchdog pretty intrusive, which is not how it
>> should be.
>
> What do you mean with "pretty intrusive"? And watchdogs _should_ be
> "intrusive" since that's the key essence of their existence :-)
It should monitor, in this case, the measurement update frequency, but
as long as everything goes well, it's influence should be as minimal
as possible (only the EventPort method execution). It should only make
it's presence felt the moment the measurements go wrong.
Steven
>
>> Regards,
>>
>> Steven
>
> Herman
EventPort with custom method calls updateHook
2011/3/20 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
> On Sun, 20 Mar 2011, Steven Bellens wrote:
>
>> 2011/3/20 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
>>> On Sun, 20 Mar 2011, Steven Bellens wrote:
>>>
>>>> Hey,
>>>>
>>>> I'm building a component using several EventPorts (toolchain-2.3).
>>>> I've made custom methods for all of them, so as to clearly monitor
>>>> which port received an update.
>>>> Apparently (I just found out in the documentation), the EventPort will
>>>> not only trigger my custom method, but also execute the component's
>>>> UpdateHook() afterwards. What's the reasoning behind calling
>>>> UpdateHook() here?
>>>
>>> Events are _the_ mechanism for asynchronous Coordination, that means that
>>> it is in their semantics to allow the receiving component to react to an
>>> event.
>>>
>>>> As I wrote my own method, I didn't expect the UpdateHook() getting
>>>> executed as well.
>>>
>>> The semantics is exactly that of an interrupt service in Operating Systems:
>>> - the event handling (= your method) does the minimally required data
>>> handling (typically, setting/getting some parameters);
>>> - the Component is woken up to give it the opportunity to do its thing with
>>> the newly set parameters.
>>>
>>> In case you do the latter inside the former, you are making a separation of
>>> concerns violation: the event handler should not know about what the
>>> Component it is attached to will do with the event.
>>>
>>>> This is however good behaviour for some of my ports (I was calling
>>>> UpdateHook manually anyway), but surely not for all. Is there a way I
>>>> can disable calling it?
>>>
>>> What would be the use case in which a Component receives an event, but does
>>> not get the chance to do something with it?
>>
>> The component involved is a pose controller component, receiving
>> current pose measurements and a goal pose and outputting control
>> signals (it's also accepting goal velocities, but that's not relevant
>> here).
>> The methods connected to these EventPorts read in the new values each
>> time a new measurement or goal is received => after these methods I do
>> want UpdateHook() to execute to update the control signals.
>
> Yes, that's indeed the semantically intended behaviour of an event.
>
>> To monitor whether new measurements are received in time, I hooked up
>> the controller component to a TimerComponent and implemented a
>> watchdog (which get's executed every time the TimerComponent triggers
>> the watchdog EventPort). If no new measurements are received withing
>> e.g. 0.1s, the ControlMode is changed. So for this method I had in
>> mind:
>> - if no new measurements are received in time - change the controlMode
>> => now I want updateHook to be called of course.
>> - as long as new measurements are received in time - don't do anything
>> => don't call the updateHook here, as nor the measurements nor the
>> goal state have changed.
>
> The _responsibility_ to change or not change belongs to the _controller
> component_ (and most probably, to its Coordination state machine), not to
> the event handler! The way you do it now is a violation of the "5Cs"
> separation of concerns. Some potential problems with your approach, that
> are not there in the architecture I propose are:
> - when the designers want to change the discrete Coordination behaviour of
> their control component, they should be able to do that by looking at
> only one single place, namely the Coordination FSM. (And not in every event
> handler that the component might be subscribed to.)
> - the controller might want to know how many times it has already been
> receiving data in time, or how many times it has already missed data,
> etc. This bookkeeping (and the possible decision making around it) belongs
> in the controller component, and not in the event handler.
I can do the decision making in the UpdateHook() (based on the flag
set in the watchdog event method), but then still this UpdateHook()
will get called with every watchdog trigger, which is still unneeded.
I could add some extra variables to keep track of why UpdateHook()
gets called and let it do nothing if the watchdog method called it
(and no ControlMode change is needed) (=> this would be the decision
making), but it looks like a lot of overhead to me, considering the
original problem?
Alternatively, I can remove the separate Event triggered methods and
check them all in UpdateHook() and take appropriate actions there? But
I actually like the fact of making seperate methods for every
EventPort.
I know there are various solutions, just wondering which is the best one...
>
>> I know it's not a terrible thing UpdateHook() get's called here as
>> well, but it makes the watchdog pretty intrusive, which is not how it
>> should be.
>
> What do you mean with "pretty intrusive"? And watchdogs _should_ be
> "intrusive" since that's the key essence of their existence :-)
It should monitor, in this case, the measurement update frequency, but
as long as everything goes well, it's influence should be as minimal
as possible (only the EventPort method execution). It should only make
it's presence felt the moment the measurements go wrong.
Steven
>
>> Regards,
>>
>> Steven
>
> Herman
EventPort with custom method calls updateHook
> >>>>
> >>>> I'm building a component using several EventPorts (toolchain-2.3).
> >>>> I've made custom methods for all of them, so as to clearly monitor
> >>>> which port received an update.
> >>>> Apparently (I just found out in the documentation), the EventPort will
> >>>> not only trigger my custom method, but also execute the component's
> >>>> UpdateHook() afterwards. What's the reasoning behind calling
> >>>> UpdateHook() here?
> >>>
> >>> Events are _the_ mechanism for asynchronous Coordination, that means
> >>> that it is in their semantics to allow the receiving component to
> >>> react to an event.
> >>>
> >>>> As I wrote my own method, I didn't expect the UpdateHook() getting
> >>>> executed as well.
> >>>
> >>> The semantics is exactly that of an interrupt service in Operating
> >>> Systems: - the event handling (= your method) does the minimally
> >>> required data handling (typically, setting/getting some parameters);
> >>> - the Component is woken up to give it the opportunity to do its thing
> >>> with the newly set parameters.
> >>>
> >>> In case you do the latter inside the former, you are making a
> >>> separation of concerns violation: the event handler should not know
> >>> about what the Component it is attached to will do with the event.
> >>>
> >>>> This is however good behaviour for some of my ports (I was calling
> >>>> UpdateHook manually anyway), but surely not for all. Is there a way I
> >>>> can disable calling it?
> >>>
> >>> What would be the use case in which a Component receives an event, but
> >>> does not get the chance to do something with it?
> >>
> >> The component involved is a pose controller component, receiving
> >> current pose measurements and a goal pose and outputting control
> >> signals (it's also accepting goal velocities, but that's not relevant
> >> here).
> >> The methods connected to these EventPorts read in the new values each
> >> time a new measurement or goal is received => after these methods I do
> >> want UpdateHook() to execute to update the control signals.
> >
> > Yes, that's indeed the semantically intended behaviour of an event.
> >
> >> To monitor whether new measurements are received in time, I hooked up
> >> the controller component to a TimerComponent and implemented a
> >> watchdog (which get's executed every time the TimerComponent triggers
> >> the watchdog EventPort). If no new measurements are received withing
> >> e.g. 0.1s, the ControlMode is changed. So for this method I had in
> >> mind:
> >> - if no new measurements are received in time - change the controlMode
> >> => now I want updateHook to be called of course.
> >> - as long as new measurements are received in time - don't do anything
> >> => don't call the updateHook here, as nor the measurements nor the
> >> goal state have changed.
> >
> > The _responsibility_ to change or not change belongs to the _controller
> > component_ (and most probably, to its Coordination state machine), not to
> > the event handler! The way you do it now is a violation of the "5Cs"
> > separation of concerns. Some potential problems with your approach, that
> > are not there in the architecture I propose are:
> > - when the designers want to change the discrete Coordination behaviour
> > of their control component, they should be able to do that by looking at
> > only one single place, namely the Coordination FSM. (And not in every
> > event handler that the component might be subscribed to.)
> > - the controller might want to know how many times it has already been
> > receiving data in time, or how many times it has already missed data,
> > etc. This bookkeeping (and the possible decision making around it)
> > belongs in the controller component, and not in the event handler.
>
> I can do the decision making in the UpdateHook() (based on the flag
> set in the watchdog event method), but then still this UpdateHook()
> will get called with every watchdog trigger, which is still unneeded.
> I could add some extra variables to keep track of why UpdateHook()
> gets called and let it do nothing if the watchdog method called it
> (and no ControlMode change is needed) (=> this would be the decision
> making), but it looks like a lot of overhead to me, considering the
> original problem?
>
> Alternatively, I can remove the separate Event triggered methods and
> check them all in UpdateHook() and take appropriate actions there? But
> I actually like the fact of making seperate methods for every
> EventPort.
> I know there are various solutions, just wondering which is the best one...
Personnaly, I prefer the second approach ....
I always map different event ports to their own specific function (the that
implements the way the component should react to the event). Personnally, I
always leave the UpdateHook empty, but nevertheless I didn't expect it to be
called after receiving an event!
>From my point of view this is unwanted (and undocumented?) behaviour.
I don't preferto to the checking myself in the UpdateHook since from my point
of view, this is just meaning double work. There is a direct means to bind the
event to his own function, so why should I bind it to a general one
(UpdateHook) and check there what caused the entry of the UpdateHook ....
If there is a part of the function that would have to be executed by all the
function raised by the events, I would implement a separate function (not the
UpdateHook) and call this function within the functions bind by to the events
....
So I don't see the need for executing the UpdateHook after every function
triggered by an event ..
Tinne
EventPort with custom method calls updateHook
> >>>>
> >>>> I'm building a component using several EventPorts (toolchain-2.3).
> >>>> I've made custom methods for all of them, so as to clearly monitor
> >>>> which port received an update.
> >>>> Apparently (I just found out in the documentation), the EventPort will
> >>>> not only trigger my custom method, but also execute the component's
> >>>> UpdateHook() afterwards. What's the reasoning behind calling
> >>>> UpdateHook() here?
> >>>
> >>> Events are _the_ mechanism for asynchronous Coordination, that means
> >>> that it is in their semantics to allow the receiving component to
> >>> react to an event.
> >>>
> >>>> As I wrote my own method, I didn't expect the UpdateHook() getting
> >>>> executed as well.
> >>>
> >>> The semantics is exactly that of an interrupt service in Operating
> >>> Systems: - the event handling (= your method) does the minimally
> >>> required data handling (typically, setting/getting some parameters);
> >>> - the Component is woken up to give it the opportunity to do its thing
> >>> with the newly set parameters.
> >>>
> >>> In case you do the latter inside the former, you are making a
> >>> separation of concerns violation: the event handler should not know
> >>> about what the Component it is attached to will do with the event.
> >>>
> >>>> This is however good behaviour for some of my ports (I was calling
> >>>> UpdateHook manually anyway), but surely not for all. Is there a way I
> >>>> can disable calling it?
> >>>
> >>> What would be the use case in which a Component receives an event, but
> >>> does not get the chance to do something with it?
> >>
> >> The component involved is a pose controller component, receiving
> >> current pose measurements and a goal pose and outputting control
> >> signals (it's also accepting goal velocities, but that's not relevant
> >> here).
> >> The methods connected to these EventPorts read in the new values each
> >> time a new measurement or goal is received => after these methods I do
> >> want UpdateHook() to execute to update the control signals.
> >
> > Yes, that's indeed the semantically intended behaviour of an event.
> >
> >> To monitor whether new measurements are received in time, I hooked up
> >> the controller component to a TimerComponent and implemented a
> >> watchdog (which get's executed every time the TimerComponent triggers
> >> the watchdog EventPort). If no new measurements are received withing
> >> e.g. 0.1s, the ControlMode is changed. So for this method I had in
> >> mind:
> >> - if no new measurements are received in time - change the controlMode
> >> => now I want updateHook to be called of course.
> >> - as long as new measurements are received in time - don't do anything
> >> => don't call the updateHook here, as nor the measurements nor the
> >> goal state have changed.
> >
> > The _responsibility_ to change or not change belongs to the _controller
> > component_ (and most probably, to its Coordination state machine), not to
> > the event handler! The way you do it now is a violation of the "5Cs"
> > separation of concerns. Some potential problems with your approach, that
> > are not there in the architecture I propose are:
> > - when the designers want to change the discrete Coordination behaviour
> > of their control component, they should be able to do that by looking at
> > only one single place, namely the Coordination FSM. (And not in every
> > event handler that the component might be subscribed to.)
> > - the controller might want to know how many times it has already been
> > receiving data in time, or how many times it has already missed data,
> > etc. This bookkeeping (and the possible decision making around it)
> > belongs in the controller component, and not in the event handler.
>
> I can do the decision making in the UpdateHook() (based on the flag
> set in the watchdog event method), but then still this UpdateHook()
> will get called with every watchdog trigger, which is still unneeded.
> I could add some extra variables to keep track of why UpdateHook()
> gets called and let it do nothing if the watchdog method called it
> (and no ControlMode change is needed) (=> this would be the decision
> making), but it looks like a lot of overhead to me, considering the
> original problem?
>
> Alternatively, I can remove the separate Event triggered methods and
> check them all in UpdateHook() and take appropriate actions there? But
> I actually like the fact of making seperate methods for every
> EventPort.
> I know there are various solutions, just wondering which is the best one...
Personnaly, I prefer the second approach ....
I always map different event ports to their own specific function (the that
implements the way the component should react to the event). Personnally, I
always leave the UpdateHook empty, but nevertheless I didn't expect it to be
called after receiving an event!
>From my point of view this is unwanted (and undocumented?) behaviour.
I don't preferto to the checking myself in the UpdateHook since from my point
of view, this is just meaning double work. There is a direct means to bind the
event to his own function, so why should I bind it to a general one
(UpdateHook) and check there what caused the entry of the UpdateHook ....
If there is a part of the function that would have to be executed by all the
function raised by the events, I would implement a separate function (not the
UpdateHook) and call this function within the functions bind by to the events
....
So I don't see the need for executing the UpdateHook after every function
triggered by an event ..
Tinne
EventPort with custom method calls updateHook
On Monday 21 March 2011 11:33:14 Tinne De Laet wrote:
> > >>>> I'm building a component using several EventPorts (toolchain-2.3).
> > >>>> I've made custom methods for all of them, so as to clearly monitor
> > >>>> which port received an update.
> > >>>> Apparently (I just found out in the documentation), the EventPort
> > >>>> will not only trigger my custom method, but also execute the
> > >>>> component's UpdateHook() afterwards. What's the reasoning behind
> > >>>> calling UpdateHook() here?
> > >>>
> > >>> Events are _the_ mechanism for asynchronous Coordination, that means
> > >>> that it is in their semantics to allow the receiving component to
> > >>> react to an event.
> > >>>
> > >>>> As I wrote my own method, I didn't expect the UpdateHook() getting
> > >>>> executed as well.
> > >>>
> > >>> The semantics is exactly that of an interrupt service in Operating
> > >>> Systems: - the event handling (= your method) does the minimally
> > >>> required data handling (typically, setting/getting some parameters);
> > >>> - the Component is woken up to give it the opportunity to do its
> > >>> thing with the newly set parameters.
> > >>>
> > >>> In case you do the latter inside the former, you are making a
> > >>> separation of concerns violation: the event handler should not know
> > >>> about what the Component it is attached to will do with the event.
> > >>>
> > >>>> This is however good behaviour for some of my ports (I was calling
> > >>>> UpdateHook manually anyway), but surely not for all. Is there a way
> > >>>> I can disable calling it?
> > >>>
> > >>> What would be the use case in which a Component receives an event,
> > >>> but does not get the chance to do something with it?
> > >>
> > >> The component involved is a pose controller component, receiving
> > >> current pose measurements and a goal pose and outputting control
> > >> signals (it's also accepting goal velocities, but that's not relevant
> > >> here).
> > >> The methods connected to these EventPorts read in the new values each
> > >> time a new measurement or goal is received => after these methods I do
> > >> want UpdateHook() to execute to update the control signals.
> > >
> > > Yes, that's indeed the semantically intended behaviour of an event.
> > >
> > >> To monitor whether new measurements are received in time, I hooked up
> > >> the controller component to a TimerComponent and implemented a
> > >> watchdog (which get's executed every time the TimerComponent triggers
> > >> the watchdog EventPort). If no new measurements are received withing
> > >> e.g. 0.1s, the ControlMode is changed. So for this method I had in
> > >> mind:
> > >> - if no new measurements are received in time - change the controlMode
> > >> => now I want updateHook to be called of course.
> > >> - as long as new measurements are received in time - don't do anything
> > >> => don't call the updateHook here, as nor the measurements nor the
> > >> goal state have changed.
> > >
> > > The _responsibility_ to change or not change belongs to the _controller
> > > component_ (and most probably, to its Coordination state machine), not
> > > to the event handler! The way you do it now is a violation of the
> > > "5Cs" separation of concerns. Some potential problems with your
> > > approach, that are not there in the architecture I propose are:
> > > - when the designers want to change the discrete Coordination behaviour
> > > of their control component, they should be able to do that by looking
> > > at only one single place, namely the Coordination FSM. (And not in
> > > every event handler that the component might be subscribed to.)
> > > - the controller might want to know how many times it has already been
> > >
> > > receiving data in time, or how many times it has already missed data,
> > > etc. This bookkeeping (and the possible decision making around it)
> > >
> > > belongs in the controller component, and not in the event handler.
> >
> > I can do the decision making in the UpdateHook() (based on the flag
> > set in the watchdog event method), but then still this UpdateHook()
> > will get called with every watchdog trigger, which is still unneeded.
> > I could add some extra variables to keep track of why UpdateHook()
> > gets called and let it do nothing if the watchdog method called it
> > (and no ControlMode change is needed) (=> this would be the decision
> > making), but it looks like a lot of overhead to me, considering the
> > original problem?
> >
> > Alternatively, I can remove the separate Event triggered methods and
> > check them all in UpdateHook() and take appropriate actions there? But
> > I actually like the fact of making seperate methods for every
> > EventPort.
> >
> > I know there are various solutions, just wondering which is the best
> > one...
>
> Personnaly, I prefer the second approach ....
> I always map different event ports to their own specific function (the that
> implements the way the component should react to the event). Personnally, I
> always leave the UpdateHook empty, but nevertheless I didn't expect it to
> be called after receiving an event!
>
> >From my point of view this is unwanted (and undocumented?) behaviour.
>
> I don't preferto to the checking myself in the UpdateHook since from my
> point of view, this is just meaning double work. There is a direct means
> to bind the event to his own function, so why should I bind it to a
> general one (UpdateHook) and check there what caused the entry of the
> UpdateHook .... If there is a part of the function that would have to be
> executed by all the function raised by the events, I would implement a
> separate function (not the UpdateHook) and call this function within the
> functions bind by to the events ....
> So I don't see the need for executing the UpdateHook after every function
> triggered by an event ..
I agree with Tinne's scheme to use updateHook() as little as possible. For the
record: each time the component's 'thread' is triggered to execute, for
whatever reason, updateHook() is called. So the problem is, you don't know
*why* updateHook() was called, you only know that the component's thread woke
up to do some work (process a script, data on event port etc.) If you have
some lengthy calculation done in there, you might have a bottleneck.
I don't think it's wise to change the behavior of updateHook(), since this
would break many components, relying on the being-called-whenever-xyz.
What is probably lacking is a mechanism similar to 'state update' and 'output
update' which has been proposed by others on this list before. Since we are
in a 'components for control' framework, I'm open to such an extension, but it
would require broad consensus, since it will add again a new concept to learn.
>
>
> Tinne
Peter
EventPort with custom method calls updateHook
On Monday 21 March 2011 11:33:14 Tinne De Laet wrote:
> > >>>> I'm building a component using several EventPorts (toolchain-2.3).
> > >>>> I've made custom methods for all of them, so as to clearly monitor
> > >>>> which port received an update.
> > >>>> Apparently (I just found out in the documentation), the EventPort
> > >>>> will not only trigger my custom method, but also execute the
> > >>>> component's UpdateHook() afterwards. What's the reasoning behind
> > >>>> calling UpdateHook() here?
> > >>>
> > >>> Events are _the_ mechanism for asynchronous Coordination, that means
> > >>> that it is in their semantics to allow the receiving component to
> > >>> react to an event.
> > >>>
> > >>>> As I wrote my own method, I didn't expect the UpdateHook() getting
> > >>>> executed as well.
> > >>>
> > >>> The semantics is exactly that of an interrupt service in Operating
> > >>> Systems: - the event handling (= your method) does the minimally
> > >>> required data handling (typically, setting/getting some parameters);
> > >>> - the Component is woken up to give it the opportunity to do its
> > >>> thing with the newly set parameters.
> > >>>
> > >>> In case you do the latter inside the former, you are making a
> > >>> separation of concerns violation: the event handler should not know
> > >>> about what the Component it is attached to will do with the event.
> > >>>
> > >>>> This is however good behaviour for some of my ports (I was calling
> > >>>> UpdateHook manually anyway), but surely not for all. Is there a way
> > >>>> I can disable calling it?
> > >>>
> > >>> What would be the use case in which a Component receives an event,
> > >>> but does not get the chance to do something with it?
> > >>
> > >> The component involved is a pose controller component, receiving
> > >> current pose measurements and a goal pose and outputting control
> > >> signals (it's also accepting goal velocities, but that's not relevant
> > >> here).
> > >> The methods connected to these EventPorts read in the new values each
> > >> time a new measurement or goal is received => after these methods I do
> > >> want UpdateHook() to execute to update the control signals.
> > >
> > > Yes, that's indeed the semantically intended behaviour of an event.
> > >
> > >> To monitor whether new measurements are received in time, I hooked up
> > >> the controller component to a TimerComponent and implemented a
> > >> watchdog (which get's executed every time the TimerComponent triggers
> > >> the watchdog EventPort). If no new measurements are received withing
> > >> e.g. 0.1s, the ControlMode is changed. So for this method I had in
> > >> mind:
> > >> - if no new measurements are received in time - change the controlMode
> > >> => now I want updateHook to be called of course.
> > >> - as long as new measurements are received in time - don't do anything
> > >> => don't call the updateHook here, as nor the measurements nor the
> > >> goal state have changed.
> > >
> > > The _responsibility_ to change or not change belongs to the _controller
> > > component_ (and most probably, to its Coordination state machine), not
> > > to the event handler! The way you do it now is a violation of the
> > > "5Cs" separation of concerns. Some potential problems with your
> > > approach, that are not there in the architecture I propose are:
> > > - when the designers want to change the discrete Coordination behaviour
> > > of their control component, they should be able to do that by looking
> > > at only one single place, namely the Coordination FSM. (And not in
> > > every event handler that the component might be subscribed to.)
> > > - the controller might want to know how many times it has already been
> > >
> > > receiving data in time, or how many times it has already missed data,
> > > etc. This bookkeeping (and the possible decision making around it)
> > >
> > > belongs in the controller component, and not in the event handler.
> >
> > I can do the decision making in the UpdateHook() (based on the flag
> > set in the watchdog event method), but then still this UpdateHook()
> > will get called with every watchdog trigger, which is still unneeded.
> > I could add some extra variables to keep track of why UpdateHook()
> > gets called and let it do nothing if the watchdog method called it
> > (and no ControlMode change is needed) (=> this would be the decision
> > making), but it looks like a lot of overhead to me, considering the
> > original problem?
> >
> > Alternatively, I can remove the separate Event triggered methods and
> > check them all in UpdateHook() and take appropriate actions there? But
> > I actually like the fact of making seperate methods for every
> > EventPort.
> >
> > I know there are various solutions, just wondering which is the best
> > one...
>
> Personnaly, I prefer the second approach ....
> I always map different event ports to their own specific function (the that
> implements the way the component should react to the event). Personnally, I
> always leave the UpdateHook empty, but nevertheless I didn't expect it to
> be called after receiving an event!
>
> >From my point of view this is unwanted (and undocumented?) behaviour.
>
> I don't preferto to the checking myself in the UpdateHook since from my
> point of view, this is just meaning double work. There is a direct means
> to bind the event to his own function, so why should I bind it to a
> general one (UpdateHook) and check there what caused the entry of the
> UpdateHook .... If there is a part of the function that would have to be
> executed by all the function raised by the events, I would implement a
> separate function (not the UpdateHook) and call this function within the
> functions bind by to the events ....
> So I don't see the need for executing the UpdateHook after every function
> triggered by an event ..
I agree with Tinne's scheme to use updateHook() as little as possible. For the
record: each time the component's 'thread' is triggered to execute, for
whatever reason, updateHook() is called. So the problem is, you don't know
*why* updateHook() was called, you only know that the component's thread woke
up to do some work (process a script, data on event port etc.) If you have
some lengthy calculation done in there, you might have a bottleneck.
I don't think it's wise to change the behavior of updateHook(), since this
would break many components, relying on the being-called-whenever-xyz.
What is probably lacking is a mechanism similar to 'state update' and 'output
update' which has been proposed by others on this list before. Since we are
in a 'components for control' framework, I'm open to such an extension, but it
would require broad consensus, since it will add again a new concept to learn.
>
>
> Tinne
Peter
EventPort with custom method calls updateHook
On Monday 21 March 2011 11:33:14 Tinne De Laet wrote:
> > >>>> I'm building a component using several EventPorts (toolchain-2.3).
> > >>>> I've made custom methods for all of them, so as to clearly monitor
> > >>>> which port received an update.
> > >>>> Apparently (I just found out in the documentation), the EventPort
> > >>>> will not only trigger my custom method, but also execute the
> > >>>> component's UpdateHook() afterwards. What's the reasoning behind
> > >>>> calling UpdateHook() here?
> > >>>
> > >>> Events are _the_ mechanism for asynchronous Coordination, that means
> > >>> that it is in their semantics to allow the receiving component to
> > >>> react to an event.
> > >>>
> > >>>> As I wrote my own method, I didn't expect the UpdateHook() getting
> > >>>> executed as well.
> > >>>
> > >>> The semantics is exactly that of an interrupt service in Operating
> > >>> Systems: - the event handling (= your method) does the minimally
> > >>> required data handling (typically, setting/getting some parameters);
> > >>> - the Component is woken up to give it the opportunity to do its
> > >>> thing with the newly set parameters.
> > >>>
> > >>> In case you do the latter inside the former, you are making a
> > >>> separation of concerns violation: the event handler should not know
> > >>> about what the Component it is attached to will do with the event.
> > >>>
> > >>>> This is however good behaviour for some of my ports (I was calling
> > >>>> UpdateHook manually anyway), but surely not for all. Is there a way
> > >>>> I can disable calling it?
> > >>>
> > >>> What would be the use case in which a Component receives an event,
> > >>> but does not get the chance to do something with it?
> > >>
> > >> The component involved is a pose controller component, receiving
> > >> current pose measurements and a goal pose and outputting control
> > >> signals (it's also accepting goal velocities, but that's not relevant
> > >> here).
> > >> The methods connected to these EventPorts read in the new values each
> > >> time a new measurement or goal is received => after these methods I do
> > >> want UpdateHook() to execute to update the control signals.
> > >
> > > Yes, that's indeed the semantically intended behaviour of an event.
> > >
> > >> To monitor whether new measurements are received in time, I hooked up
> > >> the controller component to a TimerComponent and implemented a
> > >> watchdog (which get's executed every time the TimerComponent triggers
> > >> the watchdog EventPort). If no new measurements are received withing
> > >> e.g. 0.1s, the ControlMode is changed. So for this method I had in
> > >> mind:
> > >> - if no new measurements are received in time - change the controlMode
> > >> => now I want updateHook to be called of course.
> > >> - as long as new measurements are received in time - don't do anything
> > >> => don't call the updateHook here, as nor the measurements nor the
> > >> goal state have changed.
> > >
> > > The _responsibility_ to change or not change belongs to the _controller
> > > component_ (and most probably, to its Coordination state machine), not
> > > to the event handler! The way you do it now is a violation of the
> > > "5Cs" separation of concerns. Some potential problems with your
> > > approach, that are not there in the architecture I propose are:
> > > - when the designers want to change the discrete Coordination behaviour
> > > of their control component, they should be able to do that by looking
> > > at only one single place, namely the Coordination FSM. (And not in
> > > every event handler that the component might be subscribed to.)
> > > - the controller might want to know how many times it has already been
> > >
> > > receiving data in time, or how many times it has already missed data,
> > > etc. This bookkeeping (and the possible decision making around it)
> > >
> > > belongs in the controller component, and not in the event handler.
> >
> > I can do the decision making in the UpdateHook() (based on the flag
> > set in the watchdog event method), but then still this UpdateHook()
> > will get called with every watchdog trigger, which is still unneeded.
> > I could add some extra variables to keep track of why UpdateHook()
> > gets called and let it do nothing if the watchdog method called it
> > (and no ControlMode change is needed) (=> this would be the decision
> > making), but it looks like a lot of overhead to me, considering the
> > original problem?
> >
> > Alternatively, I can remove the separate Event triggered methods and
> > check them all in UpdateHook() and take appropriate actions there? But
> > I actually like the fact of making seperate methods for every
> > EventPort.
> >
> > I know there are various solutions, just wondering which is the best
> > one...
>
> Personnaly, I prefer the second approach ....
> I always map different event ports to their own specific function (the that
> implements the way the component should react to the event). Personnally, I
> always leave the UpdateHook empty, but nevertheless I didn't expect it to
> be called after receiving an event!
>
> >From my point of view this is unwanted (and undocumented?) behaviour.
>
> I don't preferto to the checking myself in the UpdateHook since from my
> point of view, this is just meaning double work. There is a direct means
> to bind the event to his own function, so why should I bind it to a
> general one (UpdateHook) and check there what caused the entry of the
> UpdateHook .... If there is a part of the function that would have to be
> executed by all the function raised by the events, I would implement a
> separate function (not the UpdateHook) and call this function within the
> functions bind by to the events ....
> So I don't see the need for executing the UpdateHook after every function
> triggered by an event ..
I agree with Tinne's scheme to use updateHook() as little as possible. For the
record: each time the component's 'thread' is triggered to execute, for
whatever reason, updateHook() is called. So the problem is, you don't know
*why* updateHook() was called, you only know that the component's thread woke
up to do some work (process a script, data on event port etc.) If you have
some lengthy calculation done in there, you might have a bottleneck.
I don't think it's wise to change the behavior of updateHook(), since this
would break many components, relying on the being-called-whenever-xyz.
What is probably lacking is a mechanism similar to 'state update' and 'output
update' which has been proposed by others on this list before. Since we are
in a 'components for control' framework, I'm open to such an extension, but it
would require broad consensus, since it will add again a new concept to learn.
>
>
> Tinne
Peter
EventPort with custom method calls updateHook
On Thu, 24 Mar 2011, Peter Soetens wrote:
> On Monday 21 March 2011 11:33:14 Tinne De Laet wrote:
>>>>>>> I'm building a component using several EventPorts (toolchain-2.3).
>>>>>>> I've made custom methods for all of them, so as to clearly monitor
>>>>>>> which port received an update.
>>>>>>> Apparently (I just found out in the documentation), the EventPort
>>>>>>> will not only trigger my custom method, but also execute the
>>>>>>> component's UpdateHook() afterwards. What's the reasoning behind
>>>>>>> calling UpdateHook() here?
>>>>>>
>>>>>> Events are _the_ mechanism for asynchronous Coordination, that means
>>>>>> that it is in their semantics to allow the receiving component to
>>>>>> react to an event.
>>>>>>
>>>>>>> As I wrote my own method, I didn't expect the UpdateHook() getting
>>>>>>> executed as well.
>>>>>>
>>>>>> The semantics is exactly that of an interrupt service in Operating
>>>>>> Systems: - the event handling (= your method) does the minimally
>>>>>> required data handling (typically, setting/getting some parameters);
>>>>>> - the Component is woken up to give it the opportunity to do its
>>>>>> thing with the newly set parameters.
>>>>>>
>>>>>> In case you do the latter inside the former, you are making a
>>>>>> separation of concerns violation: the event handler should not know
>>>>>> about what the Component it is attached to will do with the event.
>>>>>>
>>>>>>> This is however good behaviour for some of my ports (I was calling
>>>>>>> UpdateHook manually anyway), but surely not for all. Is there a way
>>>>>>> I can disable calling it?
>>>>>>
>>>>>> What would be the use case in which a Component receives an event,
>>>>>> but does not get the chance to do something with it?
>>>>>
>>>>> The component involved is a pose controller component, receiving
>>>>> current pose measurements and a goal pose and outputting control
>>>>> signals (it's also accepting goal velocities, but that's not relevant
>>>>> here).
>>>>> The methods connected to these EventPorts read in the new values each
>>>>> time a new measurement or goal is received => after these methods I do
>>>>> want UpdateHook() to execute to update the control signals.
>>>>
>>>> Yes, that's indeed the semantically intended behaviour of an event.
>>>>
>>>>> To monitor whether new measurements are received in time, I hooked up
>>>>> the controller component to a TimerComponent and implemented a
>>>>> watchdog (which get's executed every time the TimerComponent triggers
>>>>> the watchdog EventPort). If no new measurements are received withing
>>>>> e.g. 0.1s, the ControlMode is changed. So for this method I had in
>>>>> mind:
>>>>> - if no new measurements are received in time - change the controlMode
>>>>> => now I want updateHook to be called of course.
>>>>> - as long as new measurements are received in time - don't do anything
>>>>> => don't call the updateHook here, as nor the measurements nor the
>>>>> goal state have changed.
>>>>
>>>> The _responsibility_ to change or not change belongs to the _controller
>>>> component_ (and most probably, to its Coordination state machine), not
>>>> to the event handler! The way you do it now is a violation of the
>>>> "5Cs" separation of concerns. Some potential problems with your
>>>> approach, that are not there in the architecture I propose are:
>>>> - when the designers want to change the discrete Coordination behaviour
>>>> of their control component, they should be able to do that by looking
>>>> at only one single place, namely the Coordination FSM. (And not in
>>>> every event handler that the component might be subscribed to.)
>>>> - the controller might want to know how many times it has already been
>>>>
>>>> receiving data in time, or how many times it has already missed data,
>>>> etc. This bookkeeping (and the possible decision making around it)
>>>>
>>>> belongs in the controller component, and not in the event handler.
>>>
>>> I can do the decision making in the UpdateHook() (based on the flag
>>> set in the watchdog event method), but then still this UpdateHook()
>>> will get called with every watchdog trigger, which is still unneeded.
>>> I could add some extra variables to keep track of why UpdateHook()
>>> gets called and let it do nothing if the watchdog method called it
>>> (and no ControlMode change is needed) (=> this would be the decision
>>> making), but it looks like a lot of overhead to me, considering the
>>> original problem?
>>>
>>> Alternatively, I can remove the separate Event triggered methods and
>>> check them all in UpdateHook() and take appropriate actions there? But
>>> I actually like the fact of making seperate methods for every
>>> EventPort.
>>>
>>> I know there are various solutions, just wondering which is the best
>>> one...
>>
>> Personnaly, I prefer the second approach ....
>> I always map different event ports to their own specific function (the that
>> implements the way the component should react to the event). Personnally, I
>> always leave the UpdateHook empty, but nevertheless I didn't expect it to
>> be called after receiving an event!
>>
>>> From my point of view this is unwanted (and undocumented?) behaviour.
>>
>> I don't preferto to the checking myself in the UpdateHook since from my
>> point of view, this is just meaning double work. There is a direct means
>> to bind the event to his own function, so why should I bind it to a
>> general one (UpdateHook) and check there what caused the entry of the
>> UpdateHook .... If there is a part of the function that would have to be
>> executed by all the function raised by the events, I would implement a
>> separate function (not the UpdateHook) and call this function within the
>> functions bind by to the events ....
>> So I don't see the need for executing the UpdateHook after every function
>> triggered by an event ..
>
> I agree with Tinne's scheme to use updateHook() as little as possible. For the
> record: each time the component's 'thread' is triggered to execute, for
> whatever reason, updateHook() is called.
Which is the intended behaviour :-)
> So the problem is, you don't know *why* updateHook() was called,
Providing this information (and nothing more) is the job of the "event
handler".
> you only know that the component's thread woke
> up to do some work (process a script, data on event port etc.) If you have
> some lengthy calculation done in there, you might have a bottleneck.
>
> I don't think it's wise to change the behavior of updateHook(), since this
> would break many components, relying on the being-called-whenever-xyz.
>
> What is probably lacking is a mechanism similar to 'state update' and 'output
> update' which has been proposed by others on this list before. Since we are
> in a 'components for control' framework, I'm open to such an extension, but it
> would require broad consensus, since it will add again a new concept to learn.
What exactly would be the semantics of this new primitive?
Herman
EventPort with custom method calls updateHook
On Thu, 24 Mar 2011, Peter Soetens wrote:
> On Monday 21 March 2011 11:33:14 Tinne De Laet wrote:
>>>>>>> I'm building a component using several EventPorts (toolchain-2.3).
>>>>>>> I've made custom methods for all of them, so as to clearly monitor
>>>>>>> which port received an update.
>>>>>>> Apparently (I just found out in the documentation), the EventPort
>>>>>>> will not only trigger my custom method, but also execute the
>>>>>>> component's UpdateHook() afterwards. What's the reasoning behind
>>>>>>> calling UpdateHook() here?
>>>>>>
>>>>>> Events are _the_ mechanism for asynchronous Coordination, that means
>>>>>> that it is in their semantics to allow the receiving component to
>>>>>> react to an event.
>>>>>>
>>>>>>> As I wrote my own method, I didn't expect the UpdateHook() getting
>>>>>>> executed as well.
>>>>>>
>>>>>> The semantics is exactly that of an interrupt service in Operating
>>>>>> Systems: - the event handling (= your method) does the minimally
>>>>>> required data handling (typically, setting/getting some parameters);
>>>>>> - the Component is woken up to give it the opportunity to do its
>>>>>> thing with the newly set parameters.
>>>>>>
>>>>>> In case you do the latter inside the former, you are making a
>>>>>> separation of concerns violation: the event handler should not know
>>>>>> about what the Component it is attached to will do with the event.
>>>>>>
>>>>>>> This is however good behaviour for some of my ports (I was calling
>>>>>>> UpdateHook manually anyway), but surely not for all. Is there a way
>>>>>>> I can disable calling it?
>>>>>>
>>>>>> What would be the use case in which a Component receives an event,
>>>>>> but does not get the chance to do something with it?
>>>>>
>>>>> The component involved is a pose controller component, receiving
>>>>> current pose measurements and a goal pose and outputting control
>>>>> signals (it's also accepting goal velocities, but that's not relevant
>>>>> here).
>>>>> The methods connected to these EventPorts read in the new values each
>>>>> time a new measurement or goal is received => after these methods I do
>>>>> want UpdateHook() to execute to update the control signals.
>>>>
>>>> Yes, that's indeed the semantically intended behaviour of an event.
>>>>
>>>>> To monitor whether new measurements are received in time, I hooked up
>>>>> the controller component to a TimerComponent and implemented a
>>>>> watchdog (which get's executed every time the TimerComponent triggers
>>>>> the watchdog EventPort). If no new measurements are received withing
>>>>> e.g. 0.1s, the ControlMode is changed. So for this method I had in
>>>>> mind:
>>>>> - if no new measurements are received in time - change the controlMode
>>>>> => now I want updateHook to be called of course.
>>>>> - as long as new measurements are received in time - don't do anything
>>>>> => don't call the updateHook here, as nor the measurements nor the
>>>>> goal state have changed.
>>>>
>>>> The _responsibility_ to change or not change belongs to the _controller
>>>> component_ (and most probably, to its Coordination state machine), not
>>>> to the event handler! The way you do it now is a violation of the
>>>> "5Cs" separation of concerns. Some potential problems with your
>>>> approach, that are not there in the architecture I propose are:
>>>> - when the designers want to change the discrete Coordination behaviour
>>>> of their control component, they should be able to do that by looking
>>>> at only one single place, namely the Coordination FSM. (And not in
>>>> every event handler that the component might be subscribed to.)
>>>> - the controller might want to know how many times it has already been
>>>>
>>>> receiving data in time, or how many times it has already missed data,
>>>> etc. This bookkeeping (and the possible decision making around it)
>>>>
>>>> belongs in the controller component, and not in the event handler.
>>>
>>> I can do the decision making in the UpdateHook() (based on the flag
>>> set in the watchdog event method), but then still this UpdateHook()
>>> will get called with every watchdog trigger, which is still unneeded.
>>> I could add some extra variables to keep track of why UpdateHook()
>>> gets called and let it do nothing if the watchdog method called it
>>> (and no ControlMode change is needed) (=> this would be the decision
>>> making), but it looks like a lot of overhead to me, considering the
>>> original problem?
>>>
>>> Alternatively, I can remove the separate Event triggered methods and
>>> check them all in UpdateHook() and take appropriate actions there? But
>>> I actually like the fact of making seperate methods for every
>>> EventPort.
>>>
>>> I know there are various solutions, just wondering which is the best
>>> one...
>>
>> Personnaly, I prefer the second approach ....
>> I always map different event ports to their own specific function (the that
>> implements the way the component should react to the event). Personnally, I
>> always leave the UpdateHook empty, but nevertheless I didn't expect it to
>> be called after receiving an event!
>>
>>> From my point of view this is unwanted (and undocumented?) behaviour.
>>
>> I don't preferto to the checking myself in the UpdateHook since from my
>> point of view, this is just meaning double work. There is a direct means
>> to bind the event to his own function, so why should I bind it to a
>> general one (UpdateHook) and check there what caused the entry of the
>> UpdateHook .... If there is a part of the function that would have to be
>> executed by all the function raised by the events, I would implement a
>> separate function (not the UpdateHook) and call this function within the
>> functions bind by to the events ....
>> So I don't see the need for executing the UpdateHook after every function
>> triggered by an event ..
>
> I agree with Tinne's scheme to use updateHook() as little as possible. For the
> record: each time the component's 'thread' is triggered to execute, for
> whatever reason, updateHook() is called.
Which is the intended behaviour :-)
> So the problem is, you don't know *why* updateHook() was called,
Providing this information (and nothing more) is the job of the "event
handler".
> you only know that the component's thread woke
> up to do some work (process a script, data on event port etc.) If you have
> some lengthy calculation done in there, you might have a bottleneck.
>
> I don't think it's wise to change the behavior of updateHook(), since this
> would break many components, relying on the being-called-whenever-xyz.
>
> What is probably lacking is a mechanism similar to 'state update' and 'output
> update' which has been proposed by others on this list before. Since we are
> in a 'components for control' framework, I'm open to such an extension, but it
> would require broad consensus, since it will add again a new concept to learn.
What exactly would be the semantics of this new primitive?
Herman
EventPort with custom method calls updateHook
On Friday 25 March 2011 07:45:30 Herman Bruyninckx wrote:
> On Thu, 24 Mar 2011, Peter Soetens wrote:
> > On Monday 21 March 2011 11:33:14 Tinne De Laet wrote:
> >>>>>>> I'm building a component using several EventPorts (toolchain-2.3).
> >>>>>>> I've made custom methods for all of them, so as to clearly monitor
> >>>>>>> which port received an update.
> >>>>>>> Apparently (I just found out in the documentation), the EventPort
> >>>>>>> will not only trigger my custom method, but also execute the
> >>>>>>> component's UpdateHook() afterwards. What's the reasoning behind
> >>>>>>> calling UpdateHook() here?
> >>>>>>
> >>>>>> Events are _the_ mechanism for asynchronous Coordination, that means
> >>>>>> that it is in their semantics to allow the receiving component to
> >>>>>> react to an event.
> >>>>>>
> >>>>>>> As I wrote my own method, I didn't expect the UpdateHook() getting
> >>>>>>> executed as well.
> >>>>>>
> >>>>>> The semantics is exactly that of an interrupt service in Operating
> >>>>>> Systems: - the event handling (= your method) does the minimally
> >>>>>> required data handling (typically, setting/getting some parameters);
> >>>>>> - the Component is woken up to give it the opportunity to do its
> >>>>>> thing with the newly set parameters.
> >>>>>>
> >>>>>> In case you do the latter inside the former, you are making a
> >>>>>> separation of concerns violation: the event handler should not know
> >>>>>> about what the Component it is attached to will do with the event.
> >>>>>>
> >>>>>>> This is however good behaviour for some of my ports (I was calling
> >>>>>>> UpdateHook manually anyway), but surely not for all. Is there a way
> >>>>>>> I can disable calling it?
> >>>>>>
> >>>>>> What would be the use case in which a Component receives an event,
> >>>>>> but does not get the chance to do something with it?
> >>>>>
> >>>>> The component involved is a pose controller component, receiving
> >>>>> current pose measurements and a goal pose and outputting control
> >>>>> signals (it's also accepting goal velocities, but that's not relevant
> >>>>> here).
> >>>>> The methods connected to these EventPorts read in the new values each
> >>>>> time a new measurement or goal is received => after these methods I
> >>>>> do want UpdateHook() to execute to update the control signals.
> >>>>
> >>>> Yes, that's indeed the semantically intended behaviour of an event.
> >>>>
> >>>>> To monitor whether new measurements are received in time, I hooked up
> >>>>> the controller component to a TimerComponent and implemented a
> >>>>> watchdog (which get's executed every time the TimerComponent triggers
> >>>>> the watchdog EventPort). If no new measurements are received withing
> >>>>> e.g. 0.1s, the ControlMode is changed. So for this method I had in
> >>>>> mind:
> >>>>> - if no new measurements are received in time - change the
> >>>>> controlMode => now I want updateHook to be called of course.
> >>>>> - as long as new measurements are received in time - don't do
> >>>>> anything => don't call the updateHook here, as nor the measurements
> >>>>> nor the goal state have changed.
> >>>>
> >>>> The _responsibility_ to change or not change belongs to the
> >>>> _controller component_ (and most probably, to its Coordination state
> >>>> machine), not to the event handler! The way you do it now is a
> >>>> violation of the "5Cs" separation of concerns. Some potential
> >>>> problems with your approach, that are not there in the architecture I
> >>>> propose are: - when the designers want to change the discrete
> >>>> Coordination behaviour of their control component, they should be
> >>>> able to do that by looking at only one single place, namely the
> >>>> Coordination FSM. (And not in every event handler that the component
> >>>> might be subscribed to.) - the controller might want to know how many
> >>>> times it has already been
> >>>>
> >>>> receiving data in time, or how many times it has already missed
> >>>> data, etc. This bookkeeping (and the possible decision making
> >>>> around it)
> >>>>
> >>>> belongs in the controller component, and not in the event handler.
> >>>
> >>> I can do the decision making in the UpdateHook() (based on the flag
> >>> set in the watchdog event method), but then still this UpdateHook()
> >>> will get called with every watchdog trigger, which is still unneeded.
> >>> I could add some extra variables to keep track of why UpdateHook()
> >>> gets called and let it do nothing if the watchdog method called it
> >>> (and no ControlMode change is needed) (=> this would be the decision
> >>> making), but it looks like a lot of overhead to me, considering the
> >>> original problem?
> >>>
> >>> Alternatively, I can remove the separate Event triggered methods and
> >>> check them all in UpdateHook() and take appropriate actions there? But
> >>> I actually like the fact of making seperate methods for every
> >>> EventPort.
> >>>
> >>> I know there are various solutions, just wondering which is the best
> >>> one...
> >>
> >> Personnaly, I prefer the second approach ....
> >> I always map different event ports to their own specific function (the
> >> that implements the way the component should react to the event).
> >> Personnally, I always leave the UpdateHook empty, but nevertheless I
> >> didn't expect it to be called after receiving an event!
> >>
> >>> From my point of view this is unwanted (and undocumented?) behaviour.
> >>
> >> I don't preferto to the checking myself in the UpdateHook since from my
> >> point of view, this is just meaning double work. There is a direct means
> >> to bind the event to his own function, so why should I bind it to a
> >> general one (UpdateHook) and check there what caused the entry of the
> >> UpdateHook .... If there is a part of the function that would have to be
> >> executed by all the function raised by the events, I would implement a
> >> separate function (not the UpdateHook) and call this function within the
> >> functions bind by to the events ....
> >> So I don't see the need for executing the UpdateHook after every
> >> function triggered by an event ..
> >
> > I agree with Tinne's scheme to use updateHook() as little as possible.
> > For the record: each time the component's 'thread' is triggered to
> > execute, for whatever reason, updateHook() is called.
>
> Which is the intended behaviour :-)
>
> > So the problem is, you don't know *why* updateHook() was called,
>
> Providing this information (and nothing more) is the job of the "event
> handler".
RTT is already doing all this. The user code Steven is talking about is only
the 'defered' event handling code, so a function executed in the thread of the
component. What we are saying is that you can put all your defered handling
code in updateHook() XOR in a specific callback function, only executed when
that particular event happens. Steven used the latter, and he complains that
updateHook() is executed anyway.
>
> > you only know that the component's thread woke
> > up to do some work (process a script, data on event port etc.) If you
> > have some lengthy calculation done in there, you might have a
> > bottleneck.
> >
> > I don't think it's wise to change the behavior of updateHook(), since
> > this would break many components, relying on the
> > being-called-whenever-xyz.
> >
> > What is probably lacking is a mechanism similar to 'state update' and
> > 'output update' which has been proposed by others on this list before.
> > Since we are in a 'components for control' framework, I'm open to such
> > an extension, but it would require broad consensus, since it will add
> > again a new concept to learn.
>
> What exactly would be the semantics of this new primitive?
That's to be discussed :) 2-step state/output update is identical to how
solvers in Simulink work. First the state variables are updated with the
current values at the input ports. Then new outputs are presented. This
requires an absolute synchronous coordination that doesn't scale well in
distributed systems. You could loosen this system-level synchronisation
constraint and still provide both methods, where the state-update is called
when new data arrived on a port (ie, the classical callback Steven uses today)
and an output-update when the component's activity is triggered, for example,
for a periodic component or any other trigger. Densely put, one function
'outputHook()' would be added which is only executed when such a trigger
occurs.
Peter
EventPort with custom method calls updateHook
On Friday 25 March 2011 07:45:30 Herman Bruyninckx wrote:
> On Thu, 24 Mar 2011, Peter Soetens wrote:
> > On Monday 21 March 2011 11:33:14 Tinne De Laet wrote:
> >>>>>>> I'm building a component using several EventPorts (toolchain-2.3).
> >>>>>>> I've made custom methods for all of them, so as to clearly monitor
> >>>>>>> which port received an update.
> >>>>>>> Apparently (I just found out in the documentation), the EventPort
> >>>>>>> will not only trigger my custom method, but also execute the
> >>>>>>> component's UpdateHook() afterwards. What's the reasoning behind
> >>>>>>> calling UpdateHook() here?
> >>>>>>
> >>>>>> Events are _the_ mechanism for asynchronous Coordination, that means
> >>>>>> that it is in their semantics to allow the receiving component to
> >>>>>> react to an event.
> >>>>>>
> >>>>>>> As I wrote my own method, I didn't expect the UpdateHook() getting
> >>>>>>> executed as well.
> >>>>>>
> >>>>>> The semantics is exactly that of an interrupt service in Operating
> >>>>>> Systems: - the event handling (= your method) does the minimally
> >>>>>> required data handling (typically, setting/getting some parameters);
> >>>>>> - the Component is woken up to give it the opportunity to do its
> >>>>>> thing with the newly set parameters.
> >>>>>>
> >>>>>> In case you do the latter inside the former, you are making a
> >>>>>> separation of concerns violation: the event handler should not know
> >>>>>> about what the Component it is attached to will do with the event.
> >>>>>>
> >>>>>>> This is however good behaviour for some of my ports (I was calling
> >>>>>>> UpdateHook manually anyway), but surely not for all. Is there a way
> >>>>>>> I can disable calling it?
> >>>>>>
> >>>>>> What would be the use case in which a Component receives an event,
> >>>>>> but does not get the chance to do something with it?
> >>>>>
> >>>>> The component involved is a pose controller component, receiving
> >>>>> current pose measurements and a goal pose and outputting control
> >>>>> signals (it's also accepting goal velocities, but that's not relevant
> >>>>> here).
> >>>>> The methods connected to these EventPorts read in the new values each
> >>>>> time a new measurement or goal is received => after these methods I
> >>>>> do want UpdateHook() to execute to update the control signals.
> >>>>
> >>>> Yes, that's indeed the semantically intended behaviour of an event.
> >>>>
> >>>>> To monitor whether new measurements are received in time, I hooked up
> >>>>> the controller component to a TimerComponent and implemented a
> >>>>> watchdog (which get's executed every time the TimerComponent triggers
> >>>>> the watchdog EventPort). If no new measurements are received withing
> >>>>> e.g. 0.1s, the ControlMode is changed. So for this method I had in
> >>>>> mind:
> >>>>> - if no new measurements are received in time - change the
> >>>>> controlMode => now I want updateHook to be called of course.
> >>>>> - as long as new measurements are received in time - don't do
> >>>>> anything => don't call the updateHook here, as nor the measurements
> >>>>> nor the goal state have changed.
> >>>>
> >>>> The _responsibility_ to change or not change belongs to the
> >>>> _controller component_ (and most probably, to its Coordination state
> >>>> machine), not to the event handler! The way you do it now is a
> >>>> violation of the "5Cs" separation of concerns. Some potential
> >>>> problems with your approach, that are not there in the architecture I
> >>>> propose are: - when the designers want to change the discrete
> >>>> Coordination behaviour of their control component, they should be
> >>>> able to do that by looking at only one single place, namely the
> >>>> Coordination FSM. (And not in every event handler that the component
> >>>> might be subscribed to.) - the controller might want to know how many
> >>>> times it has already been
> >>>>
> >>>> receiving data in time, or how many times it has already missed
> >>>> data, etc. This bookkeeping (and the possible decision making
> >>>> around it)
> >>>>
> >>>> belongs in the controller component, and not in the event handler.
> >>>
> >>> I can do the decision making in the UpdateHook() (based on the flag
> >>> set in the watchdog event method), but then still this UpdateHook()
> >>> will get called with every watchdog trigger, which is still unneeded.
> >>> I could add some extra variables to keep track of why UpdateHook()
> >>> gets called and let it do nothing if the watchdog method called it
> >>> (and no ControlMode change is needed) (=> this would be the decision
> >>> making), but it looks like a lot of overhead to me, considering the
> >>> original problem?
> >>>
> >>> Alternatively, I can remove the separate Event triggered methods and
> >>> check them all in UpdateHook() and take appropriate actions there? But
> >>> I actually like the fact of making seperate methods for every
> >>> EventPort.
> >>>
> >>> I know there are various solutions, just wondering which is the best
> >>> one...
> >>
> >> Personnaly, I prefer the second approach ....
> >> I always map different event ports to their own specific function (the
> >> that implements the way the component should react to the event).
> >> Personnally, I always leave the UpdateHook empty, but nevertheless I
> >> didn't expect it to be called after receiving an event!
> >>
> >>> From my point of view this is unwanted (and undocumented?) behaviour.
> >>
> >> I don't preferto to the checking myself in the UpdateHook since from my
> >> point of view, this is just meaning double work. There is a direct means
> >> to bind the event to his own function, so why should I bind it to a
> >> general one (UpdateHook) and check there what caused the entry of the
> >> UpdateHook .... If there is a part of the function that would have to be
> >> executed by all the function raised by the events, I would implement a
> >> separate function (not the UpdateHook) and call this function within the
> >> functions bind by to the events ....
> >> So I don't see the need for executing the UpdateHook after every
> >> function triggered by an event ..
> >
> > I agree with Tinne's scheme to use updateHook() as little as possible.
> > For the record: each time the component's 'thread' is triggered to
> > execute, for whatever reason, updateHook() is called.
>
> Which is the intended behaviour :-)
>
> > So the problem is, you don't know *why* updateHook() was called,
>
> Providing this information (and nothing more) is the job of the "event
> handler".
RTT is already doing all this. The user code Steven is talking about is only
the 'defered' event handling code, so a function executed in the thread of the
component. What we are saying is that you can put all your defered handling
code in updateHook() XOR in a specific callback function, only executed when
that particular event happens. Steven used the latter, and he complains that
updateHook() is executed anyway.
>
> > you only know that the component's thread woke
> > up to do some work (process a script, data on event port etc.) If you
> > have some lengthy calculation done in there, you might have a
> > bottleneck.
> >
> > I don't think it's wise to change the behavior of updateHook(), since
> > this would break many components, relying on the
> > being-called-whenever-xyz.
> >
> > What is probably lacking is a mechanism similar to 'state update' and
> > 'output update' which has been proposed by others on this list before.
> > Since we are in a 'components for control' framework, I'm open to such
> > an extension, but it would require broad consensus, since it will add
> > again a new concept to learn.
>
> What exactly would be the semantics of this new primitive?
That's to be discussed :) 2-step state/output update is identical to how
solvers in Simulink work. First the state variables are updated with the
current values at the input ports. Then new outputs are presented. This
requires an absolute synchronous coordination that doesn't scale well in
distributed systems. You could loosen this system-level synchronisation
constraint and still provide both methods, where the state-update is called
when new data arrived on a port (ie, the classical callback Steven uses today)
and an output-update when the component's activity is triggered, for example,
for a periodic component or any other trigger. Densely put, one function
'outputHook()' would be added which is only executed when such a trigger
occurs.
Peter
EventPort with custom method calls updateHook
On Fri, 25 Mar 2011, Peter Soetens wrote:
> On Friday 25 March 2011 07:45:30 Herman Bruyninckx wrote:
>> On Thu, 24 Mar 2011, Peter Soetens wrote:
>>> On Monday 21 March 2011 11:33:14 Tinne De Laet wrote:
>>>>>>>>> I'm building a component using several EventPorts (toolchain-2.3).
>>>>>>>>> I've made custom methods for all of them, so as to clearly monitor
>>>>>>>>> which port received an update.
>>>>>>>>> Apparently (I just found out in the documentation), the EventPort
>>>>>>>>> will not only trigger my custom method, but also execute the
>>>>>>>>> component's UpdateHook() afterwards. What's the reasoning behind
>>>>>>>>> calling UpdateHook() here?
>>>>>>>>
>>>>>>>> Events are _the_ mechanism for asynchronous Coordination, that means
>>>>>>>> that it is in their semantics to allow the receiving component to
>>>>>>>> react to an event.
>>>>>>>>
>>>>>>>>> As I wrote my own method, I didn't expect the UpdateHook() getting
>>>>>>>>> executed as well.
>>>>>>>>
>>>>>>>> The semantics is exactly that of an interrupt service in Operating
>>>>>>>> Systems: - the event handling (= your method) does the minimally
>>>>>>>> required data handling (typically, setting/getting some parameters);
>>>>>>>> - the Component is woken up to give it the opportunity to do its
>>>>>>>> thing with the newly set parameters.
>>>>>>>>
>>>>>>>> In case you do the latter inside the former, you are making a
>>>>>>>> separation of concerns violation: the event handler should not know
>>>>>>>> about what the Component it is attached to will do with the event.
>>>>>>>>
>>>>>>>>> This is however good behaviour for some of my ports (I was calling
>>>>>>>>> UpdateHook manually anyway), but surely not for all. Is there a way
>>>>>>>>> I can disable calling it?
>>>>>>>>
>>>>>>>> What would be the use case in which a Component receives an event,
>>>>>>>> but does not get the chance to do something with it?
>>>>>>>
>>>>>>> The component involved is a pose controller component, receiving
>>>>>>> current pose measurements and a goal pose and outputting control
>>>>>>> signals (it's also accepting goal velocities, but that's not relevant
>>>>>>> here).
>>>>>>> The methods connected to these EventPorts read in the new values each
>>>>>>> time a new measurement or goal is received => after these methods I
>>>>>>> do want UpdateHook() to execute to update the control signals.
>>>>>>
>>>>>> Yes, that's indeed the semantically intended behaviour of an event.
>>>>>>
>>>>>>> To monitor whether new measurements are received in time, I hooked up
>>>>>>> the controller component to a TimerComponent and implemented a
>>>>>>> watchdog (which get's executed every time the TimerComponent triggers
>>>>>>> the watchdog EventPort). If no new measurements are received withing
>>>>>>> e.g. 0.1s, the ControlMode is changed. So for this method I had in
>>>>>>> mind:
>>>>>>> - if no new measurements are received in time - change the
>>>>>>> controlMode => now I want updateHook to be called of course.
>>>>>>> - as long as new measurements are received in time - don't do
>>>>>>> anything => don't call the updateHook here, as nor the measurements
>>>>>>> nor the goal state have changed.
>>>>>>
>>>>>> The _responsibility_ to change or not change belongs to the
>>>>>> _controller component_ (and most probably, to its Coordination state
>>>>>> machine), not to the event handler! The way you do it now is a
>>>>>> violation of the "5Cs" separation of concerns. Some potential
>>>>>> problems with your approach, that are not there in the architecture I
>>>>>> propose are: - when the designers want to change the discrete
>>>>>> Coordination behaviour of their control component, they should be
>>>>>> able to do that by looking at only one single place, namely the
>>>>>> Coordination FSM. (And not in every event handler that the component
>>>>>> might be subscribed to.) - the controller might want to know how many
>>>>>> times it has already been
>>>>>>
>>>>>> receiving data in time, or how many times it has already missed
>>>>>> data, etc. This bookkeeping (and the possible decision making
>>>>>> around it)
>>>>>>
>>>>>> belongs in the controller component, and not in the event handler.
>>>>>
>>>>> I can do the decision making in the UpdateHook() (based on the flag
>>>>> set in the watchdog event method), but then still this UpdateHook()
>>>>> will get called with every watchdog trigger, which is still unneeded.
>>>>> I could add some extra variables to keep track of why UpdateHook()
>>>>> gets called and let it do nothing if the watchdog method called it
>>>>> (and no ControlMode change is needed) (=> this would be the decision
>>>>> making), but it looks like a lot of overhead to me, considering the
>>>>> original problem?
>>>>>
>>>>> Alternatively, I can remove the separate Event triggered methods and
>>>>> check them all in UpdateHook() and take appropriate actions there? But
>>>>> I actually like the fact of making seperate methods for every
>>>>> EventPort.
>>>>>
>>>>> I know there are various solutions, just wondering which is the best
>>>>> one...
>>>>
>>>> Personnaly, I prefer the second approach ....
>>>> I always map different event ports to their own specific function (the
>>>> that implements the way the component should react to the event).
>>>> Personnally, I always leave the UpdateHook empty, but nevertheless I
>>>> didn't expect it to be called after receiving an event!
>>>>
>>>>> From my point of view this is unwanted (and undocumented?) behaviour.
>>>>
>>>> I don't preferto to the checking myself in the UpdateHook since from my
>>>> point of view, this is just meaning double work. There is a direct means
>>>> to bind the event to his own function, so why should I bind it to a
>>>> general one (UpdateHook) and check there what caused the entry of the
>>>> UpdateHook .... If there is a part of the function that would have to be
>>>> executed by all the function raised by the events, I would implement a
>>>> separate function (not the UpdateHook) and call this function within the
>>>> functions bind by to the events ....
>>>> So I don't see the need for executing the UpdateHook after every
>>>> function triggered by an event ..
>>>
>>> I agree with Tinne's scheme to use updateHook() as little as possible.
>>> For the record: each time the component's 'thread' is triggered to
>>> execute, for whatever reason, updateHook() is called.
>>
>> Which is the intended behaviour :-)
>>
>>> So the problem is, you don't know *why* updateHook() was called,
>>
>> Providing this information (and nothing more) is the job of the "event
>> handler".
>
> RTT is already doing all this. The user code Steven is talking about is only
> the 'defered' event handling code, so a function executed in the thread of the
> component. What we are saying is that you can put all your defered handling
> code in updateHook() XOR in a specific callback function, only executed when
> that particular event happens. Steven used the latter, and he complains that
> updateHook() is executed anyway.
>
Ok, good clarification. Some operating systems have this three-level
handling, sometimes called ISR-ASR-DSR (interrupt service routine,
asynchronous service routine, deferred service routine). Useful to have
this flexibility, for advanced users. It will increase the complexity of
the RTT infrastructure, of course.
I am neutral (at this moment) about whether or not to have these three
levels...
>>
>>> you only know that the component's thread woke
>>> up to do some work (process a script, data on event port etc.) If you
>>> have some lengthy calculation done in there, you might have a
>>> bottleneck.
>>>
>>> I don't think it's wise to change the behavior of updateHook(), since
>>> this would break many components, relying on the
>>> being-called-whenever-xyz.
>>>
>>> What is probably lacking is a mechanism similar to 'state update' and
>>> 'output update' which has been proposed by others on this list before.
>>> Since we are in a 'components for control' framework, I'm open to such
>>> an extension, but it would require broad consensus, since it will add
>>> again a new concept to learn.
>>
>> What exactly would be the semantics of this new primitive?
>
> That's to be discussed :) 2-step state/output update is identical to how
> solvers in Simulink work. First the state variables are updated with the
> current values at the input ports. Then new outputs are presented. This
> requires an absolute synchronous coordination that doesn't scale well in
> distributed systems. You could loosen this system-level synchronisation
> constraint and still provide both methods, where the state-update is called
> when new data arrived on a port (ie, the classical callback Steven uses today)
> and an output-update when the component's activity is triggered, for example,
> for a periodic component or any other trigger. Densely put, one function
> 'outputHook()' would be added which is only executed when such a trigger
> occurs.
Ok... Again, I have no good insights to bring in in this discussion...
Herman
EventPort with custom method calls updateHook
On Fri, 25 Mar 2011, Peter Soetens wrote:
> On Friday 25 March 2011 07:45:30 Herman Bruyninckx wrote:
>> On Thu, 24 Mar 2011, Peter Soetens wrote:
>>> On Monday 21 March 2011 11:33:14 Tinne De Laet wrote:
>>>>>>>>> I'm building a component using several EventPorts (toolchain-2.3).
>>>>>>>>> I've made custom methods for all of them, so as to clearly monitor
>>>>>>>>> which port received an update.
>>>>>>>>> Apparently (I just found out in the documentation), the EventPort
>>>>>>>>> will not only trigger my custom method, but also execute the
>>>>>>>>> component's UpdateHook() afterwards. What's the reasoning behind
>>>>>>>>> calling UpdateHook() here?
>>>>>>>>
>>>>>>>> Events are _the_ mechanism for asynchronous Coordination, that means
>>>>>>>> that it is in their semantics to allow the receiving component to
>>>>>>>> react to an event.
>>>>>>>>
>>>>>>>>> As I wrote my own method, I didn't expect the UpdateHook() getting
>>>>>>>>> executed as well.
>>>>>>>>
>>>>>>>> The semantics is exactly that of an interrupt service in Operating
>>>>>>>> Systems: - the event handling (= your method) does the minimally
>>>>>>>> required data handling (typically, setting/getting some parameters);
>>>>>>>> - the Component is woken up to give it the opportunity to do its
>>>>>>>> thing with the newly set parameters.
>>>>>>>>
>>>>>>>> In case you do the latter inside the former, you are making a
>>>>>>>> separation of concerns violation: the event handler should not know
>>>>>>>> about what the Component it is attached to will do with the event.
>>>>>>>>
>>>>>>>>> This is however good behaviour for some of my ports (I was calling
>>>>>>>>> UpdateHook manually anyway), but surely not for all. Is there a way
>>>>>>>>> I can disable calling it?
>>>>>>>>
>>>>>>>> What would be the use case in which a Component receives an event,
>>>>>>>> but does not get the chance to do something with it?
>>>>>>>
>>>>>>> The component involved is a pose controller component, receiving
>>>>>>> current pose measurements and a goal pose and outputting control
>>>>>>> signals (it's also accepting goal velocities, but that's not relevant
>>>>>>> here).
>>>>>>> The methods connected to these EventPorts read in the new values each
>>>>>>> time a new measurement or goal is received => after these methods I
>>>>>>> do want UpdateHook() to execute to update the control signals.
>>>>>>
>>>>>> Yes, that's indeed the semantically intended behaviour of an event.
>>>>>>
>>>>>>> To monitor whether new measurements are received in time, I hooked up
>>>>>>> the controller component to a TimerComponent and implemented a
>>>>>>> watchdog (which get's executed every time the TimerComponent triggers
>>>>>>> the watchdog EventPort). If no new measurements are received withing
>>>>>>> e.g. 0.1s, the ControlMode is changed. So for this method I had in
>>>>>>> mind:
>>>>>>> - if no new measurements are received in time - change the
>>>>>>> controlMode => now I want updateHook to be called of course.
>>>>>>> - as long as new measurements are received in time - don't do
>>>>>>> anything => don't call the updateHook here, as nor the measurements
>>>>>>> nor the goal state have changed.
>>>>>>
>>>>>> The _responsibility_ to change or not change belongs to the
>>>>>> _controller component_ (and most probably, to its Coordination state
>>>>>> machine), not to the event handler! The way you do it now is a
>>>>>> violation of the "5Cs" separation of concerns. Some potential
>>>>>> problems with your approach, that are not there in the architecture I
>>>>>> propose are: - when the designers want to change the discrete
>>>>>> Coordination behaviour of their control component, they should be
>>>>>> able to do that by looking at only one single place, namely the
>>>>>> Coordination FSM. (And not in every event handler that the component
>>>>>> might be subscribed to.) - the controller might want to know how many
>>>>>> times it has already been
>>>>>>
>>>>>> receiving data in time, or how many times it has already missed
>>>>>> data, etc. This bookkeeping (and the possible decision making
>>>>>> around it)
>>>>>>
>>>>>> belongs in the controller component, and not in the event handler.
>>>>>
>>>>> I can do the decision making in the UpdateHook() (based on the flag
>>>>> set in the watchdog event method), but then still this UpdateHook()
>>>>> will get called with every watchdog trigger, which is still unneeded.
>>>>> I could add some extra variables to keep track of why UpdateHook()
>>>>> gets called and let it do nothing if the watchdog method called it
>>>>> (and no ControlMode change is needed) (=> this would be the decision
>>>>> making), but it looks like a lot of overhead to me, considering the
>>>>> original problem?
>>>>>
>>>>> Alternatively, I can remove the separate Event triggered methods and
>>>>> check them all in UpdateHook() and take appropriate actions there? But
>>>>> I actually like the fact of making seperate methods for every
>>>>> EventPort.
>>>>>
>>>>> I know there are various solutions, just wondering which is the best
>>>>> one...
>>>>
>>>> Personnaly, I prefer the second approach ....
>>>> I always map different event ports to their own specific function (the
>>>> that implements the way the component should react to the event).
>>>> Personnally, I always leave the UpdateHook empty, but nevertheless I
>>>> didn't expect it to be called after receiving an event!
>>>>
>>>>> From my point of view this is unwanted (and undocumented?) behaviour.
>>>>
>>>> I don't preferto to the checking myself in the UpdateHook since from my
>>>> point of view, this is just meaning double work. There is a direct means
>>>> to bind the event to his own function, so why should I bind it to a
>>>> general one (UpdateHook) and check there what caused the entry of the
>>>> UpdateHook .... If there is a part of the function that would have to be
>>>> executed by all the function raised by the events, I would implement a
>>>> separate function (not the UpdateHook) and call this function within the
>>>> functions bind by to the events ....
>>>> So I don't see the need for executing the UpdateHook after every
>>>> function triggered by an event ..
>>>
>>> I agree with Tinne's scheme to use updateHook() as little as possible.
>>> For the record: each time the component's 'thread' is triggered to
>>> execute, for whatever reason, updateHook() is called.
>>
>> Which is the intended behaviour :-)
>>
>>> So the problem is, you don't know *why* updateHook() was called,
>>
>> Providing this information (and nothing more) is the job of the "event
>> handler".
>
> RTT is already doing all this. The user code Steven is talking about is only
> the 'defered' event handling code, so a function executed in the thread of the
> component. What we are saying is that you can put all your defered handling
> code in updateHook() XOR in a specific callback function, only executed when
> that particular event happens. Steven used the latter, and he complains that
> updateHook() is executed anyway.
>
Ok, good clarification. Some operating systems have this three-level
handling, sometimes called ISR-ASR-DSR (interrupt service routine,
asynchronous service routine, deferred service routine). Useful to have
this flexibility, for advanced users. It will increase the complexity of
the RTT infrastructure, of course.
I am neutral (at this moment) about whether or not to have these three
levels...
>>
>>> you only know that the component's thread woke
>>> up to do some work (process a script, data on event port etc.) If you
>>> have some lengthy calculation done in there, you might have a
>>> bottleneck.
>>>
>>> I don't think it's wise to change the behavior of updateHook(), since
>>> this would break many components, relying on the
>>> being-called-whenever-xyz.
>>>
>>> What is probably lacking is a mechanism similar to 'state update' and
>>> 'output update' which has been proposed by others on this list before.
>>> Since we are in a 'components for control' framework, I'm open to such
>>> an extension, but it would require broad consensus, since it will add
>>> again a new concept to learn.
>>
>> What exactly would be the semantics of this new primitive?
>
> That's to be discussed :) 2-step state/output update is identical to how
> solvers in Simulink work. First the state variables are updated with the
> current values at the input ports. Then new outputs are presented. This
> requires an absolute synchronous coordination that doesn't scale well in
> distributed systems. You could loosen this system-level synchronisation
> constraint and still provide both methods, where the state-update is called
> when new data arrived on a port (ie, the classical callback Steven uses today)
> and an output-update when the component's activity is triggered, for example,
> for a periodic component or any other trigger. Densely put, one function
> 'outputHook()' would be added which is only executed when such a trigger
> occurs.
Ok... Again, I have no good insights to bring in in this discussion...
Herman
EventPort with custom method calls updateHook
On 03/25/2011 11:38 AM, Peter Soetens wrote:
>>> What is probably lacking is a mechanism similar to 'state update' and
>>> 'output update' which has been proposed by others on this list before.
>>> Since we are in a 'components for control' framework, I'm open to such
>>> an extension, but it would require broad consensus, since it will add
>>> again a new concept to learn.
>>
>> What exactly would be the semantics of this new primitive?
>
> That's to be discussed :) 2-step state/output update is identical to how
> solvers in Simulink work. First the state variables are updated with the
> current values at the input ports. Then new outputs are presented. This
> requires an absolute synchronous coordination that doesn't scale well in
> distributed systems. You could loosen this system-level synchronisation
> constraint and still provide both methods, where the state-update is called
> when new data arrived on a port (ie, the classical callback Steven uses today)
> and an output-update when the component's activity is triggered, for example,
> for a periodic component or any other trigger. Densely put, one function
> 'outputHook()' would be added which is only executed when such a trigger
> occurs.
A bigger picture is that, when you are doing data processing using
specific callbacks, you want your data to come "in order", i.e. you
actually want the hooks to be called in the order of the data timestamps
NOT the order at which the data arrives on the ports.
In other words, you do want to do some "global" processing on the data
before calling the callbacks. Which is best done in the updateHook. And,
honestly, the performance impact of having the updateHook called if
there is no data is completely negligible.
ADVERTISEMENT
We have a nice solution for that particular problem in rock, see
http://rock-robotics.org/stream_aligner/index.html
EventPort with custom method calls updateHook
On 03/25/2011 11:38 AM, Peter Soetens wrote:
>>> What is probably lacking is a mechanism similar to 'state update' and
>>> 'output update' which has been proposed by others on this list before.
>>> Since we are in a 'components for control' framework, I'm open to such
>>> an extension, but it would require broad consensus, since it will add
>>> again a new concept to learn.
>>
>> What exactly would be the semantics of this new primitive?
>
> That's to be discussed :) 2-step state/output update is identical to how
> solvers in Simulink work. First the state variables are updated with the
> current values at the input ports. Then new outputs are presented. This
> requires an absolute synchronous coordination that doesn't scale well in
> distributed systems. You could loosen this system-level synchronisation
> constraint and still provide both methods, where the state-update is called
> when new data arrived on a port (ie, the classical callback Steven uses today)
> and an output-update when the component's activity is triggered, for example,
> for a periodic component or any other trigger. Densely put, one function
> 'outputHook()' would be added which is only executed when such a trigger
> occurs.
A bigger picture is that, when you are doing data processing using
specific callbacks, you want your data to come "in order", i.e. you
actually want the hooks to be called in the order of the data timestamps
NOT the order at which the data arrives on the ports.
In other words, you do want to do some "global" processing on the data
before calling the callbacks. Which is best done in the updateHook. And,
honestly, the performance impact of having the updateHook called if
there is no data is completely negligible.
ADVERTISEMENT
We have a nice solution for that particular problem in rock, see
http://rock-robotics.org/stream_aligner/index.html
EventPort with custom method calls updateHook
On Mon, 21 Mar 2011, Tinne De Laet wrote:
>
>>>>>>
>>>>>> I'm building a component using several EventPorts (toolchain-2.3).
>>>>>> I've made custom methods for all of them, so as to clearly monitor
>>>>>> which port received an update.
>>>>>> Apparently (I just found out in the documentation), the EventPort will
>>>>>> not only trigger my custom method, but also execute the component's
>>>>>> UpdateHook() afterwards. What's the reasoning behind calling
>>>>>> UpdateHook() here?
>>>>>
>>>>> Events are _the_ mechanism for asynchronous Coordination, that means
>>>>> that it is in their semantics to allow the receiving component to
>>>>> react to an event.
>>>>>
>>>>>> As I wrote my own method, I didn't expect the UpdateHook() getting
>>>>>> executed as well.
>>>>>
>>>>> The semantics is exactly that of an interrupt service in Operating
>>>>> Systems: - the event handling (= your method) does the minimally
>>>>> required data handling (typically, setting/getting some parameters);
>>>>> - the Component is woken up to give it the opportunity to do its thing
>>>>> with the newly set parameters.
>>>>>
>>>>> In case you do the latter inside the former, you are making a
>>>>> separation of concerns violation: the event handler should not know
>>>>> about what the Component it is attached to will do with the event.
>>>>>
>>>>>> This is however good behaviour for some of my ports (I was calling
>>>>>> UpdateHook manually anyway), but surely not for all. Is there a way I
>>>>>> can disable calling it?
>>>>>
>>>>> What would be the use case in which a Component receives an event, but
>>>>> does not get the chance to do something with it?
>>>>
>>>> The component involved is a pose controller component, receiving
>>>> current pose measurements and a goal pose and outputting control
>>>> signals (it's also accepting goal velocities, but that's not relevant
>>>> here).
>>>> The methods connected to these EventPorts read in the new values each
>>>> time a new measurement or goal is received => after these methods I do
>>>> want UpdateHook() to execute to update the control signals.
>>>
>>> Yes, that's indeed the semantically intended behaviour of an event.
>>>
>>>> To monitor whether new measurements are received in time, I hooked up
>>>> the controller component to a TimerComponent and implemented a
>>>> watchdog (which get's executed every time the TimerComponent triggers
>>>> the watchdog EventPort). If no new measurements are received withing
>>>> e.g. 0.1s, the ControlMode is changed. So for this method I had in
>>>> mind:
>>>> - if no new measurements are received in time - change the controlMode
>>>> => now I want updateHook to be called of course.
>>>> - as long as new measurements are received in time - don't do anything
>>>> => don't call the updateHook here, as nor the measurements nor the
>>>> goal state have changed.
>>>
>>> The _responsibility_ to change or not change belongs to the _controller
>>> component_ (and most probably, to its Coordination state machine), not to
>>> the event handler! The way you do it now is a violation of the "5Cs"
>>> separation of concerns. Some potential problems with your approach, that
>>> are not there in the architecture I propose are:
>>> - when the designers want to change the discrete Coordination behaviour
>>> of their control component, they should be able to do that by looking at
>>> only one single place, namely the Coordination FSM. (And not in every
>>> event handler that the component might be subscribed to.)
>>> - the controller might want to know how many times it has already been
>>> receiving data in time, or how many times it has already missed data,
>>> etc. This bookkeeping (and the possible decision making around it)
>>> belongs in the controller component, and not in the event handler.
>>
>> I can do the decision making in the UpdateHook() (based on the flag
>> set in the watchdog event method), but then still this UpdateHook()
>> will get called with every watchdog trigger, which is still unneeded.
>> I could add some extra variables to keep track of why UpdateHook()
>> gets called and let it do nothing if the watchdog method called it
>> (and no ControlMode change is needed) (=> this would be the decision
>> making), but it looks like a lot of overhead to me, considering the
>>
>> Alternatively, I can remove the separate Event triggered methods and
>> check them all in UpdateHook() and take appropriate actions there? But
>> I actually like the fact of making seperate methods for every
>> EventPort.
>
>> I know there are various solutions, just wondering which is the best one...
>
> Personnaly, I prefer the second approach ....
> I always map different event ports to their own specific function (the that
> implements the way the component should react to the event). Personnally, I
> always leave the UpdateHook empty, but nevertheless I didn't expect it to be
> called after receiving an event!
> From my point of view this is unwanted (and undocumented?) behaviour.
>From my point of view, calling the UpdateHook() is the preferred behaviour.
(For the reasons explained before in this thread.)
I do think that RTT's potential support for a more versatile
_configuration_ of when to call the UpdateHook() does make sense though.
> I don't preferto to the checking myself in the UpdateHook since from my point
> of view, this is just meaning double work. There is a direct means to bind the
> event to his own function, so why should I bind it to a general one
> (UpdateHook) and check there what caused the entry of the UpdateHook ....
Because of these problems:
- executing the same function in different process contexts.
(This is a technical problem ("race conditions", "inconsistent data"),
that can wreck your application when it is deployed on a different
threading model.)
- an event handler should not decide for a component; the component must do
its own event "completion", on the basis of the data prepared by each
event handler.
(This is a "reusability" problem: if the desired behaviour of a component
is to be updated, or reused in another context, the developer of the
component should only have to look at one single configuration, and not at
what each of the event handlers do. In addition, what if two different
event handlers would take inconsistent decisions? Not so probable in
your small-scale use case, but very probably in large-scale systems,
that is, when one component can be triggered by a lot of events.)
> If there is a part of the function that would have to be executed by all the
> function raised by the events, I would implement a separate function (not the
> UpdateHook) and call this function within the functions bind by to the events
> ....
> So I don't see the need for executing the UpdateHook after every function
> triggered by an event ..
>
> Tinne
Herman
EventPort with custom method calls updateHook
On Mon, 21 Mar 2011, Tinne De Laet wrote:
>
>>>>>>
>>>>>> I'm building a component using several EventPorts (toolchain-2.3).
>>>>>> I've made custom methods for all of them, so as to clearly monitor
>>>>>> which port received an update.
>>>>>> Apparently (I just found out in the documentation), the EventPort will
>>>>>> not only trigger my custom method, but also execute the component's
>>>>>> UpdateHook() afterwards. What's the reasoning behind calling
>>>>>> UpdateHook() here?
>>>>>
>>>>> Events are _the_ mechanism for asynchronous Coordination, that means
>>>>> that it is in their semantics to allow the receiving component to
>>>>> react to an event.
>>>>>
>>>>>> As I wrote my own method, I didn't expect the UpdateHook() getting
>>>>>> executed as well.
>>>>>
>>>>> The semantics is exactly that of an interrupt service in Operating
>>>>> Systems: - the event handling (= your method) does the minimally
>>>>> required data handling (typically, setting/getting some parameters);
>>>>> - the Component is woken up to give it the opportunity to do its thing
>>>>> with the newly set parameters.
>>>>>
>>>>> In case you do the latter inside the former, you are making a
>>>>> separation of concerns violation: the event handler should not know
>>>>> about what the Component it is attached to will do with the event.
>>>>>
>>>>>> This is however good behaviour for some of my ports (I was calling
>>>>>> UpdateHook manually anyway), but surely not for all. Is there a way I
>>>>>> can disable calling it?
>>>>>
>>>>> What would be the use case in which a Component receives an event, but
>>>>> does not get the chance to do something with it?
>>>>
>>>> The component involved is a pose controller component, receiving
>>>> current pose measurements and a goal pose and outputting control
>>>> signals (it's also accepting goal velocities, but that's not relevant
>>>> here).
>>>> The methods connected to these EventPorts read in the new values each
>>>> time a new measurement or goal is received => after these methods I do
>>>> want UpdateHook() to execute to update the control signals.
>>>
>>> Yes, that's indeed the semantically intended behaviour of an event.
>>>
>>>> To monitor whether new measurements are received in time, I hooked up
>>>> the controller component to a TimerComponent and implemented a
>>>> watchdog (which get's executed every time the TimerComponent triggers
>>>> the watchdog EventPort). If no new measurements are received withing
>>>> e.g. 0.1s, the ControlMode is changed. So for this method I had in
>>>> mind:
>>>> - if no new measurements are received in time - change the controlMode
>>>> => now I want updateHook to be called of course.
>>>> - as long as new measurements are received in time - don't do anything
>>>> => don't call the updateHook here, as nor the measurements nor the
>>>> goal state have changed.
>>>
>>> The _responsibility_ to change or not change belongs to the _controller
>>> component_ (and most probably, to its Coordination state machine), not to
>>> the event handler! The way you do it now is a violation of the "5Cs"
>>> separation of concerns. Some potential problems with your approach, that
>>> are not there in the architecture I propose are:
>>> - when the designers want to change the discrete Coordination behaviour
>>> of their control component, they should be able to do that by looking at
>>> only one single place, namely the Coordination FSM. (And not in every
>>> event handler that the component might be subscribed to.)
>>> - the controller might want to know how many times it has already been
>>> receiving data in time, or how many times it has already missed data,
>>> etc. This bookkeeping (and the possible decision making around it)
>>> belongs in the controller component, and not in the event handler.
>>
>> I can do the decision making in the UpdateHook() (based on the flag
>> set in the watchdog event method), but then still this UpdateHook()
>> will get called with every watchdog trigger, which is still unneeded.
>> I could add some extra variables to keep track of why UpdateHook()
>> gets called and let it do nothing if the watchdog method called it
>> (and no ControlMode change is needed) (=> this would be the decision
>> making), but it looks like a lot of overhead to me, considering the
>>
>> Alternatively, I can remove the separate Event triggered methods and
>> check them all in UpdateHook() and take appropriate actions there? But
>> I actually like the fact of making seperate methods for every
>> EventPort.
>
>> I know there are various solutions, just wondering which is the best one...
>
> Personnaly, I prefer the second approach ....
> I always map different event ports to their own specific function (the that
> implements the way the component should react to the event). Personnally, I
> always leave the UpdateHook empty, but nevertheless I didn't expect it to be
> called after receiving an event!
> From my point of view this is unwanted (and undocumented?) behaviour.
>From my point of view, calling the UpdateHook() is the preferred behaviour.
(For the reasons explained before in this thread.)
I do think that RTT's potential support for a more versatile
_configuration_ of when to call the UpdateHook() does make sense though.
> I don't preferto to the checking myself in the UpdateHook since from my point
> of view, this is just meaning double work. There is a direct means to bind the
> event to his own function, so why should I bind it to a general one
> (UpdateHook) and check there what caused the entry of the UpdateHook ....
Because of these problems:
- executing the same function in different process contexts.
(This is a technical problem ("race conditions", "inconsistent data"),
that can wreck your application when it is deployed on a different
threading model.)
- an event handler should not decide for a component; the component must do
its own event "completion", on the basis of the data prepared by each
event handler.
(This is a "reusability" problem: if the desired behaviour of a component
is to be updated, or reused in another context, the developer of the
component should only have to look at one single configuration, and not at
what each of the event handlers do. In addition, what if two different
event handlers would take inconsistent decisions? Not so probable in
your small-scale use case, but very probably in large-scale systems,
that is, when one component can be triggered by a lot of events.)
> If there is a part of the function that would have to be executed by all the
> function raised by the events, I would implement a separate function (not the
> UpdateHook) and call this function within the functions bind by to the events
> ....
> So I don't see the need for executing the UpdateHook after every function
> triggered by an event ..
>
> Tinne
Herman
EventPort with custom method calls updateHook
On Sun, 20 Mar 2011, Steven Bellens wrote:
> 2011/3/20 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
>> On Sun, 20 Mar 2011, Steven Bellens wrote:
>>
>>> 2011/3/20 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
>>>> On Sun, 20 Mar 2011, Steven Bellens wrote:
>>>>
>>>>> Hey,
>>>>>
>>>>> I'm building a component using several EventPorts (toolchain-2.3).
>>>>> I've made custom methods for all of them, so as to clearly monitor
>>>>> which port received an update.
>>>>> Apparently (I just found out in the documentation), the EventPort will
>>>>> not only trigger my custom method, but also execute the component's
>>>>> UpdateHook() afterwards. What's the reasoning behind calling
>>>>> UpdateHook() here?
>>>>
>>>> Events are _the_ mechanism for asynchronous Coordination, that means that
>>>> it is in their semantics to allow the receiving component to react to an
>>>> event.
>>>>
>>>>> As I wrote my own method, I didn't expect the UpdateHook() getting
>>>>> executed as well.
>>>>
>>>> The semantics is exactly that of an interrupt service in Operating Systems:
>>>> - the event handling (= your method) does the minimally required data
>>>> handling (typically, setting/getting some parameters);
>>>> - the Component is woken up to give it the opportunity to do its thing with
>>>> the newly set parameters.
>>>>
>>>> In case you do the latter inside the former, you are making a separation of
>>>> concerns violation: the event handler should not know about what the
>>>> Component it is attached to will do with the event.
>>>>
>>>>> This is however good behaviour for some of my ports (I was calling
>>>>> UpdateHook manually anyway), but surely not for all. Is there a way I
>>>>> can disable calling it?
>>>>
>>>> What would be the use case in which a Component receives an event, but does
>>>> not get the chance to do something with it?
>>>
>>> The component involved is a pose controller component, receiving
>>> current pose measurements and a goal pose and outputting control
>>> signals (it's also accepting goal velocities, but that's not relevant
>>> here).
>>> The methods connected to these EventPorts read in the new values each
>>> time a new measurement or goal is received => after these methods I do
>>> want UpdateHook() to execute to update the control signals.
>>
>> Yes, that's indeed the semantically intended behaviour of an event.
>>
>>> To monitor whether new measurements are received in time, I hooked up
>>> the controller component to a TimerComponent and implemented a
>>> watchdog (which get's executed every time the TimerComponent triggers
>>> the watchdog EventPort). If no new measurements are received withing
>>> e.g. 0.1s, the ControlMode is changed. So for this method I had in
>>> mind:
>>> - if no new measurements are received in time - change the controlMode
>>> => now I want updateHook to be called of course.
>>> - as long as new measurements are received in time - don't do anything
>>> => don't call the updateHook here, as nor the measurements nor the
>>> goal state have changed.
>>
>> The _responsibility_ to change or not change belongs to the _controller
>> component_ (and most probably, to its Coordination state machine), not to
>> the event handler! The way you do it now is a violation of the "5Cs"
>> separation of concerns. Some potential problems with your approach, that
>> are not there in the architecture I propose are:
>> - when the designers want to change the discrete Coordination behaviour of
>> their control component, they should be able to do that by looking at
>> only one single place, namely the Coordination FSM. (And not in every event
>> handler that the component might be subscribed to.)
>> - the controller might want to know how many times it has already been
>> receiving data in time, or how many times it has already missed data,
>> etc. This bookkeeping (and the possible decision making around it) belongs
>> in the controller component, and not in the event handler.
>
> I can do the decision making in the UpdateHook() (based on the flag
> set in the watchdog event method), but then still this UpdateHook()
> will get called with every watchdog trigger, which is still unneeded.
> I could add some extra variables to keep track of why UpdateHook()
> gets called and let it do nothing if the watchdog method called it
> (and no ControlMode change is needed) (=> this would be the decision
> making), but it looks like a lot of overhead to me, considering the
> original problem?
Don't expect to use watchdogs without overhead! You did the right thing, by
introducing a watchdog, but don't try to "optimize its overhead away" for
your specific case...
The fundamental question I have is _why_ you think safety is a "lot of
overhead"... :-)
> Alternatively, I can remove the separate Event triggered methods and
> check them all in UpdateHook() and take appropriate actions there? But
> I actually like the fact of making seperate methods for every
> EventPort.
Why is that? And what is so portable about your likings? :-)
I do repeat that you are _violating_ separations of concerns by including
"separate methods for every EventPort"! The event port has to do nothing
more than getting events; _any_ interpretation of the events _has_ to take
place within the component that is subscribed to the event.
> I know there are various solutions, just wondering which is the best one...
Orocos was created with two definitions of "best" in mind:
- more reusable is better, and
- more realtime safe is better.
Mind you, _not_ with "faster is better" as a criterion!
Your approach does not satisfy any of those two criterions. (The latter one
is obvious, if you think about a reuse in accelerated hardware, where your
event handlers could be real Interrupt Service Routines.)
>>> I know it's not a terrible thing UpdateHook() get's called here as
>>> well, but it makes the watchdog pretty intrusive, which is not how it
>>> should be.
>>
>> What do you mean with "pretty intrusive"? And watchdogs _should_ be
>> "intrusive" since that's the key essence of their existence :-)
>
> It should monitor, in this case, the measurement update frequency, but
> as long as everything goes well, it's influence should be as minimal
> as possible (only the EventPort method execution).
> It should only make it's presence felt the moment the measurements go wrong.
No: violation of SoC... No event handler should have to know anything about
when something is right or wrong for the Component it is attached to.
Never!
Herman
EventPort with custom method calls updateHook
On Sun, 20 Mar 2011, Steven Bellens wrote:
> 2011/3/20 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
>> On Sun, 20 Mar 2011, Steven Bellens wrote:
>>
>>> 2011/3/20 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
>>>> On Sun, 20 Mar 2011, Steven Bellens wrote:
>>>>
>>>>> Hey,
>>>>>
>>>>> I'm building a component using several EventPorts (toolchain-2.3).
>>>>> I've made custom methods for all of them, so as to clearly monitor
>>>>> which port received an update.
>>>>> Apparently (I just found out in the documentation), the EventPort will
>>>>> not only trigger my custom method, but also execute the component's
>>>>> UpdateHook() afterwards. What's the reasoning behind calling
>>>>> UpdateHook() here?
>>>>
>>>> Events are _the_ mechanism for asynchronous Coordination, that means that
>>>> it is in their semantics to allow the receiving component to react to an
>>>> event.
>>>>
>>>>> As I wrote my own method, I didn't expect the UpdateHook() getting
>>>>> executed as well.
>>>>
>>>> The semantics is exactly that of an interrupt service in Operating Systems:
>>>> - the event handling (= your method) does the minimally required data
>>>> handling (typically, setting/getting some parameters);
>>>> - the Component is woken up to give it the opportunity to do its thing with
>>>> the newly set parameters.
>>>>
>>>> In case you do the latter inside the former, you are making a separation of
>>>> concerns violation: the event handler should not know about what the
>>>> Component it is attached to will do with the event.
>>>>
>>>>> This is however good behaviour for some of my ports (I was calling
>>>>> UpdateHook manually anyway), but surely not for all. Is there a way I
>>>>> can disable calling it?
>>>>
>>>> What would be the use case in which a Component receives an event, but does
>>>> not get the chance to do something with it?
>>>
>>> The component involved is a pose controller component, receiving
>>> current pose measurements and a goal pose and outputting control
>>> signals (it's also accepting goal velocities, but that's not relevant
>>> here).
>>> The methods connected to these EventPorts read in the new values each
>>> time a new measurement or goal is received => after these methods I do
>>> want UpdateHook() to execute to update the control signals.
>>
>> Yes, that's indeed the semantically intended behaviour of an event.
>>
>>> To monitor whether new measurements are received in time, I hooked up
>>> the controller component to a TimerComponent and implemented a
>>> watchdog (which get's executed every time the TimerComponent triggers
>>> the watchdog EventPort). If no new measurements are received withing
>>> e.g. 0.1s, the ControlMode is changed. So for this method I had in
>>> mind:
>>> - if no new measurements are received in time - change the controlMode
>>> => now I want updateHook to be called of course.
>>> - as long as new measurements are received in time - don't do anything
>>> => don't call the updateHook here, as nor the measurements nor the
>>> goal state have changed.
>>
>> The _responsibility_ to change or not change belongs to the _controller
>> component_ (and most probably, to its Coordination state machine), not to
>> the event handler! The way you do it now is a violation of the "5Cs"
>> separation of concerns. Some potential problems with your approach, that
>> are not there in the architecture I propose are:
>> - when the designers want to change the discrete Coordination behaviour of
>> their control component, they should be able to do that by looking at
>> only one single place, namely the Coordination FSM. (And not in every event
>> handler that the component might be subscribed to.)
>> - the controller might want to know how many times it has already been
>> receiving data in time, or how many times it has already missed data,
>> etc. This bookkeeping (and the possible decision making around it) belongs
>> in the controller component, and not in the event handler.
>
> I can do the decision making in the UpdateHook() (based on the flag
> set in the watchdog event method), but then still this UpdateHook()
> will get called with every watchdog trigger, which is still unneeded.
> I could add some extra variables to keep track of why UpdateHook()
> gets called and let it do nothing if the watchdog method called it
> (and no ControlMode change is needed) (=> this would be the decision
> making), but it looks like a lot of overhead to me, considering the
> original problem?
Don't expect to use watchdogs without overhead! You did the right thing, by
introducing a watchdog, but don't try to "optimize its overhead away" for
your specific case...
The fundamental question I have is _why_ you think safety is a "lot of
overhead"... :-)
> Alternatively, I can remove the separate Event triggered methods and
> check them all in UpdateHook() and take appropriate actions there? But
> I actually like the fact of making seperate methods for every
> EventPort.
Why is that? And what is so portable about your likings? :-)
I do repeat that you are _violating_ separations of concerns by including
"separate methods for every EventPort"! The event port has to do nothing
more than getting events; _any_ interpretation of the events _has_ to take
place within the component that is subscribed to the event.
> I know there are various solutions, just wondering which is the best one...
Orocos was created with two definitions of "best" in mind:
- more reusable is better, and
- more realtime safe is better.
Mind you, _not_ with "faster is better" as a criterion!
Your approach does not satisfy any of those two criterions. (The latter one
is obvious, if you think about a reuse in accelerated hardware, where your
event handlers could be real Interrupt Service Routines.)
>>> I know it's not a terrible thing UpdateHook() get's called here as
>>> well, but it makes the watchdog pretty intrusive, which is not how it
>>> should be.
>>
>> What do you mean with "pretty intrusive"? And watchdogs _should_ be
>> "intrusive" since that's the key essence of their existence :-)
>
> It should monitor, in this case, the measurement update frequency, but
> as long as everything goes well, it's influence should be as minimal
> as possible (only the EventPort method execution).
> It should only make it's presence felt the moment the measurements go wrong.
No: violation of SoC... No event handler should have to know anything about
when something is right or wrong for the Component it is attached to.
Never!
Herman
EventPort with custom method calls updateHook
[...]
>
> Don't expect to use watchdogs without overhead! You did the right thing, by
> introducing a watchdog, but don't try to "optimize its overhead away" for
> your specific case...
>
> The fundamental question I have is _why_ you think safety is a "lot of
> overhead"... :-)
>
>> Alternatively, I can remove the separate Event triggered methods and
>> check them all in UpdateHook() and take appropriate actions there? But
>> I actually like the fact of making seperate methods for every
>> EventPort.
>
> Why is that? And what is so portable about your likings? :-)
Because it nicely separates what happens for every EventPort
individually without cluttering UpdateHook().
>
> I do repeat that you are _violating_ separations of concerns by including
> "separate methods for every EventPort"! The event port has to do nothing
> more than getting events; _any_ interpretation of the events _has_ to take
> place within the component that is subscribed to the event.
This is how it works now! The interpretation of the Events happens in
the individual methods, which are part of the Controller component,
subscribed to the event.
>
>> I know there are various solutions, just wondering which is the best one...
>
> Orocos was created with two definitions of "best" in mind:
> - more reusable is better, and
> - more realtime safe is better.
> Mind you, _not_ with "faster is better" as a criterion!
>
> Your approach does not satisfy any of those two criterions. (The latter one
> is obvious, if you think about a reuse in accelerated hardware, where your
> event handlers could be real Interrupt Service Routines.)
>
>>>> I know it's not a terrible thing UpdateHook() get's called here as
>>>> well, but it makes the watchdog pretty intrusive, which is not how it
>>>> should be.
>>>
>>> What do you mean with "pretty intrusive"? And watchdogs _should_ be
>>> "intrusive" since that's the key essence of their existence :-)
>>
>> It should monitor, in this case, the measurement update frequency, but
>> as long as everything goes well, it's influence should be as minimal
>> as possible (only the EventPort method execution).
>> It should only make it's presence felt the moment the measurements go wrong.
>
> No: violation of SoC... No event handler should have to know anything about
> when something is right or wrong for the Component it is attached to.
> Never!
Again, this interpretation is already done _inside_ the Controller component.
Steven
>
> Herman
EventPort with custom method calls updateHook
[...]
>
> Don't expect to use watchdogs without overhead! You did the right thing, by
> introducing a watchdog, but don't try to "optimize its overhead away" for
> your specific case...
>
> The fundamental question I have is _why_ you think safety is a "lot of
> overhead"... :-)
>
>> Alternatively, I can remove the separate Event triggered methods and
>> check them all in UpdateHook() and take appropriate actions there? But
>> I actually like the fact of making seperate methods for every
>> EventPort.
>
> Why is that? And what is so portable about your likings? :-)
Because it nicely separates what happens for every EventPort
individually without cluttering UpdateHook().
>
> I do repeat that you are _violating_ separations of concerns by including
> "separate methods for every EventPort"! The event port has to do nothing
> more than getting events; _any_ interpretation of the events _has_ to take
> place within the component that is subscribed to the event.
This is how it works now! The interpretation of the Events happens in
the individual methods, which are part of the Controller component,
subscribed to the event.
>
>> I know there are various solutions, just wondering which is the best one...
>
> Orocos was created with two definitions of "best" in mind:
> - more reusable is better, and
> - more realtime safe is better.
> Mind you, _not_ with "faster is better" as a criterion!
>
> Your approach does not satisfy any of those two criterions. (The latter one
> is obvious, if you think about a reuse in accelerated hardware, where your
> event handlers could be real Interrupt Service Routines.)
>
>>>> I know it's not a terrible thing UpdateHook() get's called here as
>>>> well, but it makes the watchdog pretty intrusive, which is not how it
>>>> should be.
>>>
>>> What do you mean with "pretty intrusive"? And watchdogs _should_ be
>>> "intrusive" since that's the key essence of their existence :-)
>>
>> It should monitor, in this case, the measurement update frequency, but
>> as long as everything goes well, it's influence should be as minimal
>> as possible (only the EventPort method execution).
>> It should only make it's presence felt the moment the measurements go wrong.
>
> No: violation of SoC... No event handler should have to know anything about
> when something is right or wrong for the Component it is attached to.
> Never!
Again, this interpretation is already done _inside_ the Controller component.
Steven
>
> Herman
EventPort with custom method calls updateHook
On Sun, 20 Mar 2011, Steven Bellens wrote:
> [...]
>>
>> Don't expect to use watchdogs without overhead! You did the right thing, by
>> introducing a watchdog, but don't try to "optimize its overhead away" for
>> your specific case...
>>
>> The fundamental question I have is _why_ you think safety is a "lot of
>> overhead"... :-)
>>
>>> Alternatively, I can remove the separate Event triggered methods and
>>> check them all in UpdateHook() and take appropriate actions there? But
>>> I actually like the fact of making seperate methods for every
>>> EventPort.
>>
>> Why is that? And what is so portable about your likings? :-)
>
> Because it nicely separates what happens for every EventPort
> individually without cluttering UpdateHook().
Oops! You have your "separation of concerns" wrong: the "UpdateHook()"
_belongs_ to the Component (that is, it can access all its data), the event
handler should not.
>> I do repeat that you are _violating_ separations of concerns by including
>> "separate methods for every EventPort"! The event port has to do nothing
>> more than getting events; _any_ interpretation of the events _has_ to take
>> place within the component that is subscribed to the event.
>
> This is how it works now! The interpretation of the Events happens in
> the individual methods, which are part of the Controller component,
> subscribed to the event.
It's the "part of" part that I do not like: an event handler should _not_
be "part of" a Controller component; they should just set/get the minimal
amount of data (related to the _taking place_ of the event, not of the
_interpretation_ of the event), and that's it.
>>> I know there are various solutions, just wondering which is the best one...
>>
>> Orocos was created with two definitions of "best" in mind:
>> - more reusable is better, and
>> - more realtime safe is better.
>> Mind you, _not_ with "faster is better" as a criterion!
>>
>> Your approach does not satisfy any of those two criterions. (The latter one
>> is obvious, if you think about a reuse in accelerated hardware, where your
>> event handlers could be real Interrupt Service Routines.)
>>
>>>>> I know it's not a terrible thing UpdateHook() get's called here as
>>>>> well, but it makes the watchdog pretty intrusive, which is not how it
>>>>> should be.
>>>>
>>>> What do you mean with "pretty intrusive"? And watchdogs _should_ be
>>>> "intrusive" since that's the key essence of their existence :-)
>>>
>>> It should monitor, in this case, the measurement update frequency, but
>>> as long as everything goes well, it's influence should be as minimal
>>> as possible (only the EventPort method execution).
>>> It should only make it's presence felt the moment the measurements go wrong.
>>
>> No: violation of SoC... No event handler should have to know anything about
>> when something is right or wrong for the Component it is attached to.
>> Never!
>
> Again, this interpretation is already done _inside_ the Controller component.
As far as I understand your design, "being done inside the Controller
component" means nothing else but "calling a function of the controller
component", right? That's not the same thing as decoupling:
- an event handler should not know about which functions are available in a
component.
- calling the same function from different threads/contexts can make a big
semantic difference, so it is not only important to keep the (decision
making) function that is called in the component, but also to do the
calling itself in the component's thread.
Maybe (probably) your case _is_ single threaded (and hence does not show
any difference wrt to second argument), but that is then a coincidence of
your particular deployment.
I can be wrong about all my interpretations about what I think your design
is doing, so please tell me if that's indeed the case :-)
Herman
EventPort with custom method calls updateHook
On Sun, 20 Mar 2011, Steven Bellens wrote:
> [...]
>>
>> Don't expect to use watchdogs without overhead! You did the right thing, by
>> introducing a watchdog, but don't try to "optimize its overhead away" for
>> your specific case...
>>
>> The fundamental question I have is _why_ you think safety is a "lot of
>> overhead"... :-)
>>
>>> Alternatively, I can remove the separate Event triggered methods and
>>> check them all in UpdateHook() and take appropriate actions there? But
>>> I actually like the fact of making seperate methods for every
>>> EventPort.
>>
>> Why is that? And what is so portable about your likings? :-)
>
> Because it nicely separates what happens for every EventPort
> individually without cluttering UpdateHook().
Oops! You have your "separation of concerns" wrong: the "UpdateHook()"
_belongs_ to the Component (that is, it can access all its data), the event
handler should not.
>> I do repeat that you are _violating_ separations of concerns by including
>> "separate methods for every EventPort"! The event port has to do nothing
>> more than getting events; _any_ interpretation of the events _has_ to take
>> place within the component that is subscribed to the event.
>
> This is how it works now! The interpretation of the Events happens in
> the individual methods, which are part of the Controller component,
> subscribed to the event.
It's the "part of" part that I do not like: an event handler should _not_
be "part of" a Controller component; they should just set/get the minimal
amount of data (related to the _taking place_ of the event, not of the
_interpretation_ of the event), and that's it.
>>> I know there are various solutions, just wondering which is the best one...
>>
>> Orocos was created with two definitions of "best" in mind:
>> - more reusable is better, and
>> - more realtime safe is better.
>> Mind you, _not_ with "faster is better" as a criterion!
>>
>> Your approach does not satisfy any of those two criterions. (The latter one
>> is obvious, if you think about a reuse in accelerated hardware, where your
>> event handlers could be real Interrupt Service Routines.)
>>
>>>>> I know it's not a terrible thing UpdateHook() get's called here as
>>>>> well, but it makes the watchdog pretty intrusive, which is not how it
>>>>> should be.
>>>>
>>>> What do you mean with "pretty intrusive"? And watchdogs _should_ be
>>>> "intrusive" since that's the key essence of their existence :-)
>>>
>>> It should monitor, in this case, the measurement update frequency, but
>>> as long as everything goes well, it's influence should be as minimal
>>> as possible (only the EventPort method execution).
>>> It should only make it's presence felt the moment the measurements go wrong.
>>
>> No: violation of SoC... No event handler should have to know anything about
>> when something is right or wrong for the Component it is attached to.
>> Never!
>
> Again, this interpretation is already done _inside_ the Controller component.
As far as I understand your design, "being done inside the Controller
component" means nothing else but "calling a function of the controller
component", right? That's not the same thing as decoupling:
- an event handler should not know about which functions are available in a
component.
- calling the same function from different threads/contexts can make a big
semantic difference, so it is not only important to keep the (decision
making) function that is called in the component, but also to do the
calling itself in the component's thread.
Maybe (probably) your case _is_ single threaded (and hence does not show
any difference wrt to second argument), but that is then a coincidence of
your particular deployment.
I can be wrong about all my interpretations about what I think your design
is doing, so please tell me if that's indeed the case :-)
Herman
EventPort with custom method calls updateHook
[...]
>>>
>>> Why is that? And what is so portable about your likings? :-)
>>
>> Because it nicely separates what happens for every EventPort
>> individually without cluttering UpdateHook().
>
> Oops! You have your "separation of concerns" wrong: the "UpdateHook()"
> _belongs_ to the Component (that is, it can access all its data), the event
> handler should not.
The suggested way, as explained in the orocos documentation (orocos
component manual, p. 30), is to do the, what you are calling event
handling, in UpdateHook(). The way I see it is:
- orocos is already taking care of the event handling: it catches it
when something happened and it will wake up my component
- inside my component, I react to that wake up call and do event
processing / decision making.
>
>>> I do repeat that you are _violating_ separations of concerns by including
>>> "separate methods for every EventPort"! The event port has to do nothing
>>> more than getting events; _any_ interpretation of the events _has_ to take
>>> place within the component that is subscribed to the event.
>>
>> This is how it works now! The interpretation of the Events happens in
>> the individual methods, which are part of the Controller component,
>> subscribed to the event.
>
> It's the "part of" part that I do not like: an event handler should _not_
> be "part of" a Controller component; they should just set/get the minimal
> amount of data (related to the _taking place_ of the event, not of the
> _interpretation_ of the event), and that's it.
>
>>>> I know there are various solutions, just wondering which is the best one...
>>>
>>> Orocos was created with two definitions of "best" in mind:
>>> - more reusable is better, and
>>> - more realtime safe is better.
>>> Mind you, _not_ with "faster is better" as a criterion!
>>>
>>> Your approach does not satisfy any of those two criterions. (The latter one
>>> is obvious, if you think about a reuse in accelerated hardware, where your
>>> event handlers could be real Interrupt Service Routines.)
>>>
>>>>>> I know it's not a terrible thing UpdateHook() get's called here as
>>>>>> well, but it makes the watchdog pretty intrusive, which is not how it
>>>>>> should be.
>>>>>
>>>>> What do you mean with "pretty intrusive"? And watchdogs _should_ be
>>>>> "intrusive" since that's the key essence of their existence :-)
>>>>
>>>> It should monitor, in this case, the measurement update frequency, but
>>>> as long as everything goes well, it's influence should be as minimal
>>>> as possible (only the EventPort method execution).
>>>> It should only make it's presence felt the moment the measurements go wrong.
>>>
>>> No: violation of SoC... No event handler should have to know anything about
>>> when something is right or wrong for the Component it is attached to.
>>> Never!
>>
>> Again, this interpretation is already done _inside_ the Controller component.
>
> As far as I understand your design, "being done inside the Controller
> component" means nothing else but "calling a function of the controller
> component", right? That's not the same thing as decoupling:
> - an event handler should not know about which functions are available in a
> component.
> - calling the same function from different threads/contexts can make a big
> semantic difference, so it is not only important to keep the (decision
> making) function that is called in the component, but also to do the
> calling itself in the component's thread.
The function which gets called _is_ part of the Controller component.
Do I misunderstand this?
Steven
> Maybe (probably) your case _is_ single threaded (and hence does not show
> any difference wrt to second argument), but that is then a coincidence of
> your particular deployment.
>
> I can be wrong about all my interpretations about what I think your design
> is doing, so please tell me if that's indeed the case :-)
>
> Herman
>
EventPort with custom method calls updateHook
[...]
>>>
>>> Why is that? And what is so portable about your likings? :-)
>>
>> Because it nicely separates what happens for every EventPort
>> individually without cluttering UpdateHook().
>
> Oops! You have your "separation of concerns" wrong: the "UpdateHook()"
> _belongs_ to the Component (that is, it can access all its data), the event
> handler should not.
The suggested way, as explained in the orocos documentation (orocos
component manual, p. 30), is to do the, what you are calling event
handling, in UpdateHook(). The way I see it is:
- orocos is already taking care of the event handling: it catches it
when something happened and it will wake up my component
- inside my component, I react to that wake up call and do event
processing / decision making.
>
>>> I do repeat that you are _violating_ separations of concerns by including
>>> "separate methods for every EventPort"! The event port has to do nothing
>>> more than getting events; _any_ interpretation of the events _has_ to take
>>> place within the component that is subscribed to the event.
>>
>> This is how it works now! The interpretation of the Events happens in
>> the individual methods, which are part of the Controller component,
>> subscribed to the event.
>
> It's the "part of" part that I do not like: an event handler should _not_
> be "part of" a Controller component; they should just set/get the minimal
> amount of data (related to the _taking place_ of the event, not of the
> _interpretation_ of the event), and that's it.
>
>>>> I know there are various solutions, just wondering which is the best one...
>>>
>>> Orocos was created with two definitions of "best" in mind:
>>> - more reusable is better, and
>>> - more realtime safe is better.
>>> Mind you, _not_ with "faster is better" as a criterion!
>>>
>>> Your approach does not satisfy any of those two criterions. (The latter one
>>> is obvious, if you think about a reuse in accelerated hardware, where your
>>> event handlers could be real Interrupt Service Routines.)
>>>
>>>>>> I know it's not a terrible thing UpdateHook() get's called here as
>>>>>> well, but it makes the watchdog pretty intrusive, which is not how it
>>>>>> should be.
>>>>>
>>>>> What do you mean with "pretty intrusive"? And watchdogs _should_ be
>>>>> "intrusive" since that's the key essence of their existence :-)
>>>>
>>>> It should monitor, in this case, the measurement update frequency, but
>>>> as long as everything goes well, it's influence should be as minimal
>>>> as possible (only the EventPort method execution).
>>>> It should only make it's presence felt the moment the measurements go wrong.
>>>
>>> No: violation of SoC... No event handler should have to know anything about
>>> when something is right or wrong for the Component it is attached to.
>>> Never!
>>
>> Again, this interpretation is already done _inside_ the Controller component.
>
> As far as I understand your design, "being done inside the Controller
> component" means nothing else but "calling a function of the controller
> component", right? That's not the same thing as decoupling:
> - an event handler should not know about which functions are available in a
> component.
> - calling the same function from different threads/contexts can make a big
> semantic difference, so it is not only important to keep the (decision
> making) function that is called in the component, but also to do the
> calling itself in the component's thread.
The function which gets called _is_ part of the Controller component.
Do I misunderstand this?
Steven
> Maybe (probably) your case _is_ single threaded (and hence does not show
> any difference wrt to second argument), but that is then a coincidence of
> your particular deployment.
>
> I can be wrong about all my interpretations about what I think your design
> is doing, so please tell me if that's indeed the case :-)
>
> Herman
>
EventPort with custom method calls updateHook
On Sun, 20 Mar 2011, Steven Bellens wrote:
> [...]
>>>>
>>>> Why is that? And what is so portable about your likings? :-)
>>>
>>> Because it nicely separates what happens for every EventPort
>>> individually without cluttering UpdateHook().
>>
>> Oops! You have your "separation of concerns" wrong: the "UpdateHook()"
>> _belongs_ to the Component (that is, it can access all its data), the event
>> handler should not.
>
> The suggested way, as explained in the orocos documentation (orocos
> component manual, p. 30), is to do the, what you are calling event
> handling, in UpdateHook().
That's indeed what I am advocating.
> The way I see it is:
> - orocos is already taking care of the event handling: it catches it
> when something happened and it will wake up my component
> - inside my component, I react to that wake up call and do event
> processing / decision making.
Yes.
>>>> I do repeat that you are _violating_ separations of concerns by including
>>>> "separate methods for every EventPort"! The event port has to do nothing
>>>> more than getting events; _any_ interpretation of the events _has_ to take
>>>> place within the component that is subscribed to the event.
>>>
>>> This is how it works now! The interpretation of the Events happens in
>>> the individual methods, which are part of the Controller component,
>>> subscribed to the event.
>>
>> It's the "part of" part that I do not like: an event handler should _not_
>> be "part of" a Controller component; they should just set/get the minimal
>> amount of data (related to the _taking place_ of the event, not of the
>> _interpretation_ of the event), and that's it.
>>
>>>>> I know there are various solutions, just wondering which is the best one...
>>>>
>>>> Orocos was created with two definitions of "best" in mind:
>>>> - more reusable is better, and
>>>> - more realtime safe is better.
>>>> Mind you, _not_ with "faster is better" as a criterion!
>>>>
>>>> Your approach does not satisfy any of those two criterions. (The latter one
>>>> is obvious, if you think about a reuse in accelerated hardware, where your
>>>> event handlers could be real Interrupt Service Routines.)
>>>>
>>>>>>> I know it's not a terrible thing UpdateHook() get's called here as
>>>>>>> well, but it makes the watchdog pretty intrusive, which is not how it
>>>>>>> should be.
>>>>>>
>>>>>> What do you mean with "pretty intrusive"? And watchdogs _should_ be
>>>>>> "intrusive" since that's the key essence of their existence :-)
>>>>>
>>>>> It should monitor, in this case, the measurement update frequency, but
>>>>> as long as everything goes well, it's influence should be as minimal
>>>>> as possible (only the EventPort method execution).
>>>>> It should only make it's presence felt the moment the measurements go wrong.
>>>>
>>>> No: violation of SoC... No event handler should have to know anything about
>>>> when something is right or wrong for the Component it is attached to.
>>>> Never!
>>>
>>> Again, this interpretation is already done _inside_ the Controller component.
>>
>> As far as I understand your design, "being done inside the Controller
>> component" means nothing else but "calling a function of the controller
>> component", right? That's not the same thing as decoupling:
>> - an event handler should not know about which functions are available in a
>> component.
>> - calling the same function from different threads/contexts can make a big
>> semantic difference, so it is not only important to keep the (decision
>> making) function that is called in the component, but also to do the
>> calling itself in the component's thread.
>
> The function which gets called _is_ part of the Controller component.
> Do I misunderstand this?
No, you don't misunderstand that. But you are probably not so aware of the
importance of the _context_ (to be interpreted in its operating systems
meaning) in which that event handling function is called. It should be
called in the process context in which the Component is also executing, so
that it can access everything that is important for the component (and vice
versa: the Component has access to everthing the event handling function
does). A problem can indeed arise when the event handling function is
called in, say, the thread of the communication middleware that the
EventPort is using: if that thread is different from the thread of the
component's Computation, there is a danger for race conditions, or other
nasty concurrency behaviour; it can be even worse if Communication and
Computation are run in different processes.
This is difficult material, I know...
> Steven
>
>> Maybe (probably) your case _is_ single threaded (and hence does not show
>> any difference wrt to second argument), but that is then a coincidence of
>> your particular deployment.
>>
>> I can be wrong about all my interpretations about what I think your design
>> is doing, so please tell me if that's indeed the case :-)
Herman
EventPort with custom method calls updateHook
On Sun, 20 Mar 2011, Steven Bellens wrote:
> [...]
>>>>
>>>> Why is that? And what is so portable about your likings? :-)
>>>
>>> Because it nicely separates what happens for every EventPort
>>> individually without cluttering UpdateHook().
>>
>> Oops! You have your "separation of concerns" wrong: the "UpdateHook()"
>> _belongs_ to the Component (that is, it can access all its data), the event
>> handler should not.
>
> The suggested way, as explained in the orocos documentation (orocos
> component manual, p. 30), is to do the, what you are calling event
> handling, in UpdateHook().
That's indeed what I am advocating.
> The way I see it is:
> - orocos is already taking care of the event handling: it catches it
> when something happened and it will wake up my component
> - inside my component, I react to that wake up call and do event
> processing / decision making.
Yes.
>>>> I do repeat that you are _violating_ separations of concerns by including
>>>> "separate methods for every EventPort"! The event port has to do nothing
>>>> more than getting events; _any_ interpretation of the events _has_ to take
>>>> place within the component that is subscribed to the event.
>>>
>>> This is how it works now! The interpretation of the Events happens in
>>> the individual methods, which are part of the Controller component,
>>> subscribed to the event.
>>
>> It's the "part of" part that I do not like: an event handler should _not_
>> be "part of" a Controller component; they should just set/get the minimal
>> amount of data (related to the _taking place_ of the event, not of the
>> _interpretation_ of the event), and that's it.
>>
>>>>> I know there are various solutions, just wondering which is the best one...
>>>>
>>>> Orocos was created with two definitions of "best" in mind:
>>>> - more reusable is better, and
>>>> - more realtime safe is better.
>>>> Mind you, _not_ with "faster is better" as a criterion!
>>>>
>>>> Your approach does not satisfy any of those two criterions. (The latter one
>>>> is obvious, if you think about a reuse in accelerated hardware, where your
>>>> event handlers could be real Interrupt Service Routines.)
>>>>
>>>>>>> I know it's not a terrible thing UpdateHook() get's called here as
>>>>>>> well, but it makes the watchdog pretty intrusive, which is not how it
>>>>>>> should be.
>>>>>>
>>>>>> What do you mean with "pretty intrusive"? And watchdogs _should_ be
>>>>>> "intrusive" since that's the key essence of their existence :-)
>>>>>
>>>>> It should monitor, in this case, the measurement update frequency, but
>>>>> as long as everything goes well, it's influence should be as minimal
>>>>> as possible (only the EventPort method execution).
>>>>> It should only make it's presence felt the moment the measurements go wrong.
>>>>
>>>> No: violation of SoC... No event handler should have to know anything about
>>>> when something is right or wrong for the Component it is attached to.
>>>> Never!
>>>
>>> Again, this interpretation is already done _inside_ the Controller component.
>>
>> As far as I understand your design, "being done inside the Controller
>> component" means nothing else but "calling a function of the controller
>> component", right? That's not the same thing as decoupling:
>> - an event handler should not know about which functions are available in a
>> component.
>> - calling the same function from different threads/contexts can make a big
>> semantic difference, so it is not only important to keep the (decision
>> making) function that is called in the component, but also to do the
>> calling itself in the component's thread.
>
> The function which gets called _is_ part of the Controller component.
> Do I misunderstand this?
No, you don't misunderstand that. But you are probably not so aware of the
importance of the _context_ (to be interpreted in its operating systems
meaning) in which that event handling function is called. It should be
called in the process context in which the Component is also executing, so
that it can access everything that is important for the component (and vice
versa: the Component has access to everthing the event handling function
does). A problem can indeed arise when the event handling function is
called in, say, the thread of the communication middleware that the
EventPort is using: if that thread is different from the thread of the
component's Computation, there is a danger for race conditions, or other
nasty concurrency behaviour; it can be even worse if Communication and
Computation are run in different processes.
This is difficult material, I know...
> Steven
>
>> Maybe (probably) your case _is_ single threaded (and hence does not show
>> any difference wrt to second argument), but that is then a coincidence of
>> your particular deployment.
>>
>> I can be wrong about all my interpretations about what I think your design
>> is doing, so please tell me if that's indeed the case :-)
Herman
EventPort with custom method calls updateHook
2011/3/20 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
> On Sun, 20 Mar 2011, Steven Bellens wrote:
>
>> [...]
>>>>>
>>>>> Why is that? And what is so portable about your likings? :-)
>>>>
>>>> Because it nicely separates what happens for every EventPort
>>>> individually without cluttering UpdateHook().
>>>
>>> Oops! You have your "separation of concerns" wrong: the "UpdateHook()"
>>> _belongs_ to the Component (that is, it can access all its data), the event
>>> handler should not.
>>
>> The suggested way, as explained in the orocos documentation (orocos
>> component manual, p. 30), is to do the, what you are calling event
>> handling, in UpdateHook().
>
> That's indeed what I am advocating.
This looks contradictory to me: you say the event handler should not
be part of the component on one side, but it needs to be done in
UpdateHook() on the other side.
>
>> The way I see it is:
>> - orocos is already taking care of the event handling: it catches it
>> when something happened and it will wake up my component
>> - inside my component, I react to that wake up call and do event
>> processing / decision making.
>
> Yes.
>
>>>>> I do repeat that you are _violating_ separations of concerns by including
>>>>> "separate methods for every EventPort"! The event port has to do nothing
>>>>> more than getting events; _any_ interpretation of the events _has_ to take
>>>>> place within the component that is subscribed to the event.
>>>>
>>>> This is how it works now! The interpretation of the Events happens in
>>>> the individual methods, which are part of the Controller component,
>>>> subscribed to the event.
>>>
>>> It's the "part of" part that I do not like: an event handler should _not_
>>> be "part of" a Controller component; they should just set/get the minimal
>>> amount of data (related to the _taking place_ of the event, not of the
>>> _interpretation_ of the event), and that's it.
>>>
>>>>>> I know there are various solutions, just wondering which is the best one...
>>>>>
>>>>> Orocos was created with two definitions of "best" in mind:
>>>>> - more reusable is better, and
>>>>> - more realtime safe is better.
>>>>> Mind you, _not_ with "faster is better" as a criterion!
>>>>>
>>>>> Your approach does not satisfy any of those two criterions. (The latter one
>>>>> is obvious, if you think about a reuse in accelerated hardware, where your
>>>>> event handlers could be real Interrupt Service Routines.)
>>>>>
>>>>>>>> I know it's not a terrible thing UpdateHook() get's called here as
>>>>>>>> well, but it makes the watchdog pretty intrusive, which is not how it
>>>>>>>> should be.
>>>>>>>
>>>>>>> What do you mean with "pretty intrusive"? And watchdogs _should_ be
>>>>>>> "intrusive" since that's the key essence of their existence :-)
>>>>>>
>>>>>> It should monitor, in this case, the measurement update frequency, but
>>>>>> as long as everything goes well, it's influence should be as minimal
>>>>>> as possible (only the EventPort method execution).
>>>>>> It should only make it's presence felt the moment the measurements go wrong.
>>>>>
>>>>> No: violation of SoC... No event handler should have to know anything about
>>>>> when something is right or wrong for the Component it is attached to.
>>>>> Never!
>>>>
>>>> Again, this interpretation is already done _inside_ the Controller component.
>>>
>>> As far as I understand your design, "being done inside the Controller
>>> component" means nothing else but "calling a function of the controller
>>> component", right? That's not the same thing as decoupling:
>>> - an event handler should not know about which functions are available in a
>>> component.
>>> - calling the same function from different threads/contexts can make a big
>>> semantic difference, so it is not only important to keep the (decision
>>> making) function that is called in the component, but also to do the
>>> calling itself in the component's thread.
>>
>> The function which gets called _is_ part of the Controller component.
>> Do I misunderstand this?
>
> No, you don't misunderstand that. But you are probably not so aware of the
> importance of the _context_ (to be interpreted in its operating systems
> meaning) in which that event handling function is called. It should be
> called in the process context in which the Component is also executing, so
> that it can access everything that is important for the component (and vice
> versa: the Component has access to everthing the event handling function
> does). A problem can indeed arise when the event handling function is
> called in, say, the thread of the communication middleware that the
> EventPort is using: if that thread is different from the thread of the
> component's Computation, there is a danger for race conditions, or other
> nasty concurrency behaviour; it can be even worse if Communication and
> Computation are run in different processes.
>
> This is difficult material, I know...
I'm getting back to my first question. I still don't see why every
event or (I found out operations do the same) every operation needs to
call UpdateHook().
The component indeed always needs to _react_ to an event / operation,
but this reaction is already done in the event / operation method, and
that does not _always_ need an UpdateHook() run as well.
Steven
>> Steven
>>
>>> Maybe (probably) your case _is_ single threaded (and hence does not show
>>> any difference wrt to second argument), but that is then a coincidence of
>>> your particular deployment.
>>>
>>> I can be wrong about all my interpretations about what I think your design
>>> is doing, so please tell me if that's indeed the case :-)
>
> Herman
EventPort with custom method calls updateHook
2011/3/20 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
> On Sun, 20 Mar 2011, Steven Bellens wrote:
>
>> [...]
>>>>>
>>>>> Why is that? And what is so portable about your likings? :-)
>>>>
>>>> Because it nicely separates what happens for every EventPort
>>>> individually without cluttering UpdateHook().
>>>
>>> Oops! You have your "separation of concerns" wrong: the "UpdateHook()"
>>> _belongs_ to the Component (that is, it can access all its data), the event
>>> handler should not.
>>
>> The suggested way, as explained in the orocos documentation (orocos
>> component manual, p. 30), is to do the, what you are calling event
>> handling, in UpdateHook().
>
> That's indeed what I am advocating.
This looks contradictory to me: you say the event handler should not
be part of the component on one side, but it needs to be done in
UpdateHook() on the other side.
>
>> The way I see it is:
>> - orocos is already taking care of the event handling: it catches it
>> when something happened and it will wake up my component
>> - inside my component, I react to that wake up call and do event
>> processing / decision making.
>
> Yes.
>
>>>>> I do repeat that you are _violating_ separations of concerns by including
>>>>> "separate methods for every EventPort"! The event port has to do nothing
>>>>> more than getting events; _any_ interpretation of the events _has_ to take
>>>>> place within the component that is subscribed to the event.
>>>>
>>>> This is how it works now! The interpretation of the Events happens in
>>>> the individual methods, which are part of the Controller component,
>>>> subscribed to the event.
>>>
>>> It's the "part of" part that I do not like: an event handler should _not_
>>> be "part of" a Controller component; they should just set/get the minimal
>>> amount of data (related to the _taking place_ of the event, not of the
>>> _interpretation_ of the event), and that's it.
>>>
>>>>>> I know there are various solutions, just wondering which is the best one...
>>>>>
>>>>> Orocos was created with two definitions of "best" in mind:
>>>>> - more reusable is better, and
>>>>> - more realtime safe is better.
>>>>> Mind you, _not_ with "faster is better" as a criterion!
>>>>>
>>>>> Your approach does not satisfy any of those two criterions. (The latter one
>>>>> is obvious, if you think about a reuse in accelerated hardware, where your
>>>>> event handlers could be real Interrupt Service Routines.)
>>>>>
>>>>>>>> I know it's not a terrible thing UpdateHook() get's called here as
>>>>>>>> well, but it makes the watchdog pretty intrusive, which is not how it
>>>>>>>> should be.
>>>>>>>
>>>>>>> What do you mean with "pretty intrusive"? And watchdogs _should_ be
>>>>>>> "intrusive" since that's the key essence of their existence :-)
>>>>>>
>>>>>> It should monitor, in this case, the measurement update frequency, but
>>>>>> as long as everything goes well, it's influence should be as minimal
>>>>>> as possible (only the EventPort method execution).
>>>>>> It should only make it's presence felt the moment the measurements go wrong.
>>>>>
>>>>> No: violation of SoC... No event handler should have to know anything about
>>>>> when something is right or wrong for the Component it is attached to.
>>>>> Never!
>>>>
>>>> Again, this interpretation is already done _inside_ the Controller component.
>>>
>>> As far as I understand your design, "being done inside the Controller
>>> component" means nothing else but "calling a function of the controller
>>> component", right? That's not the same thing as decoupling:
>>> - an event handler should not know about which functions are available in a
>>> component.
>>> - calling the same function from different threads/contexts can make a big
>>> semantic difference, so it is not only important to keep the (decision
>>> making) function that is called in the component, but also to do the
>>> calling itself in the component's thread.
>>
>> The function which gets called _is_ part of the Controller component.
>> Do I misunderstand this?
>
> No, you don't misunderstand that. But you are probably not so aware of the
> importance of the _context_ (to be interpreted in its operating systems
> meaning) in which that event handling function is called. It should be
> called in the process context in which the Component is also executing, so
> that it can access everything that is important for the component (and vice
> versa: the Component has access to everthing the event handling function
> does). A problem can indeed arise when the event handling function is
> called in, say, the thread of the communication middleware that the
> EventPort is using: if that thread is different from the thread of the
> component's Computation, there is a danger for race conditions, or other
> nasty concurrency behaviour; it can be even worse if Communication and
> Computation are run in different processes.
>
> This is difficult material, I know...
I'm getting back to my first question. I still don't see why every
event or (I found out operations do the same) every operation needs to
call UpdateHook().
The component indeed always needs to _react_ to an event / operation,
but this reaction is already done in the event / operation method, and
that does not _always_ need an UpdateHook() run as well.
Steven
>> Steven
>>
>>> Maybe (probably) your case _is_ single threaded (and hence does not show
>>> any difference wrt to second argument), but that is then a coincidence of
>>> your particular deployment.
>>>
>>> I can be wrong about all my interpretations about what I think your design
>>> is doing, so please tell me if that's indeed the case :-)
>
> Herman
EventPort with custom method calls updateHook
On Sun, 20 Mar 2011, Steven Bellens wrote:
> 2011/3/20 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
>> On Sun, 20 Mar 2011, Steven Bellens wrote:
>>
>>> [...]
>>>>>>
>>>>>> Why is that? And what is so portable about your likings? :-)
>>>>>
>>>>> Because it nicely separates what happens for every EventPort
>>>>> individually without cluttering UpdateHook().
>>>>
>>>> Oops! You have your "separation of concerns" wrong: the "UpdateHook()"
>>>> _belongs_ to the Component (that is, it can access all its data), the event
>>>> handler should not.
>>>
>>> The suggested way, as explained in the orocos documentation (orocos
>>> component manual, p. 30), is to do the, what you are calling event
>>> handling, in UpdateHook().
>>
>> That's indeed what I am advocating.
>
> This looks contradictory to me: you say the event handler should not
> be part of the component on one side, but it needs to be done in
> UpdateHook() on the other side.
Oops, I used some incompletely defined terminology; let me make myself
clear
- "event handling" = the immediate reaction to an event; must be done by
the component/thread that notices the event. (In your case: in the
EventPort.)
- "event completion" = the not (necessarily) immediate reaction to the
event, by the component/thread for which the event was destined.
(In your case: taking the decision about whether or not to stop the
ongoing control.)
The _code_ for both can be part of the code of the component, but the
_execution context_ is, in general, different: the "handling" takes place
in the thread of the "event noticer", the "completion" takes place in the
thread of the component for which the event was destined. In
single-threaded environments, there is no difference.
>>> The way I see it is:
>>> - orocos is already taking care of the event handling: it catches it
>>> when something happened and it will wake up my component
>>> - inside my component, I react to that wake up call and do event
>>> processing / decision making.
>>
>> Yes.
>>
>>>>>> I do repeat that you are _violating_ separations of concerns by including
>>>>>> "separate methods for every EventPort"! The event port has to do nothing
>>>>>> more than getting events; _any_ interpretation of the events _has_ to take
>>>>>> place within the component that is subscribed to the event.
>>>>>
>>>>> This is how it works now! The interpretation of the Events happens in
>>>>> the individual methods, which are part of the Controller component,
>>>>> subscribed to the event.
>>>>
>>>> It's the "part of" part that I do not like: an event handler should _not_
>>>> be "part of" a Controller component; they should just set/get the minimal
>>>> amount of data (related to the _taking place_ of the event, not of the
>>>> _interpretation_ of the event), and that's it.
>>>>
>>>>>>> I know there are various solutions, just wondering which is the best one...
>>>>>>
>>>>>> Orocos was created with two definitions of "best" in mind:
>>>>>> - more reusable is better, and
>>>>>> - more realtime safe is better.
>>>>>> Mind you, _not_ with "faster is better" as a criterion!
>>>>>>
>>>>>> Your approach does not satisfy any of those two criterions. (The latter one
>>>>>> is obvious, if you think about a reuse in accelerated hardware, where your
>>>>>> event handlers could be real Interrupt Service Routines.)
>>>>>>
>>>>>>>>> I know it's not a terrible thing UpdateHook() get's called here as
>>>>>>>>> well, but it makes the watchdog pretty intrusive, which is not how it
>>>>>>>>> should be.
>>>>>>>>
>>>>>>>> What do you mean with "pretty intrusive"? And watchdogs _should_ be
>>>>>>>> "intrusive" since that's the key essence of their existence :-)
>>>>>>>
>>>>>>> It should monitor, in this case, the measurement update frequency, but
>>>>>>> as long as everything goes well, it's influence should be as minimal
>>>>>>> as possible (only the EventPort method execution).
>>>>>>> It should only make it's presence felt the moment the measurements go wrong.
>>>>>>
>>>>>> No: violation of SoC... No event handler should have to know anything about
>>>>>> when something is right or wrong for the Component it is attached to.
>>>>>> Never!
>>>>>
>>>>> Again, this interpretation is already done _inside_ the Controller component.
>>>>
>>>> As far as I understand your design, "being done inside the Controller
>>>> component" means nothing else but "calling a function of the controller
>>>> component", right? That's not the same thing as decoupling:
>>>> - an event handler should not know about which functions are available in a
>>>> component.
>>>> - calling the same function from different threads/contexts can make a big
>>>> semantic difference, so it is not only important to keep the (decision
>>>> making) function that is called in the component, but also to do the
>>>> calling itself in the component's thread.
>>>
>>> The function which gets called _is_ part of the Controller component.
>>> Do I misunderstand this?
>>
>> No, you don't misunderstand that. But you are probably not so aware of the
>> importance of the _context_ (to be interpreted in its operating systems
>> meaning) in which that event handling function is called. It should be
>> called in the process context in which the Component is also executing, so
>> that it can access everything that is important for the component (and vice
>> versa: the Component has access to everthing the event handling function
>> does). A problem can indeed arise when the event handling function is
>> called in, say, the thread of the communication middleware that the
>> EventPort is using: if that thread is different from the thread of the
>> component's Computation, there is a danger for race conditions, or other
>> nasty concurrency behaviour; it can be even worse if Communication and
>> Computation are run in different processes.
>>
>> This is difficult material, I know...
>
> I'm getting back to my first question. I still don't see why every
> event or (I found out operations do the same) every operation needs to
> call UpdateHook().
_If_ a component has decided to register to an event, that means that it
_wants_ to do _something_ which each event that it receives. That also
means that it must get the opportunity to "run" as soon as its thread is
ready to do so.
> The component indeed always needs to _react_ to an event / operation,
> but this reaction is already done in the event / operation method, and
> that does not _always_ need an UpdateHook() run as well.
Have you understood the 'race conditions' that can occur if the "event
handler" also does the "completion"?
Page 42 and following of my RealTime and Embedded Howto (terribly outdated
in many respects, sigh...) give more technical details about "event
handling": <people.mech.kuleuven.be/~bruyninc/rthowto/rtHOWTO.pdf>
Herman
EventPort with custom method calls updateHook
On Sun, 20 Mar 2011, Steven Bellens wrote:
> 2011/3/20 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
>> On Sun, 20 Mar 2011, Steven Bellens wrote:
>>
>>> [...]
>>>>>>
>>>>>> Why is that? And what is so portable about your likings? :-)
>>>>>
>>>>> Because it nicely separates what happens for every EventPort
>>>>> individually without cluttering UpdateHook().
>>>>
>>>> Oops! You have your "separation of concerns" wrong: the "UpdateHook()"
>>>> _belongs_ to the Component (that is, it can access all its data), the event
>>>> handler should not.
>>>
>>> The suggested way, as explained in the orocos documentation (orocos
>>> component manual, p. 30), is to do the, what you are calling event
>>> handling, in UpdateHook().
>>
>> That's indeed what I am advocating.
>
> This looks contradictory to me: you say the event handler should not
> be part of the component on one side, but it needs to be done in
> UpdateHook() on the other side.
Oops, I used some incompletely defined terminology; let me make myself
clear
- "event handling" = the immediate reaction to an event; must be done by
the component/thread that notices the event. (In your case: in the
EventPort.)
- "event completion" = the not (necessarily) immediate reaction to the
event, by the component/thread for which the event was destined.
(In your case: taking the decision about whether or not to stop the
ongoing control.)
The _code_ for both can be part of the code of the component, but the
_execution context_ is, in general, different: the "handling" takes place
in the thread of the "event noticer", the "completion" takes place in the
thread of the component for which the event was destined. In
single-threaded environments, there is no difference.
>>> The way I see it is:
>>> - orocos is already taking care of the event handling: it catches it
>>> when something happened and it will wake up my component
>>> - inside my component, I react to that wake up call and do event
>>> processing / decision making.
>>
>> Yes.
>>
>>>>>> I do repeat that you are _violating_ separations of concerns by including
>>>>>> "separate methods for every EventPort"! The event port has to do nothing
>>>>>> more than getting events; _any_ interpretation of the events _has_ to take
>>>>>> place within the component that is subscribed to the event.
>>>>>
>>>>> This is how it works now! The interpretation of the Events happens in
>>>>> the individual methods, which are part of the Controller component,
>>>>> subscribed to the event.
>>>>
>>>> It's the "part of" part that I do not like: an event handler should _not_
>>>> be "part of" a Controller component; they should just set/get the minimal
>>>> amount of data (related to the _taking place_ of the event, not of the
>>>> _interpretation_ of the event), and that's it.
>>>>
>>>>>>> I know there are various solutions, just wondering which is the best one...
>>>>>>
>>>>>> Orocos was created with two definitions of "best" in mind:
>>>>>> - more reusable is better, and
>>>>>> - more realtime safe is better.
>>>>>> Mind you, _not_ with "faster is better" as a criterion!
>>>>>>
>>>>>> Your approach does not satisfy any of those two criterions. (The latter one
>>>>>> is obvious, if you think about a reuse in accelerated hardware, where your
>>>>>> event handlers could be real Interrupt Service Routines.)
>>>>>>
>>>>>>>>> I know it's not a terrible thing UpdateHook() get's called here as
>>>>>>>>> well, but it makes the watchdog pretty intrusive, which is not how it
>>>>>>>>> should be.
>>>>>>>>
>>>>>>>> What do you mean with "pretty intrusive"? And watchdogs _should_ be
>>>>>>>> "intrusive" since that's the key essence of their existence :-)
>>>>>>>
>>>>>>> It should monitor, in this case, the measurement update frequency, but
>>>>>>> as long as everything goes well, it's influence should be as minimal
>>>>>>> as possible (only the EventPort method execution).
>>>>>>> It should only make it's presence felt the moment the measurements go wrong.
>>>>>>
>>>>>> No: violation of SoC... No event handler should have to know anything about
>>>>>> when something is right or wrong for the Component it is attached to.
>>>>>> Never!
>>>>>
>>>>> Again, this interpretation is already done _inside_ the Controller component.
>>>>
>>>> As far as I understand your design, "being done inside the Controller
>>>> component" means nothing else but "calling a function of the controller
>>>> component", right? That's not the same thing as decoupling:
>>>> - an event handler should not know about which functions are available in a
>>>> component.
>>>> - calling the same function from different threads/contexts can make a big
>>>> semantic difference, so it is not only important to keep the (decision
>>>> making) function that is called in the component, but also to do the
>>>> calling itself in the component's thread.
>>>
>>> The function which gets called _is_ part of the Controller component.
>>> Do I misunderstand this?
>>
>> No, you don't misunderstand that. But you are probably not so aware of the
>> importance of the _context_ (to be interpreted in its operating systems
>> meaning) in which that event handling function is called. It should be
>> called in the process context in which the Component is also executing, so
>> that it can access everything that is important for the component (and vice
>> versa: the Component has access to everthing the event handling function
>> does). A problem can indeed arise when the event handling function is
>> called in, say, the thread of the communication middleware that the
>> EventPort is using: if that thread is different from the thread of the
>> component's Computation, there is a danger for race conditions, or other
>> nasty concurrency behaviour; it can be even worse if Communication and
>> Computation are run in different processes.
>>
>> This is difficult material, I know...
>
> I'm getting back to my first question. I still don't see why every
> event or (I found out operations do the same) every operation needs to
> call UpdateHook().
_If_ a component has decided to register to an event, that means that it
_wants_ to do _something_ which each event that it receives. That also
means that it must get the opportunity to "run" as soon as its thread is
ready to do so.
> The component indeed always needs to _react_ to an event / operation,
> but this reaction is already done in the event / operation method, and
> that does not _always_ need an UpdateHook() run as well.
Have you understood the 'race conditions' that can occur if the "event
handler" also does the "completion"?
Page 42 and following of my RealTime and Embedded Howto (terribly outdated
in many respects, sigh...) give more technical details about "event
handling": <people.mech.kuleuven.be/~bruyninc/rthowto/rtHOWTO.pdf>
Herman
EventPort with custom method calls updateHook
2011/3/20 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
> On Sun, 20 Mar 2011, Steven Bellens wrote:
>
>> 2011/3/20 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
>>> On Sun, 20 Mar 2011, Steven Bellens wrote:
>>>
>>>> [...]
>>>>>>>
>>>>>>> Why is that? And what is so portable about your likings? :-)
>>>>>>
>>>>>> Because it nicely separates what happens for every EventPort
>>>>>> individually without cluttering UpdateHook().
>>>>>
>>>>> Oops! You have your "separation of concerns" wrong: the "UpdateHook()"
>>>>> _belongs_ to the Component (that is, it can access all its data), the event
>>>>> handler should not.
>>>>
>>>> The suggested way, as explained in the orocos documentation (orocos
>>>> component manual, p. 30), is to do the, what you are calling event
>>>> handling, in UpdateHook().
>>>
>>> That's indeed what I am advocating.
>>
>> This looks contradictory to me: you say the event handler should not
>> be part of the component on one side, but it needs to be done in
>> UpdateHook() on the other side.
>
> Oops, I used some incompletely defined terminology; let me make myself
> clear
> - "event handling" = the immediate reaction to an event; must be done by
> the component/thread that notices the event. (In your case: in the
> EventPort.)
> - "event completion" = the not (necessarily) immediate reaction to the
> event, by the component/thread for which the event was destined.
> (In your case: taking the decision about whether or not to stop the
> ongoing control.)
> The _code_ for both can be part of the code of the component, but the
> _execution context_ is, in general, different: the "handling" takes place
> in the thread of the "event noticer", the "completion" takes place in the
> thread of the component for which the event was destined. In
> single-threaded environments, there is no difference.
Agree!
>
>>>> The way I see it is:
>>>> - orocos is already taking care of the event handling: it catches it
>>>> when something happened and it will wake up my component
>>>> - inside my component, I react to that wake up call and do event
>>>> processing / decision making.
>>>
>>> Yes.
>>>
>>>>>>> I do repeat that you are _violating_ separations of concerns by including
>>>>>>> "separate methods for every EventPort"! The event port has to do nothing
>>>>>>> more than getting events; _any_ interpretation of the events _has_ to take
>>>>>>> place within the component that is subscribed to the event.
>>>>>>
>>>>>> This is how it works now! The interpretation of the Events happens in
>>>>>> the individual methods, which are part of the Controller component,
>>>>>> subscribed to the event.
>>>>>
>>>>> It's the "part of" part that I do not like: an event handler should _not_
>>>>> be "part of" a Controller component; they should just set/get the minimal
>>>>> amount of data (related to the _taking place_ of the event, not of the
>>>>> _interpretation_ of the event), and that's it.
>>>>>
>>>>>>>> I know there are various solutions, just wondering which is the best one...
>>>>>>>
>>>>>>> Orocos was created with two definitions of "best" in mind:
>>>>>>> - more reusable is better, and
>>>>>>> - more realtime safe is better.
>>>>>>> Mind you, _not_ with "faster is better" as a criterion!
>>>>>>>
>>>>>>> Your approach does not satisfy any of those two criterions. (The latter one
>>>>>>> is obvious, if you think about a reuse in accelerated hardware, where your
>>>>>>> event handlers could be real Interrupt Service Routines.)
>>>>>>>
>>>>>>>>>> I know it's not a terrible thing UpdateHook() get's called here as
>>>>>>>>>> well, but it makes the watchdog pretty intrusive, which is not how it
>>>>>>>>>> should be.
>>>>>>>>>
>>>>>>>>> What do you mean with "pretty intrusive"? And watchdogs _should_ be
>>>>>>>>> "intrusive" since that's the key essence of their existence :-)
>>>>>>>>
>>>>>>>> It should monitor, in this case, the measurement update frequency, but
>>>>>>>> as long as everything goes well, it's influence should be as minimal
>>>>>>>> as possible (only the EventPort method execution).
>>>>>>>> It should only make it's presence felt the moment the measurements go wrong.
>>>>>>>
>>>>>>> No: violation of SoC... No event handler should have to know anything about
>>>>>>> when something is right or wrong for the Component it is attached to.
>>>>>>> Never!
>>>>>>
>>>>>> Again, this interpretation is already done _inside_ the Controller component.
>>>>>
>>>>> As far as I understand your design, "being done inside the Controller
>>>>> component" means nothing else but "calling a function of the controller
>>>>> component", right? That's not the same thing as decoupling:
>>>>> - an event handler should not know about which functions are available in a
>>>>> component.
>>>>> - calling the same function from different threads/contexts can make a big
>>>>> semantic difference, so it is not only important to keep the (decision
>>>>> making) function that is called in the component, but also to do the
>>>>> calling itself in the component's thread.
>>>>
>>>> The function which gets called _is_ part of the Controller component.
>>>> Do I misunderstand this?
>>>
>>> No, you don't misunderstand that. But you are probably not so aware of the
>>> importance of the _context_ (to be interpreted in its operating systems
>>> meaning) in which that event handling function is called. It should be
>>> called in the process context in which the Component is also executing, so
>>> that it can access everything that is important for the component (and vice
>>> versa: the Component has access to everthing the event handling function
>>> does). A problem can indeed arise when the event handling function is
>>> called in, say, the thread of the communication middleware that the
>>> EventPort is using: if that thread is different from the thread of the
>>> component's Computation, there is a danger for race conditions, or other
>>> nasty concurrency behaviour; it can be even worse if Communication and
>>> Computation are run in different processes.
>>>
>>> This is difficult material, I know...
>>
>> I'm getting back to my first question. I still don't see why every
>> event or (I found out operations do the same) every operation needs to
>> call UpdateHook().
>
> _If_ a component has decided to register to an event, that means that it
> _wants_ to do _something_ which each event that it receives. That also
> means that it must get the opportunity to "run" as soon as its thread is
> ready to do so.
"Having the opportunity to run" is not really the same as
automatically running after every event notice. That's exactly my
point: It _can_ run, but does not _need_ to.
>
>> The component indeed always needs to _react_ to an event / operation,
>> but this reaction is already done in the event / operation method, and
>> that does not _always_ need an UpdateHook() run as well.
>
> Have you understood the 'race conditions' that can occur if the "event
> handler" also does the "completion"?
I won't say I 'master' the subject :), but I see things can go wrong
in the situation you explained.
Steven
> Page 42 and following of my RealTime and Embedded Howto (terribly outdated
> in many respects, sigh...) give more technical details about "event
> handling": <people.mech.kuleuven.be/~bruyninc/rthowto/rtHOWTO.pdf>
>
> Herman
EventPort with custom method calls updateHook
2011/3/20 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
> On Sun, 20 Mar 2011, Steven Bellens wrote:
>
>> 2011/3/20 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
>>> On Sun, 20 Mar 2011, Steven Bellens wrote:
>>>
>>>> [...]
>>>>>>>
>>>>>>> Why is that? And what is so portable about your likings? :-)
>>>>>>
>>>>>> Because it nicely separates what happens for every EventPort
>>>>>> individually without cluttering UpdateHook().
>>>>>
>>>>> Oops! You have your "separation of concerns" wrong: the "UpdateHook()"
>>>>> _belongs_ to the Component (that is, it can access all its data), the event
>>>>> handler should not.
>>>>
>>>> The suggested way, as explained in the orocos documentation (orocos
>>>> component manual, p. 30), is to do the, what you are calling event
>>>> handling, in UpdateHook().
>>>
>>> That's indeed what I am advocating.
>>
>> This looks contradictory to me: you say the event handler should not
>> be part of the component on one side, but it needs to be done in
>> UpdateHook() on the other side.
>
> Oops, I used some incompletely defined terminology; let me make myself
> clear
> - "event handling" = the immediate reaction to an event; must be done by
> the component/thread that notices the event. (In your case: in the
> EventPort.)
> - "event completion" = the not (necessarily) immediate reaction to the
> event, by the component/thread for which the event was destined.
> (In your case: taking the decision about whether or not to stop the
> ongoing control.)
> The _code_ for both can be part of the code of the component, but the
> _execution context_ is, in general, different: the "handling" takes place
> in the thread of the "event noticer", the "completion" takes place in the
> thread of the component for which the event was destined. In
> single-threaded environments, there is no difference.
Agree!
>
>>>> The way I see it is:
>>>> - orocos is already taking care of the event handling: it catches it
>>>> when something happened and it will wake up my component
>>>> - inside my component, I react to that wake up call and do event
>>>> processing / decision making.
>>>
>>> Yes.
>>>
>>>>>>> I do repeat that you are _violating_ separations of concerns by including
>>>>>>> "separate methods for every EventPort"! The event port has to do nothing
>>>>>>> more than getting events; _any_ interpretation of the events _has_ to take
>>>>>>> place within the component that is subscribed to the event.
>>>>>>
>>>>>> This is how it works now! The interpretation of the Events happens in
>>>>>> the individual methods, which are part of the Controller component,
>>>>>> subscribed to the event.
>>>>>
>>>>> It's the "part of" part that I do not like: an event handler should _not_
>>>>> be "part of" a Controller component; they should just set/get the minimal
>>>>> amount of data (related to the _taking place_ of the event, not of the
>>>>> _interpretation_ of the event), and that's it.
>>>>>
>>>>>>>> I know there are various solutions, just wondering which is the best one...
>>>>>>>
>>>>>>> Orocos was created with two definitions of "best" in mind:
>>>>>>> - more reusable is better, and
>>>>>>> - more realtime safe is better.
>>>>>>> Mind you, _not_ with "faster is better" as a criterion!
>>>>>>>
>>>>>>> Your approach does not satisfy any of those two criterions. (The latter one
>>>>>>> is obvious, if you think about a reuse in accelerated hardware, where your
>>>>>>> event handlers could be real Interrupt Service Routines.)
>>>>>>>
>>>>>>>>>> I know it's not a terrible thing UpdateHook() get's called here as
>>>>>>>>>> well, but it makes the watchdog pretty intrusive, which is not how it
>>>>>>>>>> should be.
>>>>>>>>>
>>>>>>>>> What do you mean with "pretty intrusive"? And watchdogs _should_ be
>>>>>>>>> "intrusive" since that's the key essence of their existence :-)
>>>>>>>>
>>>>>>>> It should monitor, in this case, the measurement update frequency, but
>>>>>>>> as long as everything goes well, it's influence should be as minimal
>>>>>>>> as possible (only the EventPort method execution).
>>>>>>>> It should only make it's presence felt the moment the measurements go wrong.
>>>>>>>
>>>>>>> No: violation of SoC... No event handler should have to know anything about
>>>>>>> when something is right or wrong for the Component it is attached to.
>>>>>>> Never!
>>>>>>
>>>>>> Again, this interpretation is already done _inside_ the Controller component.
>>>>>
>>>>> As far as I understand your design, "being done inside the Controller
>>>>> component" means nothing else but "calling a function of the controller
>>>>> component", right? That's not the same thing as decoupling:
>>>>> - an event handler should not know about which functions are available in a
>>>>> component.
>>>>> - calling the same function from different threads/contexts can make a big
>>>>> semantic difference, so it is not only important to keep the (decision
>>>>> making) function that is called in the component, but also to do the
>>>>> calling itself in the component's thread.
>>>>
>>>> The function which gets called _is_ part of the Controller component.
>>>> Do I misunderstand this?
>>>
>>> No, you don't misunderstand that. But you are probably not so aware of the
>>> importance of the _context_ (to be interpreted in its operating systems
>>> meaning) in which that event handling function is called. It should be
>>> called in the process context in which the Component is also executing, so
>>> that it can access everything that is important for the component (and vice
>>> versa: the Component has access to everthing the event handling function
>>> does). A problem can indeed arise when the event handling function is
>>> called in, say, the thread of the communication middleware that the
>>> EventPort is using: if that thread is different from the thread of the
>>> component's Computation, there is a danger for race conditions, or other
>>> nasty concurrency behaviour; it can be even worse if Communication and
>>> Computation are run in different processes.
>>>
>>> This is difficult material, I know...
>>
>> I'm getting back to my first question. I still don't see why every
>> event or (I found out operations do the same) every operation needs to
>> call UpdateHook().
>
> _If_ a component has decided to register to an event, that means that it
> _wants_ to do _something_ which each event that it receives. That also
> means that it must get the opportunity to "run" as soon as its thread is
> ready to do so.
"Having the opportunity to run" is not really the same as
automatically running after every event notice. That's exactly my
point: It _can_ run, but does not _need_ to.
>
>> The component indeed always needs to _react_ to an event / operation,
>> but this reaction is already done in the event / operation method, and
>> that does not _always_ need an UpdateHook() run as well.
>
> Have you understood the 'race conditions' that can occur if the "event
> handler" also does the "completion"?
I won't say I 'master' the subject :), but I see things can go wrong
in the situation you explained.
Steven
> Page 42 and following of my RealTime and Embedded Howto (terribly outdated
> in many respects, sigh...) give more technical details about "event
> handling": <people.mech.kuleuven.be/~bruyninc/rthowto/rtHOWTO.pdf>
>
> Herman
EventPort with custom method calls updateHook
On Sun, 20 Mar 2011, Steven Bellens wrote:
> 2011/3/20 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
>> On Sun, 20 Mar 2011, Steven Bellens wrote:
>>
>>> 2011/3/20 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
>>>> On Sun, 20 Mar 2011, Steven Bellens wrote:
>>>>
>>>>> [...]
>>>>>>>>
>>>>>>>> Why is that? And what is so portable about your likings? :-)
>>>>>>>
>>>>>>> Because it nicely separates what happens for every EventPort
>>>>>>> individually without cluttering UpdateHook().
>>>>>>
>>>>>> Oops! You have your "separation of concerns" wrong: the "UpdateHook()"
>>>>>> _belongs_ to the Component (that is, it can access all its data), the event
>>>>>> handler should not.
>>>>>
>>>>> The suggested way, as explained in the orocos documentation (orocos
>>>>> component manual, p. 30), is to do the, what you are calling event
>>>>> handling, in UpdateHook().
>>>>
>>>> That's indeed what I am advocating.
>>>
>>> This looks contradictory to me: you say the event handler should not
>>> be part of the component on one side, but it needs to be done in
>>> UpdateHook() on the other side.
>>
>> Oops, I used some incompletely defined terminology; let me make myself
>> clear
>> - "event handling" = the immediate reaction to an event; must be done by
>> the component/thread that notices the event. (In your case: in the
>> EventPort.)
>> - "event completion" = the not (necessarily) immediate reaction to the
>> event, by the component/thread for which the event was destined.
>> (In your case: taking the decision about whether or not to stop the
>> ongoing control.)
>> The _code_ for both can be part of the code of the component, but the
>> _execution context_ is, in general, different: the "handling" takes place
>> in the thread of the "event noticer", the "completion" takes place in the
>> thread of the component for which the event was destined. In
>> single-threaded environments, there is no difference.
>
> Agree!
>
>>
>>>>> The way I see it is:
>>>>> - orocos is already taking care of the event handling: it catches it
>>>>> when something happened and it will wake up my component
>>>>> - inside my component, I react to that wake up call and do event
>>>>> processing / decision making.
>>>>
>>>> Yes.
>>>>
>>>>>>>> I do repeat that you are _violating_ separations of concerns by including
>>>>>>>> "separate methods for every EventPort"! The event port has to do nothing
>>>>>>>> more than getting events; _any_ interpretation of the events _has_ to take
>>>>>>>> place within the component that is subscribed to the event.
>>>>>>>
>>>>>>> This is how it works now! The interpretation of the Events happens in
>>>>>>> the individual methods, which are part of the Controller component,
>>>>>>> subscribed to the event.
>>>>>>
>>>>>> It's the "part of" part that I do not like: an event handler should _not_
>>>>>> be "part of" a Controller component; they should just set/get the minimal
>>>>>> amount of data (related to the _taking place_ of the event, not of the
>>>>>> _interpretation_ of the event), and that's it.
>>>>>>
>>>>>>>>> I know there are various solutions, just wondering which is the best one...
>>>>>>>>
>>>>>>>> Orocos was created with two definitions of "best" in mind:
>>>>>>>> - more reusable is better, and
>>>>>>>> - more realtime safe is better.
>>>>>>>> Mind you, _not_ with "faster is better" as a criterion!
>>>>>>>>
>>>>>>>> Your approach does not satisfy any of those two criterions. (The latter one
>>>>>>>> is obvious, if you think about a reuse in accelerated hardware, where your
>>>>>>>> event handlers could be real Interrupt Service Routines.)
>>>>>>>>
>>>>>>>>>>> I know it's not a terrible thing UpdateHook() get's called here as
>>>>>>>>>>> well, but it makes the watchdog pretty intrusive, which is not how it
>>>>>>>>>>> should be.
>>>>>>>>>>
>>>>>>>>>> What do you mean with "pretty intrusive"? And watchdogs _should_ be
>>>>>>>>>> "intrusive" since that's the key essence of their existence :-)
>>>>>>>>>
>>>>>>>>> It should monitor, in this case, the measurement update frequency, but
>>>>>>>>> as long as everything goes well, it's influence should be as minimal
>>>>>>>>> as possible (only the EventPort method execution).
>>>>>>>>> It should only make it's presence felt the moment the measurements go wrong.
>>>>>>>>
>>>>>>>> No: violation of SoC... No event handler should have to know anything about
>>>>>>>> when something is right or wrong for the Component it is attached to.
>>>>>>>> Never!
>>>>>>>
>>>>>>> Again, this interpretation is already done _inside_ the Controller component.
>>>>>>
>>>>>> As far as I understand your design, "being done inside the Controller
>>>>>> component" means nothing else but "calling a function of the controller
>>>>>> component", right? That's not the same thing as decoupling:
>>>>>> - an event handler should not know about which functions are available in a
>>>>>> component.
>>>>>> - calling the same function from different threads/contexts can make a big
>>>>>> semantic difference, so it is not only important to keep the (decision
>>>>>> making) function that is called in the component, but also to do the
>>>>>> calling itself in the component's thread.
>>>>>
>>>>> The function which gets called _is_ part of the Controller component.
>>>>> Do I misunderstand this?
>>>>
>>>> No, you don't misunderstand that. But you are probably not so aware of the
>>>> importance of the _context_ (to be interpreted in its operating systems
>>>> meaning) in which that event handling function is called. It should be
>>>> called in the process context in which the Component is also executing, so
>>>> that it can access everything that is important for the component (and vice
>>>> versa: the Component has access to everthing the event handling function
>>>> does). A problem can indeed arise when the event handling function is
>>>> called in, say, the thread of the communication middleware that the
>>>> EventPort is using: if that thread is different from the thread of the
>>>> component's Computation, there is a danger for race conditions, or other
>>>> nasty concurrency behaviour; it can be even worse if Communication and
>>>> Computation are run in different processes.
>>>>
>>>> This is difficult material, I know...
>>>
>>> I'm getting back to my first question. I still don't see why every
>>> event or (I found out operations do the same) every operation needs to
>>> call UpdateHook().
>>
>> _If_ a component has decided to register to an event, that means that it
>> _wants_ to do _something_ which each event that it receives. That also
>> means that it must get the opportunity to "run" as soon as its thread is
>> ready to do so.
>
> "Having the opportunity to run" is not really the same as
> automatically running after every event notice. That's exactly my
> point: It _can_ run, but does not _need_ to.
There are again two different players to be taken into account here:
- the component itself, that can (or rather, has!) to decide what it does
with the event
- the OS scheduler that is the only one that eventually decides whether or
not to run the component
So, the event handler can have a policy to notify or not the OS that the
component has to run after the event.
>>> The component indeed always needs to _react_ to an event / operation,
>>> but this reaction is already done in the event / operation method, and
>>> that does not _always_ need an UpdateHook() run as well.
>>
>> Have you understood the 'race conditions' that can occur if the "event
>> handler" also does the "completion"?
>
> I won't say I 'master' the subject :), but I see things can go wrong
> in the situation you explained.
You've been shielded from most of these problems, because you started with
RTT; I've had to learn these lessons "the hard way", on the bare operating
system :-(
> Steven
>
>> Page 42 and following of my RealTime and Embedded Howto (terribly outdated
>> in many respects, sigh...) give more technical details about "event
>> handling": <people.mech.kuleuven.be/~bruyninc/rthowto/rtHOWTO.pdf>
Herman
EventPort with custom method calls updateHook
On Sun, 20 Mar 2011, Steven Bellens wrote:
> 2011/3/20 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
>> On Sun, 20 Mar 2011, Steven Bellens wrote:
>>
>>> 2011/3/20 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
>>>> On Sun, 20 Mar 2011, Steven Bellens wrote:
>>>>
>>>>> [...]
>>>>>>>>
>>>>>>>> Why is that? And what is so portable about your likings? :-)
>>>>>>>
>>>>>>> Because it nicely separates what happens for every EventPort
>>>>>>> individually without cluttering UpdateHook().
>>>>>>
>>>>>> Oops! You have your "separation of concerns" wrong: the "UpdateHook()"
>>>>>> _belongs_ to the Component (that is, it can access all its data), the event
>>>>>> handler should not.
>>>>>
>>>>> The suggested way, as explained in the orocos documentation (orocos
>>>>> component manual, p. 30), is to do the, what you are calling event
>>>>> handling, in UpdateHook().
>>>>
>>>> That's indeed what I am advocating.
>>>
>>> This looks contradictory to me: you say the event handler should not
>>> be part of the component on one side, but it needs to be done in
>>> UpdateHook() on the other side.
>>
>> Oops, I used some incompletely defined terminology; let me make myself
>> clear
>> - "event handling" = the immediate reaction to an event; must be done by
>> the component/thread that notices the event. (In your case: in the
>> EventPort.)
>> - "event completion" = the not (necessarily) immediate reaction to the
>> event, by the component/thread for which the event was destined.
>> (In your case: taking the decision about whether or not to stop the
>> ongoing control.)
>> The _code_ for both can be part of the code of the component, but the
>> _execution context_ is, in general, different: the "handling" takes place
>> in the thread of the "event noticer", the "completion" takes place in the
>> thread of the component for which the event was destined. In
>> single-threaded environments, there is no difference.
>
> Agree!
>
>>
>>>>> The way I see it is:
>>>>> - orocos is already taking care of the event handling: it catches it
>>>>> when something happened and it will wake up my component
>>>>> - inside my component, I react to that wake up call and do event
>>>>> processing / decision making.
>>>>
>>>> Yes.
>>>>
>>>>>>>> I do repeat that you are _violating_ separations of concerns by including
>>>>>>>> "separate methods for every EventPort"! The event port has to do nothing
>>>>>>>> more than getting events; _any_ interpretation of the events _has_ to take
>>>>>>>> place within the component that is subscribed to the event.
>>>>>>>
>>>>>>> This is how it works now! The interpretation of the Events happens in
>>>>>>> the individual methods, which are part of the Controller component,
>>>>>>> subscribed to the event.
>>>>>>
>>>>>> It's the "part of" part that I do not like: an event handler should _not_
>>>>>> be "part of" a Controller component; they should just set/get the minimal
>>>>>> amount of data (related to the _taking place_ of the event, not of the
>>>>>> _interpretation_ of the event), and that's it.
>>>>>>
>>>>>>>>> I know there are various solutions, just wondering which is the best one...
>>>>>>>>
>>>>>>>> Orocos was created with two definitions of "best" in mind:
>>>>>>>> - more reusable is better, and
>>>>>>>> - more realtime safe is better.
>>>>>>>> Mind you, _not_ with "faster is better" as a criterion!
>>>>>>>>
>>>>>>>> Your approach does not satisfy any of those two criterions. (The latter one
>>>>>>>> is obvious, if you think about a reuse in accelerated hardware, where your
>>>>>>>> event handlers could be real Interrupt Service Routines.)
>>>>>>>>
>>>>>>>>>>> I know it's not a terrible thing UpdateHook() get's called here as
>>>>>>>>>>> well, but it makes the watchdog pretty intrusive, which is not how it
>>>>>>>>>>> should be.
>>>>>>>>>>
>>>>>>>>>> What do you mean with "pretty intrusive"? And watchdogs _should_ be
>>>>>>>>>> "intrusive" since that's the key essence of their existence :-)
>>>>>>>>>
>>>>>>>>> It should monitor, in this case, the measurement update frequency, but
>>>>>>>>> as long as everything goes well, it's influence should be as minimal
>>>>>>>>> as possible (only the EventPort method execution).
>>>>>>>>> It should only make it's presence felt the moment the measurements go wrong.
>>>>>>>>
>>>>>>>> No: violation of SoC... No event handler should have to know anything about
>>>>>>>> when something is right or wrong for the Component it is attached to.
>>>>>>>> Never!
>>>>>>>
>>>>>>> Again, this interpretation is already done _inside_ the Controller component.
>>>>>>
>>>>>> As far as I understand your design, "being done inside the Controller
>>>>>> component" means nothing else but "calling a function of the controller
>>>>>> component", right? That's not the same thing as decoupling:
>>>>>> - an event handler should not know about which functions are available in a
>>>>>> component.
>>>>>> - calling the same function from different threads/contexts can make a big
>>>>>> semantic difference, so it is not only important to keep the (decision
>>>>>> making) function that is called in the component, but also to do the
>>>>>> calling itself in the component's thread.
>>>>>
>>>>> The function which gets called _is_ part of the Controller component.
>>>>> Do I misunderstand this?
>>>>
>>>> No, you don't misunderstand that. But you are probably not so aware of the
>>>> importance of the _context_ (to be interpreted in its operating systems
>>>> meaning) in which that event handling function is called. It should be
>>>> called in the process context in which the Component is also executing, so
>>>> that it can access everything that is important for the component (and vice
>>>> versa: the Component has access to everthing the event handling function
>>>> does). A problem can indeed arise when the event handling function is
>>>> called in, say, the thread of the communication middleware that the
>>>> EventPort is using: if that thread is different from the thread of the
>>>> component's Computation, there is a danger for race conditions, or other
>>>> nasty concurrency behaviour; it can be even worse if Communication and
>>>> Computation are run in different processes.
>>>>
>>>> This is difficult material, I know...
>>>
>>> I'm getting back to my first question. I still don't see why every
>>> event or (I found out operations do the same) every operation needs to
>>> call UpdateHook().
>>
>> _If_ a component has decided to register to an event, that means that it
>> _wants_ to do _something_ which each event that it receives. That also
>> means that it must get the opportunity to "run" as soon as its thread is
>> ready to do so.
>
> "Having the opportunity to run" is not really the same as
> automatically running after every event notice. That's exactly my
> point: It _can_ run, but does not _need_ to.
There are again two different players to be taken into account here:
- the component itself, that can (or rather, has!) to decide what it does
with the event
- the OS scheduler that is the only one that eventually decides whether or
not to run the component
So, the event handler can have a policy to notify or not the OS that the
component has to run after the event.
>>> The component indeed always needs to _react_ to an event / operation,
>>> but this reaction is already done in the event / operation method, and
>>> that does not _always_ need an UpdateHook() run as well.
>>
>> Have you understood the 'race conditions' that can occur if the "event
>> handler" also does the "completion"?
>
> I won't say I 'master' the subject :), but I see things can go wrong
> in the situation you explained.
You've been shielded from most of these problems, because you started with
RTT; I've had to learn these lessons "the hard way", on the bare operating
system :-(
> Steven
>
>> Page 42 and following of my RealTime and Embedded Howto (terribly outdated
>> in many respects, sigh...) give more technical details about "event
>> handling": <people.mech.kuleuven.be/~bruyninc/rthowto/rtHOWTO.pdf>
Herman
EventPort with custom method calls updateHook
[...]
>>>
>>> _If_ a component has decided to register to an event, that means that it
>>> _wants_ to do _something_ which each event that it receives. That also
>>> means that it must get the opportunity to "run" as soon as its thread is
>>> ready to do so.
>>
>> "Having the opportunity to run" is not really the same as
>> automatically running after every event notice. That's exactly my
>> point: It _can_ run, but does not _need_ to.
>
> There are again two different players to be taken into account here:
> - the component itself, that can (or rather, has!) to decide what it does
> with the event
> - the OS scheduler that is the only one that eventually decides whether or
> not to run the component
> So, the event handler can have a policy to notify or not the OS that the
> component has to run after the event.
Yes, so that brings us back where we started. Is there a specific
reason to choose one policy above the other?
And, more important, is there an option to override that policy?
>
>>>> The component indeed always needs to _react_ to an event / operation,
>>>> but this reaction is already done in the event / operation method, and
>>>> that does not _always_ need an UpdateHook() run as well.
>>>
>>> Have you understood the 'race conditions' that can occur if the "event
>>> handler" also does the "completion"?
>>
>> I won't say I 'master' the subject :), but I see things can go wrong
>> in the situation you explained.
>
> You've been shielded from most of these problems, because you started with
> RTT; I've had to learn these lessons "the hard way", on the bare operating
> system :-(
And I'm glad I could!
Steven
>
>> Steven
>>
>>> Page 42 and following of my RealTime and Embedded Howto (terribly outdated
>>> in many respects, sigh...) give more technical details about "event
>>> handling": <people.mech.kuleuven.be/~bruyninc/rthowto/rtHOWTO.pdf>
>
> Herman
EventPort with custom method calls updateHook
[...]
>>>
>>> _If_ a component has decided to register to an event, that means that it
>>> _wants_ to do _something_ which each event that it receives. That also
>>> means that it must get the opportunity to "run" as soon as its thread is
>>> ready to do so.
>>
>> "Having the opportunity to run" is not really the same as
>> automatically running after every event notice. That's exactly my
>> point: It _can_ run, but does not _need_ to.
>
> There are again two different players to be taken into account here:
> - the component itself, that can (or rather, has!) to decide what it does
> with the event
> - the OS scheduler that is the only one that eventually decides whether or
> not to run the component
> So, the event handler can have a policy to notify or not the OS that the
> component has to run after the event.
Yes, so that brings us back where we started. Is there a specific
reason to choose one policy above the other?
And, more important, is there an option to override that policy?
>
>>>> The component indeed always needs to _react_ to an event / operation,
>>>> but this reaction is already done in the event / operation method, and
>>>> that does not _always_ need an UpdateHook() run as well.
>>>
>>> Have you understood the 'race conditions' that can occur if the "event
>>> handler" also does the "completion"?
>>
>> I won't say I 'master' the subject :), but I see things can go wrong
>> in the situation you explained.
>
> You've been shielded from most of these problems, because you started with
> RTT; I've had to learn these lessons "the hard way", on the bare operating
> system :-(
And I'm glad I could!
Steven
>
>> Steven
>>
>>> Page 42 and following of my RealTime and Embedded Howto (terribly outdated
>>> in many respects, sigh...) give more technical details about "event
>>> handling": <people.mech.kuleuven.be/~bruyninc/rthowto/rtHOWTO.pdf>
>
> Herman
EventPort with custom method calls updateHook
On Sun, 20 Mar 2011, Steven Bellens wrote:
> [...]
>>>>
>>>> _If_ a component has decided to register to an event, that means that it
>>>> _wants_ to do _something_ which each event that it receives. That also
>>>> means that it must get the opportunity to "run" as soon as its thread is
>>>> ready to do so.
>>>
>>> "Having the opportunity to run" is not really the same as
>>> automatically running after every event notice. That's exactly my
>>> point: It _can_ run, but does not _need_ to.
>>
>> There are again two different players to be taken into account here:
>> - the component itself, that can (or rather, has!) to decide what it does
>> with the event
>> - the OS scheduler that is the only one that eventually decides whether or
>> not to run the component
>> So, the event handler can have a policy to notify or not the OS that the
>> component has to run after the event.
>
> Yes, so that brings us back where we started. Is there a specific
> reason to choose one policy above the other?
> And, more important, is there an option to override that policy?
Any policy should be _configurable_, exactly for the reason that the
framework developers should not _impose_ any policy on the framework users.
RTT most probably has not yet reached this level of configurability, so a
"feature request" to the developers might be in order :-) (Not that they
don't know about that "problem" yet :-)
>>>>> The component indeed always needs to _react_ to an event / operation,
>>>>> but this reaction is already done in the event / operation method, and
>>>>> that does not _always_ need an UpdateHook() run as well.
>>>>
>>>> Have you understood the 'race conditions' that can occur if the "event
>>>> handler" also does the "completion"?
>>>
>>> I won't say I 'master' the subject :), but I see things can go wrong
>>> in the situation you explained.
>>
>> You've been shielded from most of these problems, because you started with
>> RTT; I've had to learn these lessons "the hard way", on the bare operating
>> system :-(
>
> And I'm glad I could!
Herman
EventPort with custom method calls updateHook
On Sun, 20 Mar 2011, Steven Bellens wrote:
> [...]
>>>>
>>>> _If_ a component has decided to register to an event, that means that it
>>>> _wants_ to do _something_ which each event that it receives. That also
>>>> means that it must get the opportunity to "run" as soon as its thread is
>>>> ready to do so.
>>>
>>> "Having the opportunity to run" is not really the same as
>>> automatically running after every event notice. That's exactly my
>>> point: It _can_ run, but does not _need_ to.
>>
>> There are again two different players to be taken into account here:
>> - the component itself, that can (or rather, has!) to decide what it does
>> with the event
>> - the OS scheduler that is the only one that eventually decides whether or
>> not to run the component
>> So, the event handler can have a policy to notify or not the OS that the
>> component has to run after the event.
>
> Yes, so that brings us back where we started. Is there a specific
> reason to choose one policy above the other?
> And, more important, is there an option to override that policy?
Any policy should be _configurable_, exactly for the reason that the
framework developers should not _impose_ any policy on the framework users.
RTT most probably has not yet reached this level of configurability, so a
"feature request" to the developers might be in order :-) (Not that they
don't know about that "problem" yet :-)
>>>>> The component indeed always needs to _react_ to an event / operation,
>>>>> but this reaction is already done in the event / operation method, and
>>>>> that does not _always_ need an UpdateHook() run as well.
>>>>
>>>> Have you understood the 'race conditions' that can occur if the "event
>>>> handler" also does the "completion"?
>>>
>>> I won't say I 'master' the subject :), but I see things can go wrong
>>> in the situation you explained.
>>
>> You've been shielded from most of these problems, because you started with
>> RTT; I've had to learn these lessons "the hard way", on the bare operating
>> system :-(
>
> And I'm glad I could!
Herman
EventPort with custom method calls updateHook
On Mon, Mar 21, 2011 at 07:45:16AM +0100, Herman Bruyninckx wrote:
> On Sun, 20 Mar 2011, Steven Bellens wrote:
>
> > [...]
> >>>>
> >>>> _If_ a component has decided to register to an event, that means that it
> >>>> _wants_ to do _something_ which each event that it receives. That also
> >>>> means that it must get the opportunity to "run" as soon as its thread is
> >>>> ready to do so.
> >>>
> >>> "Having the opportunity to run" is not really the same as
> >>> automatically running after every event notice. That's exactly my
> >>> point: It _can_ run, but does not _need_ to.
> >>
> >> There are again two different players to be taken into account here:
> >> - the component itself, that can (or rather, has!) to decide what it does
> >> with the event
> >> - the OS scheduler that is the only one that eventually decides whether or
> >> not to run the component
> >> So, the event handler can have a policy to notify or not the OS that the
> >> component has to run after the event.
> >
> > Yes, so that brings us back where we started. Is there a specific
> > reason to choose one policy above the other?
> > And, more important, is there an option to override that policy?
>
> Any policy should be _configurable_, exactly for the reason that the
> framework developers should not _impose_ any policy on the framework users.
> RTT most probably has not yet reached this level of configurability, so a
> "feature request" to the developers might be in order :-) (Not that they
> don't know about that "problem" yet :-)
AFAIR, at the RTT developers meeting last year it was mutually agreed
that indiviudal event handlers would not be necesssary. But as Peter
had implemented the feature already and it seemed conveniant under
some circumstances, it was decided to leave it in.
I don't see a problem with this list of port->handler functions as
long as one is aware when to stop using it. This would be when the
handlers are no longer independent and stateless, which is of course
the domain of finite state machines :-)
Best regards
Markus
EventPort with custom method calls updateHook
On Mon, Mar 21, 2011 at 07:45:16AM +0100, Herman Bruyninckx wrote:
> On Sun, 20 Mar 2011, Steven Bellens wrote:
>
> > [...]
> >>>>
> >>>> _If_ a component has decided to register to an event, that means that it
> >>>> _wants_ to do _something_ which each event that it receives. That also
> >>>> means that it must get the opportunity to "run" as soon as its thread is
> >>>> ready to do so.
> >>>
> >>> "Having the opportunity to run" is not really the same as
> >>> automatically running after every event notice. That's exactly my
> >>> point: It _can_ run, but does not _need_ to.
> >>
> >> There are again two different players to be taken into account here:
> >> - the component itself, that can (or rather, has!) to decide what it does
> >> with the event
> >> - the OS scheduler that is the only one that eventually decides whether or
> >> not to run the component
> >> So, the event handler can have a policy to notify or not the OS that the
> >> component has to run after the event.
> >
> > Yes, so that brings us back where we started. Is there a specific
> > reason to choose one policy above the other?
> > And, more important, is there an option to override that policy?
>
> Any policy should be _configurable_, exactly for the reason that the
> framework developers should not _impose_ any policy on the framework users.
> RTT most probably has not yet reached this level of configurability, so a
> "feature request" to the developers might be in order :-) (Not that they
> don't know about that "problem" yet :-)
AFAIR, at the RTT developers meeting last year it was mutually agreed
that indiviudal event handlers would not be necesssary. But as Peter
had implemented the feature already and it seemed conveniant under
some circumstances, it was decided to leave it in.
I don't see a problem with this list of port->handler functions as
long as one is aware when to stop using it. This would be when the
handlers are no longer independent and stateless, which is of course
the domain of finite state machines :-)
Best regards
Markus