hi
I made a program with two components
when I give them the same period, they are executed in the same thread
I expect a blocking call from one of them, this should not block the
other component
=> How do I get them in different threads with the same period?
thanks for your suggestions!
nick
threads
On Mon, Apr 26, 2010 at 11:17 AM, Dominick Vanthienen
<dominick [dot] vanthienen [..] ...> wrote:
> hi
>
> I made a program with two components
> when I give them the same period, they are executed in the same thread
>
> I expect a blocking call from one of them, this should not block the other
> component
> => How do I get them in different threads with the same period?
There is a difference in using Activity vs PeriodicActivity (see e.g.
<http://people.mech.kuleuven.be/~orocos/pub/documentation/rtt/v1.10.x/doc-xml/orocos-rtt-changes.html>,
although it is by far a complete description of what has changed):
Summary:
- PeriodicActivies (will be deprecated IIRC) that have the same
period/priority are executed in the same thread
- Activities (starting from 1.10) that have the same period and
priority are executed in different threads. If you want to fall back
to the "old" behaviour, you need to use SlaveActivies [*], [**].
What do you mean exactly with "blocking call"? Fi. having to
components in the same thread, does not (necessarily [***]) mean that
one of them cannot call a method on the other one.
[*] There is one "nasty" side effect of this: Using SlaveActivities
introduces some kind of coupling between components: You need to
specify at _compile_ time which component is master and what are the
slaves, whereas with the old model you could do this at runtime
(deployment configuration).
[**] Second caveat: we have already encountered situations where
Master+Slaves yields a different behaviour from PeriodAcitivies with
generated code from Simulink models. Unfortunately, we haven't found
time so far to dig deeper.
[***] Ofcourse, if that method locks a Mutex that is also locked by
the others updateHook fi, you're in trouble :-)
HTH,
Klaas
threads
On Mon, Apr 26, 2010 at 13:38, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
> On Mon, Apr 26, 2010 at 11:17 AM, Dominick Vanthienen
> <dominick [dot] vanthienen [..] ...> wrote:
>> hi
>>
>> I made a program with two components
>> when I give them the same period, they are executed in the same thread
>>
>> I expect a blocking call from one of them, this should not block the other
>> component
>> => How do I get them in different threads with the same period?
>
> There is a difference in using Activity vs PeriodicActivity (see e.g.
> <http://people.mech.kuleuven.be/~orocos/pub/documentation/rtt/v1.10.x/doc-xml/orocos-rtt-changes.html>,
> although it is by far a complete description of what has changed):
>
> Summary:
> - PeriodicActivies (will be deprecated IIRC) that have the same
> period/priority are executed in the same thread
PeriodicActivity will not be deprecated. In 2.x, it's in RTT::extras
for example, in 1.x, it remains where it is, in the RTT namespace.
> - Activities (starting from 1.10) that have the same period and
> priority are executed in different threads. If you want to fall back
> to the "old" behaviour, you need to use SlaveActivies [*], [**].
>
> What do you mean exactly with "blocking call"? Fi. having to
> components in the same thread, does not (necessarily [***]) mean that
> one of them cannot call a method on the other one.
>
> [*] There is one "nasty" side effect of this: Using SlaveActivities
> introduces some kind of coupling between components: You need to
> specify at _compile_ time which component is master and what are the
> slaves, whereas with the old model you could do this at runtime
> (deployment configuration).
You're refering to explicitly calling update() on the slave ? You can
load a program script in the master that calls this method on the
slave to avoid compile time dependencies.
I advice SlaveActivity in favor of PeriodicActivity because a slave
forces you to fix the causality in the master. PeriodicActivity is
implicitly ordering component updates, depending on the order of
starting components.
> [**] Second caveat: we have already encountered situations where
> Master+Slaves yields a different behaviour from PeriodAcitivies with
> generated code from Simulink models. Unfortunately, we haven't found
> time so far to dig deeper.
Master+Slave should represent your intended behavior, since there's no
doubt about the ordering.
Peter
threads
On Mon, Apr 26, 2010 at 11:20 PM, Peter Soetens
<peter [..] ...> wrote:
> On Mon, Apr 26, 2010 at 13:38, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
>> On Mon, Apr 26, 2010 at 11:17 AM, Dominick Vanthienen
>> <dominick [dot] vanthienen [..] ...> wrote:
[...]
>> There is a difference in using Activity vs PeriodicActivity (see e.g.
>> <http://people.mech.kuleuven.be/~orocos/pub/documentation/rtt/v1.10.x/doc-xml/orocos-rtt-changes.html>,
>> although it is by far a complete description of what has changed):
>>
>> Summary:
>> - PeriodicActivies (will be deprecated IIRC) that have the same
>> period/priority are executed in the same thread
>
> PeriodicActivity will not be deprecated. In 2.x, it's in RTT::extras
> for example, in 1.x, it remains where it is, in the RTT namespace.
ACK. What's the scope of "RTT::extras"?
[...]
>> [*] There is one "nasty" side effect of this: Using SlaveActivities
>> introduces some kind of coupling between components: You need to
>> specify at _compile_ time which component is master and what are the
>> slaves, whereas with the old model you could do this at runtime
>> (deployment configuration).
>
> You're refering to explicitly calling update() on the slave ?
Yes
> You can
> load a program script in the master that calls this method on the
> slave to avoid compile time dependencies.
That could be a workaround, indeed. Although the most logical place
to decide on the application architecture and hence which component's
activities belong together in threads seems to be the deployment
configuration (for people not using ORO_main, that is) for me?
> I advice SlaveActivity in favor of PeriodicActivity because a slave
> forces you to fix the causality in the master. PeriodicActivity is
> implicitly ordering component updates, depending on the order of
> starting components.
I don't know if there is always something as an explicit "master". My
usecase is rather a situtation in which I would have 5 components of
which I say: for this application, you guys will all use the same
thread. And sometimes, ordering can be important indeed. But is
specifying an order in which components should be executed for one
particular application the same as specifying that one of them is the
master for that application?
Best regards,
Klaas
threads
On Apr 27, 2010, at 03:03 , Klaas Gadeyne wrote:
> On Mon, Apr 26, 2010 at 11:20 PM, Peter Soetens
> <peter [..] ...> wrote:
>> On Mon, Apr 26, 2010 at 13:38, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
>>> On Mon, Apr 26, 2010 at 11:17 AM, Dominick Vanthienen
>>> <dominick [dot] vanthienen [..] ...> wrote:
> [...]
>>> There is a difference in using Activity vs PeriodicActivity (see e.g.
>>> <http://people.mech.kuleuven.be/~orocos/pub/documentation/rtt/v1.10.x/doc-xml/orocos-rtt-changes.html>,
>>> although it is by far a complete description of what has changed):
>>>
>>> Summary:
>>> - PeriodicActivies (will be deprecated IIRC) that have the same
>>> period/priority are executed in the same thread
>>
>> PeriodicActivity will not be deprecated. In 2.x, it's in RTT::extras
>> for example, in 1.x, it remains where it is, in the RTT namespace.
>
> ACK. What's the scope of "RTT::extras"?
>
> [...]
>>> [*] There is one "nasty" side effect of this: Using SlaveActivities
>>> introduces some kind of coupling between components: You need to
>>> specify at _compile_ time which component is master and what are the
>>> slaves, whereas with the old model you could do this at runtime
>>> (deployment configuration).
>>
>> You're refering to explicitly calling update() on the slave ?
>
> Yes
>
>> You can
>> load a program script in the master that calls this method on the
>> slave to avoid compile time dependencies.
>
> That could be a workaround, indeed. Although the most logical place
> to decide on the application architecture and hence which component's
> activities belong together in threads seems to be the deployment
> configuration (for people not using ORO_main, that is) for me?
That's how we do it in v1, but we use state machines instead of program scripts. The master/slave connections are done at runtime.
>> I advice SlaveActivity in favor of PeriodicActivity because a slave
>> forces you to fix the causality in the master. PeriodicActivity is
>> implicitly ordering component updates, depending on the order of
>> starting components.
>
> I don't know if there is always something as an explicit "master". My
> usecase is rather a situtation in which I would have 5 components of
> which I say: for this application, you guys will all use the same
> thread. And sometimes, ordering can be important indeed. But is
> specifying an order in which components should be executed for one
> particular application the same as specifying that one of them is the
> master for that application?
I think it is the same. We use a coordinating component that solely runs a state machine, and within each state we trigger the appropriate slave components in order. The coordinator is our "explicit master". I gather that you are doing something different?
Stephen
threads
On Tue, Apr 27, 2010 at 1:03 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
[...]
>> I don't know if there is always something as an explicit "master". My
>> usecase is rather a situtation in which I would have 5 components of
>> which I say: for this application, you guys will all use the same
>> thread. And sometimes, ordering can be important indeed. But is
>> specifying an order in which components should be executed for one
>> particular application the same as specifying that one of them is the
>> master for that application?
>
> I think it is the same. We use a coordinating component that solely runs a state machine, and within each state we trigger the appropriate slave components in order. The coordinator is our "explicit master". I gather that you are doing something different?
Well, I guess you're right: The type of application I was thinking
about when writing this email is probably just a special (read: more
simple, more static) case of an application architecture whose
"coordinating component" is that simple that it (the architecture)
can/could be specified using a deployment file only.
Klaas
threads
On Tue, Apr 27, 2010 at 09:03, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
> On Mon, Apr 26, 2010 at 11:20 PM, Peter Soetens
> <peter [..] ...> wrote:
>> On Mon, Apr 26, 2010 at 13:38, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
>>> On Mon, Apr 26, 2010 at 11:17 AM, Dominick Vanthienen
>>> <dominick [dot] vanthienen [..] ...> wrote:
> [...]
>>> There is a difference in using Activity vs PeriodicActivity (see e.g.
>>> <http://people.mech.kuleuven.be/~orocos/pub/documentation/rtt/v1.10.x/doc-xml/orocos-rtt-changes.html>,
>>> although it is by far a complete description of what has changed):
>>>
>>> Summary:
>>> - PeriodicActivies (will be deprecated IIRC) that have the same
>>> period/priority are executed in the same thread
>>
>> PeriodicActivity will not be deprecated. In 2.x, it's in RTT::extras
>> for example, in 1.x, it remains where it is, in the RTT namespace.
>
> ACK. What's the scope of "RTT::extras"?
'User contributed utility classes'. 'Might not be of the same quality
(impl/doc) as the rest of RTT'. API stability obeys same rules as RTT.
>
> [...]
>>> [*] There is one "nasty" side effect of this: Using SlaveActivities
>>> introduces some kind of coupling between components: You need to
>>> specify at _compile_ time which component is master and what are the
>>> slaves, whereas with the old model you could do this at runtime
>>> (deployment configuration).
>>
>> You're refering to explicitly calling update() on the slave ?
>
> Yes
>
>> You can
>> load a program script in the master that calls this method on the
>> slave to avoid compile time dependencies.
>
> That could be a workaround, indeed. Although the most logical place
> to decide on the application architecture and hence which component's
> activities belong together in threads seems to be the deployment
> configuration (for people not using ORO_main, that is) for me?
Yes it is. I'm not assuming anyone is using ORO_main that much nowadays.
>
>> I advice SlaveActivity in favor of PeriodicActivity because a slave
>> forces you to fix the causality in the master. PeriodicActivity is
>> implicitly ordering component updates, depending on the order of
>> starting components.
>
> I don't know if there is always something as an explicit "master". My
> usecase is rather a situtation in which I would have 5 components of
> which I say: for this application, you guys will all use the same
> thread. And sometimes, ordering can be important indeed. But is
> specifying an order in which components should be executed for one
> particular application the same as specifying that one of them is the
> master for that application?
Both are a deployment choice, or at least, can be defered to
deployment. Specifying behaviours in a script is not a work-around in
my opinion, loading the proper/required scripts into components is
just part of the deployment process.
Peter
threads
On Apr 27, 2010, at 03:40 , Peter Soetens wrote:
> On Tue, Apr 27, 2010 at 09:03, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
>> On Mon, Apr 26, 2010 at 11:20 PM, Peter Soetens
>> <peter [..] ...> wrote:
>>> On Mon, Apr 26, 2010 at 13:38, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
>>>> On Mon, Apr 26, 2010 at 11:17 AM, Dominick Vanthienen
>>>> <dominick [dot] vanthienen [..] ...> wrote:
>> [...]
>>>> There is a difference in using Activity vs PeriodicActivity (see e.g.
>>>> <http://people.mech.kuleuven.be/~orocos/pub/documentation/rtt/v1.10.x/doc-xml/orocos-rtt-changes.html>,
>>>> although it is by far a complete description of what has changed):
>>>>
>>>> Summary:
>>>> - PeriodicActivies (will be deprecated IIRC) that have the same
>>>> period/priority are executed in the same thread
>>>
>>> PeriodicActivity will not be deprecated. In 2.x, it's in RTT::extras
>>> for example, in 1.x, it remains where it is, in the RTT namespace.
>>
>> ACK. What's the scope of "RTT::extras"?
>
> 'User contributed utility classes'. 'Might not be of the same quality
> (impl/doc) as the rest of RTT'. API stability obeys same rules as RTT.
>
>>
>> [...]
>>>> [*] There is one "nasty" side effect of this: Using SlaveActivities
>>>> introduces some kind of coupling between components: You need to
>>>> specify at _compile_ time which component is master and what are the
>>>> slaves, whereas with the old model you could do this at runtime
>>>> (deployment configuration).
>>>
>>> You're refering to explicitly calling update() on the slave ?
>>
>> Yes
>>
>>> You can
>>> load a program script in the master that calls this method on the
>>> slave to avoid compile time dependencies.
>>
>> That could be a workaround, indeed. Although the most logical place
>> to decide on the application architecture and hence which component's
>> activities belong together in threads seems to be the deployment
>> configuration (for people not using ORO_main, that is) for me?
>
> Yes it is. I'm not assuming anyone is using ORO_main that much nowadays.
Slow down ... some of us still use it! Don't go ditching it in v2 please!! It is very useful for unit test cases.
>>> I advice SlaveActivity in favor of PeriodicActivity because a slave
>>> forces you to fix the causality in the master. PeriodicActivity is
>>> implicitly ordering component updates, depending on the order of
>>> starting components.
>>
>> I don't know if there is always something as an explicit "master". My
>> usecase is rather a situtation in which I would have 5 components of
>> which I say: for this application, you guys will all use the same
>> thread. And sometimes, ordering can be important indeed. But is
>> specifying an order in which components should be executed for one
>> particular application the same as specifying that one of them is the
>> master for that application?
>
> Both are a deployment choice, or at least, can be defered to
> deployment. Specifying behaviours in a script is not a work-around in
> my opinion, loading the proper/required scripts into components is
> just part of the deployment process.
+1
S
threads
S Roderick wrote:
> On Apr 27, 2010, at 03:40 , Peter Soetens wrote:
>
>
>> On Tue, Apr 27, 2010 at 09:03, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
>>
>>> On Mon, Apr 26, 2010 at 11:20 PM, Peter Soetens
>>> <peter [..] ...> wrote:
>>>
>>>> On Mon, Apr 26, 2010 at 13:38, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
>>>>
>>>>> On Mon, Apr 26, 2010 at 11:17 AM, Dominick Vanthienen
>>>>> <dominick [dot] vanthienen [..] ...> wrote:
>>>>>
>>> [...]
>>>
>>>>> There is a difference in using Activity vs PeriodicActivity (see e.g.
>>>>> <http://people.mech.kuleuven.be/~orocos/pub/documentation/rtt/v1.10.x/doc-xml/orocos-rtt-changes.html>,
>>>>> although it is by far a complete description of what has changed):
>>>>>
>>>>> Summary:
>>>>> - PeriodicActivies (will be deprecated IIRC) that have the same
>>>>> period/priority are executed in the same thread
>>>>>
>>>> PeriodicActivity will not be deprecated. In 2.x, it's in RTT::extras
>>>> for example, in 1.x, it remains where it is, in the RTT namespace.
>>>>
>>> ACK. What's the scope of "RTT::extras"?
>>>
>> 'User contributed utility classes'. 'Might not be of the same quality
>> (impl/doc) as the rest of RTT'. API stability obeys same rules as RTT.
>>
>>
>>> [...]
>>>
>>>>> [*] There is one "nasty" side effect of this: Using SlaveActivities
>>>>> introduces some kind of coupling between components: You need to
>>>>> specify at _compile_ time which component is master and what are the
>>>>> slaves, whereas with the old model you could do this at runtime
>>>>> (deployment configuration).
>>>>>
>>>> You're refering to explicitly calling update() on the slave ?
>>>>
>>> Yes
>>>
>>>
>>>> You can
>>>> load a program script in the master that calls this method on the
>>>> slave to avoid compile time dependencies.
>>>>
>>> That could be a workaround, indeed. Although the most logical place
>>> to decide on the application architecture and hence which component's
>>> activities belong together in threads seems to be the deployment
>>> configuration (for people not using ORO_main, that is) for me?
>>>
>> Yes it is. I'm not assuming anyone is using ORO_main that much nowadays.
>>
>
> Slow down ... some of us still use it! Don't go ditching it in v2 please!! It is very useful for unit test cases.
>
+1. oroGen uses it for so-called "static deployments". Which is the only
deployment type we currently use at DFKI ...
threads
On Tue, Apr 27, 2010 at 2:02 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
> S Roderick wrote:
>>
>> On Apr 27, 2010, at 03:40 , Peter Soetens wrote:
>>>
>>> Yes it is. I'm not assuming anyone is using ORO_main that much nowadays.
>>>
>>
>> Slow down ... some of us still use it! Don't go ditching it in v2 please!! It is very useful for unit test cases.
>>
>
> +1. oroGen uses it for so-called "static deployments". Which is the only deployment type we currently use at DFKI ...
I wasn't saying that. I was just talking about my 'assumptions' when
analysing user problems reported on this list. Meaning, I assume the
user is using the deployer to load his component, when he doesn't
specify the procedure used.
Peter
threads
On Apr 27, 2010, at 08:42 , Peter Soetens wrote:
> On Tue, Apr 27, 2010 at 2:02 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
>> S Roderick wrote:
>>>
>>> On Apr 27, 2010, at 03:40 , Peter Soetens wrote:
>>>>
>>>> Yes it is. I'm not assuming anyone is using ORO_main that much nowadays.
>>>>
>>>
>>> Slow down ... some of us still use it! Don't go ditching it in v2 please!! It is very useful for unit test cases.
>>>
>>
>> +1. oroGen uses it for so-called "static deployments". Which is the only deployment type we currently use at DFKI ...
>
> I wasn't saying that. I was just talking about my 'assumptions' when
> analysing user problems reported on this list. Meaning, I assume the
> user is using the deployer to load his component, when he doesn't
> specify the procedure used.
Fair enough, makes sense.
S
threads
I changed to activities in stead of PeriodicActivities
it works fine now
thanx
Klaas Gadeyne wrote:
> On Mon, Apr 26, 2010 at 11:17 AM, Dominick Vanthienen
> <dominick [dot] vanthienen [..] ...> wrote:
>
>> hi
>>
>> I made a program with two components
>> when I give them the same period, they are executed in the same thread
>>
>> I expect a blocking call from one of them, this should not block the other
>> component
>> => How do I get them in different threads with the same period?
>>
>
> There is a difference in using Activity vs PeriodicActivity (see e.g.
> <http://people.mech.kuleuven.be/~orocos/pub/documentation/rtt/v1.10.x/doc-xml/orocos-rtt-changes.html>,
> although it is by far a complete description of what has changed):
>
> Summary:
> - PeriodicActivies (will be deprecated IIRC) that have the same
> period/priority are executed in the same thread
> - Activities (starting from 1.10) that have the same period and
> priority are executed in different threads. If you want to fall back
> to the "old" behaviour, you need to use SlaveActivies [*], [**].
>
> What do you mean exactly with "blocking call"? Fi. having to
> components in the same thread, does not (necessarily [***]) mean that
> one of them cannot call a method on the other one.
>
> [*] There is one "nasty" side effect of this: Using SlaveActivities
> introduces some kind of coupling between components: You need to
> specify at _compile_ time which component is master and what are the
> slaves, whereas with the old model you could do this at runtime
> (deployment configuration).
> [**] Second caveat: we have already encountered situations where
> Master+Slaves yields a different behaviour from PeriodAcitivies with
> generated code from Simulink models. Unfortunately, we haven't found
> time so far to dig deeper.
> [***] Ofcourse, if that method locks a Mutex that is also locked by
> the others updateHook fi, you're in trouble :-)
>
> HTH,
>
> Klaas
>