?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 [..] ...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

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

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