ExecutionEngine and SlaveActivity

Hello together,
i would create an optimized setup with minimal thread-switching.

Currently i have an Setup with one Master and 2 slaves.

The master is periodically called, the master should then invoke the
slaves by calling their update() method.
Is it allowed to to all of this with _one_ execution engine?

In my test i get an lock, it seems this setup is now allowed. So is
there another way to do this?
I can give the master another exection engine then everything works
fine, but as mentioned i would like to prevent the thread change...

Can this be an bug or enhancement? From my understanding there is no
practical reason that the execution engine from the master couldn’t
execute the slaves too.
It might the execution engine blocks internally because the master is
currently executed... but is this really an "desired" behavior?

Greetings,
Matthias

ExecutionEngine and SlaveActivity

On Mon, Dec 10, 2012 at 09:57:25AM +0100, Matthias Goldhoorn wrote:
> Hello together,
> i would create an optimized setup with minimal thread-switching.
>
> Currently i have an Setup with one Master and 2 slaves.
>
> The master is periodically called, the master should then invoke the
> slaves by calling their update() method.
> Is it allowed to to all of this with _one_ execution engine?

Yes.

> In my test i get an lock, it seems this setup is now allowed. So is
> there another way to do this?

How can we know without you telling us how you did it?

> I can give the master another exection engine then everything works
> fine, but as mentioned i would like to prevent the thread change...
>
> Can this be an bug or enhancement? From my understanding there is no
> practical reason that the execution engine from the master couldn’t
> execute the slaves too.
> It might the execution engine blocks internally because the master is
> currently executed... but is this really an "desired" behavior?

Please provide the details of how you configure your components. In a
nutshell, you need to configure an Activity with "setActivity" for
your master component (as usual), and afterwards call

deployer->setMasterSlaveActivity("master", "slave1")
deployer->setMasterSlaveActivity("master", "slave2")
...

to attach your slaves.

Markus

slaveactivity

Hi all

I want to have one master activity and multiple slave activities, where the slaves activities are triggered
in a strict order. Let's say I have 3 activities A, B and C (with A the master) and I want to run them in that order.
Is there a way to enforce this?

Is it better and possible to define A as master, B as slave of A and C as slave B? In other words, is it possible
to define a SlaveActivity on another SlaveActivity?

regards

Jonas

slaveactivity

If you define a Slave activity, you have to explicitely schedule your slave
from your master. Hence you'll have something like

updateHook() //Master
{
slaveA.schedule()
slaveB.schedule()
slaveC.schedule()
}

So it'll be in the order you wish. Please replace "schedule" by the correct
function call, I can't find which is the good one.

2015-09-17 15:45 GMT+02:00 Jonas Vantilt <jonas [dot] vantilt [..] ...>:

> Hi all
>
>
>
> I want to have one master activity and multiple slave activities, where
> the slaves activities are triggered
>
> in a strict order. Let’s say I have 3 activities A, B and C (with A the
> master) and I want to run them in that order.
>
> Is there a way to enforce this?
>
>
>
> Is it better and possible to define A as master, B as slave of A and C as
> slave B? In other words, is it possible
>
> to define a SlaveActivity on another SlaveActivity?
>
>
>
>
>
> regards
>
>
>
> Jonas
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>

slaveactivity

?Aren't you after FBSched<https://github.com/kmarkus/fbsched>?

Antoine.

________________________________
De : orocos-users-bounces [..] ... <orocos-users-bounces [..] ...> de la part de Willy Lambert <lambert [dot] willy [..] ...>
Envoyé : jeudi 17 septembre 2015 16:21
À : Jonas Vantilt
Cc : orocos-users [..] ...
Objet : Re: [Orocos-users] slaveactivity

If you define a Slave activity, you have to explicitely schedule your slave from your master. Hence you'll have something like

updateHook() //Master
{
slaveA.schedule()
slaveB.schedule()
slaveC.schedule()
}

So it'll be in the order you wish. Please replace "schedule" by the correct function call, I can't find which is the good one.

2015-09-17 15:45 GMT+02:00 Jonas Vantilt <jonas [dot] vantilt [..] ...<mailto:jonas [dot] vantilt [..] ...>>:
Hi all

I want to have one master activity and multiple slave activities, where the slaves activities are triggered
in a strict order. Let's say I have 3 activities A, B and C (with A the master) and I want to run them in that order.
Is there a way to enforce this?

Is it better and possible to define A as master, B as slave of A and C as slave B? In other words, is it possible
to define a SlaveActivity on another SlaveActivity?

regards

Jonas

--
Orocos-Users mailing list
Orocos-Users [..] ...<mailto:Orocos-Users [..] ...>
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users

slaveactivity

On 17/09/2015 20:33, Antoine Rennuit wrote:

Hi Antoine
>
> Aren't you after FBSched <https://github.com/kmarkus/fbsched>?
>
>
I thought you could use 'setMasterSlaveActivity' in the deployer to do
this scheduling.
It works in the sens that their activities are coupled, i.e. changing
the period of the master
also changes the period of the slaves. However the updateHook of the
master does not
trigger the updateHook of the slaves when it is finished. So FBSched
indeed seems to be
an alternative yes.

Can anyone explain me the use of Master Slave activities, because I am
not understanding its
value when it cannot be used to trigger the other components. This is
what I did:

setActivity("component1",1,0,ORO_SCHED_OTHER) #component1 is master
setMasterSlaveActivity("component1", "component2") #component2 is slave of 1
setMasterSlaveActivity("component1","component3") #component3 is slave of 1

component2.configure
component3.configure
component1.start
component2.start
component3.start

This only executes the component1. Component2 and 3 are not run.

Jonas
>
>
> Antoine.
>
>
> ------------------------------------------------------------------------
> *De :* orocos-users-bounces [..] ...
> <orocos-users-bounces [..] ...> de la part de Willy
> Lambert <lambert [dot] willy [..] ...>
> *Envoyé :* jeudi 17 septembre 2015 16:21
> *À :* Jonas Vantilt
> *Cc :* orocos-users [..] ...
> *Objet :* Re: [Orocos-users] slaveactivity
> If you define a Slave activity, you have to explicitely schedule your
> slave from your master. Hence you'll have something like
>
> updateHook() //Master
> {
> slaveA.schedule()
> slaveB.schedule()
> slaveC.schedule()
> }
>
> So it'll be in the order you wish. Please replace "schedule" by the
> correct function call, I can't find which is the good one.
>
> 2015-09-17 15:45 GMT+02:00 Jonas Vantilt <jonas [dot] vantilt [..] ...
> <mailto:jonas [dot] vantilt [..] ...>>:
>
> Hi all
>
> I want to have one master activity and multiple slave activities,
> where the slaves activities are triggered
>
> in a strict order. Let's say I have 3 activities A, B and C (with
> A the master) and I want to run them in that order.
>
> Is there a way to enforce this?
>
> Is it better and possible to define A as master, B as slave of A
> and C as slave B? In other words, is it possible
>
> to define a SlaveActivity on another SlaveActivity?
>
> regards
>
> Jonas
>
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> <mailto:Orocos-Users [..] ...>
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>
>
>

slaveactivity

Hi Jonas,

On 09/18/2015 09:44 AM, Jonas Vantilt wrote:
>
> On 17/09/2015 20:33, Antoine Rennuit wrote:
>
> Hi Antoine
>>
>> ?Aren't you after FBSched <https://github.com/kmarkus/fbsched>?
>>
>>
> I thought you could use 'setMasterSlaveActivity' in the deployer to do
> this scheduling.
> It works in the sens that their activities are coupled, i.e. changing
> the period of the master
> also changes the period of the slaves. However the updateHook of the
> master does not
> trigger the updateHook of the slaves when it is finished. So FBSched
> indeed seems to be
> an alternative yes.
>
> Can anyone explain me the use of Master Slave activities, because I am
> not understanding its
> value when it cannot be used to trigger the other components. This is
> what I did:
>
> setActivity("component1",1,0,ORO_SCHED_OTHER) #component1 is master
> setMasterSlaveActivity("component1", "component2") #component2 is slave of 1
> setMasterSlaveActivity("component1","component3") #component3 is slave of 1
>
> component2.configure
> component3.configure
> component1.start
> component2.start
> component3.start
>
> This only executes the component1. Component2 and 3 are not run.
that is the expected, you should call explicitly in the update hook of
component1 the update of component2 and 3...

probably, if you want to have a component1 that is composable, is better
to delegate the synchronization to a coordination component.

see also the example i did trying to understand the synchronization
problem,

https://github.com/gborghesan/sched_test/blob/master/scripts/sched.lua

with flag==6
this is practically a lua-written FBSsched clone that calls all the
nodes in names_nodes property (string vector), in the order in which
they are presented.

Gianni.

>
> Jonas
>>
>>
>> Antoine.
>>
>>
>> ------------------------------------------------------------------------
>> *De :* orocos-users-bounces [..] ...
>> <orocos-users-bounces [..] ...> de la part de Willy
>> Lambert <lambert [dot] willy [..] ...>
>> *Envoyé :* jeudi 17 septembre 2015 16:21
>> *À :* Jonas Vantilt
>> *Cc :* orocos-users [..] ...
>> *Objet :* Re: [Orocos-users] slaveactivity
>> If you define a Slave activity, you have to explicitely schedule your
>> slave from your master. Hence you'll have something like
>>
>> updateHook() //Master
>> {
>> slaveA.schedule()
>> slaveB.schedule()
>> slaveC.schedule()
>> }
>>
>> So it'll be in the order you wish. Please replace "schedule" by the
>> correct function call, I can't find which is the good one.
>>
>> 2015-09-17 15:45 GMT+02:00 Jonas Vantilt <jonas [dot] vantilt [..] ...
>> <mailto:jonas [dot] vantilt [..] ...>>:
>>
>> Hi all
>>
>> I want to have one master activity and multiple slave activities,
>> where the slaves activities are triggered
>>
>> in a strict order. Let’s say I have 3 activities A, B and C (with
>> A the master) and I want to run them in that order.
>>
>> Is there a way to enforce this?
>>
>> Is it better and possible to define A as master, B as slave of A
>> and C as slave B? In other words, is it possible
>>
>> to define a SlaveActivity on another SlaveActivity?
>>
>> regards
>>
>> Jonas
>>
>>
>> --
>> Orocos-Users mailing list
>> Orocos-Users [..] ...
>> <mailto:Orocos-Users [..] ...>
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>>
>>
>>
>>
>
>
>

ExecutionEngine and SlaveActivity

On 10.12.2012 10:34, Markus Klotzbuecher wrote:
> On Mon, Dec 10, 2012 at 09:57:25AM +0100, Matthias Goldhoorn wrote:
>> Hello together,
>> i would create an optimized setup with minimal thread-switching.
>>
>> Currently i have an Setup with one Master and 2 slaves.
>>
>> The master is periodically called, the master should then invoke the
>> slaves by calling their update() method.
>> Is it allowed to to all of this with _one_ execution engine?
> Yes.
>
>> In my test i get an lock, it seems this setup is now allowed. So is
>> there another way to do this?
> How can we know without you telling us how you did it?
>
>> I can give the master another exection engine then everything works
>> fine, but as mentioned i would like to prevent the thread change...
>>
>> Can this be an bug or enhancement? From my understanding there is no
>> practical reason that the execution engine from the master couldn’t
>> execute the slaves too.
>> It might the execution engine blocks internally because the master is
>> currently executed... but is this really an "desired" behavior?
> Please provide the details of how you configure your components. In a
> nutshell, you need to configure an Activity with "setActivity" for
> your master component (as usual), and afterwards call
>
> deployer->setMasterSlaveActivity("master", "slave1")
> deployer->setMasterSlaveActivity("master", "slave2")
> ...
>
> to attach your slaves.
>
> Markus

I currently try to create/add an scheduling component like your
https://github.com/kmarkus/fbsched to orogen.
For this i have already fixed the slave component creation in orogen on
the rock-branch of orogen.

The scheduling already works with separate execution engines for each
"slave".
To prevent the ContextSwitch i tried to alter (currently manually) the
"main.cpp" which is from orogen created in this way that the slaves use
the same execution engine as the parent.
I attached my "main" file, i altered only these lines.

263 //RTT::extras::SlaveActivity* activity_adder1 = new
RTT::extras::SlaveActivity(activity_main,task_adder1.engine());
264 RTT::extras::SlaveActivity* activity_adder1 = new
RTT::extras::SlaveActivity(activity_main,task_main.engine());

With 263 it works, with 264 not.

Greetings,
Matthias

ExecutionEngine and SlaveActivity

On 12/10/2012 01:15 PM, Matthias Goldhoorn wrote:
>
> I currently try to create/add an scheduling component like your
> https://github.com/kmarkus/fbsched to orogen.
> For this i have already fixed the slave component creation in orogen
> on the rock-branch of orogen.
Which one of these two options is it ? Do you try to integrate fbsched
in the orogen deployments or do you try to create something like an
fbsched component ?

In the second case, why ? Why not use fbsched ?

ExecutionEngine and SlaveActivity

On 10.12.2012 15:05, Sylvain Joyeux wrote:
> On 12/10/2012 01:15 PM, Matthias Goldhoorn wrote:
>>
>> I currently try to create/add an scheduling component like your
>> https://github.com/kmarkus/fbsched to orogen.
>> For this i have already fixed the slave component creation in orogen
>> on the rock-branch of orogen.
> Which one of these two options is it ? Do you try to integrate fbsched
> in the orogen deployments or do you try to create something like an
> fbsched component ?
>
> In the second case, why ? Why not use fbsched ?
>
I created an orogen task that does exactly that what the fbsched
component does.
I copied this, because i don't know if and how i an use this "fbsched"
component in an rock-component system.
So it not directly the fbsched, but an adapted clone of it...

Matthias

ExecutionEngine and SlaveActivity

On 12/10/2012 03:13 PM, Matthias Goldhoorn wrote:
> On 10.12.2012 15:05, Sylvain Joyeux wrote:
>> On 12/10/2012 01:15 PM, Matthias Goldhoorn wrote:
>>>
>>> I currently try to create/add an scheduling component like your
>>> https://github.com/kmarkus/fbsched to orogen.
>>> For this i have already fixed the slave component creation in orogen
>>> on the rock-branch of orogen.
>> Which one of these two options is it ? Do you try to integrate
>> fbsched in the orogen deployments or do you try to create something
>> like an fbsched component ?
>>
>> In the second case, why ? Why not use fbsched ?
>>
> I created an orogen task that does exactly that what the fbsched
> component does.
> I copied this, because i don't know if and how i an use this "fbsched"
> component in an rock-component system.
> So it not directly the fbsched, but an adapted clone of it...
Then, *first try* to use fbsched directly. It is possible, or at least
SHOULD BE possible to use plain orocos components in Rock, and we should
do it when it makes sense (i.e., here) !

You can see that there is rtt.orogen and ocl.orogen files in the oroGen
source code. It is defining the models for RTT::TaskContext and the OCL
reporter. You could do the same for fbsched and start from there ...

Sylvain

ExecutionEngine and SlaveActivity

On Mon, Dec 10, 2012 at 01:15:54PM +0100, Matthias Goldhoorn wrote:
> On 10.12.2012 10:34, Markus Klotzbuecher wrote:
> >On Mon, Dec 10, 2012 at 09:57:25AM +0100, Matthias Goldhoorn wrote:
> >>Hello together,
> >>i would create an optimized setup with minimal thread-switching.
> >>
> >>Currently i have an Setup with one Master and 2 slaves.
> >>
> >>The master is periodically called, the master should then invoke the
> >>slaves by calling their update() method.
> >>Is it allowed to to all of this with _one_ execution engine?
> >Yes.
> >
> >>In my test i get an lock, it seems this setup is now allowed. So is
> >>there another way to do this?
> >How can we know without you telling us how you did it?
> >
> >>I can give the master another exection engine then everything works
> >>fine, but as mentioned i would like to prevent the thread change...
> >>
> >>Can this be an bug or enhancement? From my understanding there is no
> >>practical reason that the execution engine from the master couldn’t
> >>execute the slaves too.
> >>It might the execution engine blocks internally because the master is
> >>currently executed... but is this really an "desired" behavior?
> >Please provide the details of how you configure your components. In a
> >nutshell, you need to configure an Activity with "setActivity" for
> >your master component (as usual), and afterwards call
> >
> >deployer->setMasterSlaveActivity("master", "slave1")
> >deployer->setMasterSlaveActivity("master", "slave2")
> >...
> >
> >to attach your slaves.
> >
> >Markus
>
> I currently try to create/add an scheduling component like your
> https://github.com/kmarkus/fbsched to orogen.
> For this i have already fixed the slave component creation in orogen
> on the rock-branch of orogen.
>
> The scheduling already works with separate execution engines for
> each "slave".
> To prevent the ContextSwitch i tried to alter (currently manually)

Having separate ExecutionEngines does not imply having thread context
switches. When used as described, the fbsched component serialized all
"update()" calls within a single thread.

> the "main.cpp" which is from orogen created in this way that the
> slaves use the same execution engine as the parent.
> I attached my "main" file, i altered only these lines.
>
> 263 //RTT::extras::SlaveActivity* activity_adder1 = new
> RTT::extras::SlaveActivity(activity_main,task_adder1.engine());
> 264 RTT::extras::SlaveActivity* activity_adder1 = new
> RTT::extras::SlaveActivity(activity_main,task_main.engine());
>
> With 263 it works, with 264 not.

I can't comment on whether this should work or not, maybe Peter can
shed some light. I recall that somebody was sharing ExecutionEngines
(or TaskCore's) some time ago in order to reduce the memory
footprint. But as said, you don't need this to avoid thread context
switches.

Markus

ExecutionEngine and SlaveActivity

On Mon, Dec 10, 2012 at 2:59 PM, Markus Klotzbuecher
<markus [dot] klotzbuecher [..] ...> wrote:
> On Mon, Dec 10, 2012 at 01:15:54PM +0100, Matthias Goldhoorn wrote:
>> On 10.12.2012 10:34, Markus Klotzbuecher wrote:
>> >On Mon, Dec 10, 2012 at 09:57:25AM +0100, Matthias Goldhoorn wrote:
>> >>Hello together,
>> >>i would create an optimized setup with minimal thread-switching.
>> >>
>> >>Currently i have an Setup with one Master and 2 slaves.
>> >>
>> >>The master is periodically called, the master should then invoke the
>> >>slaves by calling their update() method.
>> >>Is it allowed to to all of this with _one_ execution engine?
>> >Yes.
>> >
>> >>In my test i get an lock, it seems this setup is now allowed. So is
>> >>there another way to do this?
>> >How can we know without you telling us how you did it?
>> >
>> >>I can give the master another exection engine then everything works
>> >>fine, but as mentioned i would like to prevent the thread change...
>> >>
>> >>Can this be an bug or enhancement? From my understanding there is no
>> >>practical reason that the execution engine from the master couldn’t
>> >>execute the slaves too.
>> >>It might the execution engine blocks internally because the master is
>> >>currently executed... but is this really an "desired" behavior?
>> >Please provide the details of how you configure your components. In a
>> >nutshell, you need to configure an Activity with "setActivity" for
>> >your master component (as usual), and afterwards call
>> >
>> >deployer->setMasterSlaveActivity("master", "slave1")
>> >deployer->setMasterSlaveActivity("master", "slave2")
>> >...
>> >
>> >to attach your slaves.
>> >
>> >Markus
>>
>> I currently try to create/add an scheduling component like your
>> https://github.com/kmarkus/fbsched to orogen.
>> For this i have already fixed the slave component creation in orogen
>> on the rock-branch of orogen.
>>
>> The scheduling already works with separate execution engines for
>> each "slave".
>> To prevent the ContextSwitch i tried to alter (currently manually)
>
> Having separate ExecutionEngines does not imply having thread context
> switches. When used as described, the fbsched component serialized all
> "update()" calls within a single thread.
>
>> the "main.cpp" which is from orogen created in this way that the
>> slaves use the same execution engine as the parent.
>> I attached my "main" file, i altered only these lines.
>>
>> 263 //RTT::extras::SlaveActivity* activity_adder1 = new
>> RTT::extras::SlaveActivity(activity_main,task_adder1.engine());
>> 264 RTT::extras::SlaveActivity* activity_adder1 = new
>> RTT::extras::SlaveActivity(activity_main,task_main.engine());
>>
>> With 263 it works, with 264 not.
>
> I can't comment on whether this should work or not, maybe Peter can
> shed some light. I recall that somebody was sharing ExecutionEngines
> (or TaskCore's) some time ago in order to reduce the memory
> footprint. But as said, you don't need this to avoid thread context
> switches.

Indeed. The sharing of engines is afaikt not tested in combination
with slaves. Even more, when you share engines, only the owner of the
engine needs an activity and the 'slave' component clearly not, since
it does not have a component. So using a SlaveActivity in a shared
engine architecture seems completely messed-up.

Also, the semantics of shared engine components are slightly different
since it can't really fake individual engines, while it is in reality
one (or we need to do a lot of bookkeeping which beats the purpose).

I would happily conditionally exclude shared engines during compilation...

Peter