Dear all,
I have a number of TaskContext instances that I need to be
executed
periodically and in a specific (mandatory!) order. The use
cases range
from in-process multi-threaded (one thread for
TaskContext) to multi-
process or distributed applications, hence this excludes
master-slave
activities and FBSched-based schedulers, since these
serialize
computations in a single thread. Applications will always
run on top
of priority-based RTOSs (RTAI, Xenomai, etc.).
In the current implementation, I create an Activity object
for each
TaskContext. Each Activity is assigned the desired period
and a
priority value according to the desired execution order.
E.g.,
// -----------
// In-process multi-threaded app.
// -----------
// Tasks: Task1, Task2, Task3
// Periods: 0.1s, 0.01s, 0.1s
// Mandatory execution order: Task2, Task1, Task3
//------------
// TaskContexts
Task1 task1("Task1");
Task2 task2("Task2");
Task3 task3("Task3");
// Connections
...
// Activities (priority is reverse exec order)
task1.setActivity( new Activity(2, 0.1) );
task2.setActivity( new Activity(3, 0.01) );
task3.setActivity( new Activity(1, 0.1) );
Does Orocos *guarantee* that, with the settings above,
TaskContext
instances will *always* be executed in the desired order,
provided
that they are started in the right order? I.e,
// Start (in the right exec order)
task2.start();
task1.start();
task3.start();
Alternatively, another approach would be to create a
*non-periodic*
activity for each component, to add an Event port to each
TaskContext
and to add a periodic component to the system. This one
would (i) be
connected to the Event port of the other TaskContexts,
(ii) run
with a period that is the GCD of all the periods, and
(iii) trigger
the execution of the activities (and in turn of
components) in the
desired order. Would this approach be more effective
(reliable) in
your opinion?
Any other approaches to suggest?
Thank you in advance,
--
Matteo
Deterministic execution order of TaskContexts
On Fri, Feb 01, 2013 at 04:43:00PM +0100, Matteo Morelli wrote:
> Dear all,
>
> I have a number of TaskContext instances that I need to be
> executed
> periodically and in a specific (mandatory!) order. The use
> cases range
> from in-process multi-threaded (one thread for
> TaskContext) to multi-
> process or distributed applications, hence this excludes
> master-slave
> activities and FBSched-based schedulers, since these
> serialize
> computations in a single thread. Applications will always
> run on top
> of priority-based RTOSs (RTAI, Xenomai, etc.).
>
> In the current implementation, I create an Activity object
> for each
> TaskContext. Each Activity is assigned the desired period
> and a
> priority value according to the desired execution order.
> E.g.,
>
> // -----------
> // In-process multi-threaded app.
> // -----------
> // Tasks: Task1, Task2, Task3
> // Periods: 0.1s, 0.01s, 0.1s
> // Mandatory execution order: Task2, Task1, Task3
> //------------
>
> // TaskContexts
> Task1 task1("Task1");
> Task2 task2("Task2");
> Task3 task3("Task3");
>
> // Connections
> ...
>
> // Activities (priority is reverse exec order)
> task1.setActivity( new Activity(2, 0.1) );
> task2.setActivity( new Activity(3, 0.01) );
> task3.setActivity( new Activity(1, 0.1) );
>
> Does Orocos *guarantee* that, with the settings above,
> TaskContext
> instances will *always* be executed in the desired order,
> provided
> that they are started in the right order? I.e,
> // Start (in the right exec order)
> task2.start();
> task1.start();
> task3.start();
No, this will certainly not work. Orocos can't make any guarantees
regarding inter-process scheduling. This purely depends on the OS.
> Alternatively, another approach would be to create a
> *non-periodic*
> activity for each component, to add an Event port to each
> TaskContext
> and to add a periodic component to the system. This one
> would (i) be
> connected to the Event port of the other TaskContexts,
> (ii) run
> with a period that is the GCD of all the periods, and
> (iii) trigger
> the execution of the activities (and in turn of
> components) in the
> desired order. Would this approach be more effective
> (reliable) in
> your opinion?
>
> Any other approaches to suggest?
I would try Willy's suggestion (together with the mqueue transport).
Markus
Deterministic execution order of TaskContexts
2013/2/1 Matteo Morelli <matteo [dot] morelli [..] ...>:
> Dear all,
>
> I have a number of TaskContext instances that I need to be
> executed
> periodically and in a specific (mandatory!) order. The use
> cases range
> from in-process multi-threaded (one thread for
> TaskContext) to multi-
> process or distributed applications, hence this excludes
> master-slave
> activities and FBSched-based schedulers, since these
> serialize
> computations in a single thread. Applications will always
> run on top
> of priority-based RTOSs (RTAI, Xenomai, etc.).
>
> In the current implementation, I create an Activity object
> for each
> TaskContext. Each Activity is assigned the desired period
> and a
> priority value according to the desired execution order.
This is a bad idea. It makes scheduling *implicit* and this will
produce a bug sooner or later. You really have to have *explicit
scheduling*. Some years ago I would have done this like you with
priorities, but thanks to pretty advices of some experimented members
here, i do have a much better life since then.
A way to do what you want is to have a "trigger" in/out port on each
component on wich you pubilsh a go when you have finished your work.
The in port are EventPort so you can have non-periodic activities and
you are waken up but the incoming data. Then the scheduling is
explicitely done by the data flow. Just give a periodic activity to
the first component of the chain, and eventually checks that the last
component has published its trigger (else you have overhead).
> E.g.,
>
> // -----------
> // In-process multi-threaded app.
> // -----------
> // Tasks: Task1, Task2, Task3
> // Periods: 0.1s, 0.01s, 0.1s
> // Mandatory execution order: Task2, Task1, Task3
> //------------
>
> // TaskContexts
> Task1 task1("Task1");
> Task2 task2("Task2");
> Task3 task3("Task3");
>
> // Connections
> ...
>
> // Activities (priority is reverse exec order)
> task1.setActivity( new Activity(2, 0.1) );
> task2.setActivity( new Activity(3, 0.01) );
> task3.setActivity( new Activity(1, 0.1) );
>
> Does Orocos *guarantee* that, with the settings above,
> TaskContext
> instances will *always* be executed in the desired order,
> provided
> that they are started in the right order? I.e,
>
> // Start (in the right exec order)
> task2.start();
> task1.start();
> task3.start();
>
> Alternatively, another approach would be to create a
> *non-periodic*
> activity for each component, to add an Event port to each
> TaskContext
> and to add a periodic component to the system. This one
> would (i) be
> connected to the Event port of the other TaskContexts,
> (ii) run
> with a period that is the GCD of all the periods, and
> (iii) trigger
> the execution of the activities (and in turn of
> components) in the
> desired order. Would this approach be more effective
> (reliable) in
> your opinion?
>
> Any other approaches to suggest?
>
> Thank you in advance,
>
> --
> Matteo
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
Deterministic execution order of TaskContexts
On Fri, 1 Feb 2013, Willy Lambert wrote:
> 2013/2/1 Matteo Morelli <matteo [dot] morelli [..] ...>:
>> Dear all,
>>
>> I have a number of TaskContext instances that I need to be
>> executed
>> periodically and in a specific (mandatory!) order. The use
>> cases range
>> from in-process multi-threaded (one thread for
>> TaskContext) to multi-
>> process or distributed applications, hence this excludes
>> master-slave
>> activities and FBSched-based schedulers, since these
>> serialize
>> computations in a single thread. Applications will always
>> run on top
>> of priority-based RTOSs (RTAI, Xenomai, etc.).
>>
>> In the current implementation, I create an Activity object
>> for each
>> TaskContext. Each Activity is assigned the desired period
>> and a
>> priority value according to the desired execution order.
>
> This is a bad idea. It makes scheduling *implicit* and this will
> produce a bug sooner or later. You really have to have *explicit
> scheduling*. Some years ago I would have done this like you with
> priorities, but thanks to pretty advices of some experimented members
> here, i do have a much better life since then.
>
> A way to do what you want is to have a "trigger" in/out port on each
> component on wich you pubilsh a go when you have finished your work.
> The in port are EventPort so you can have non-periodic activities and
> you are waken up but the incoming data. Then the scheduling is
> explicitely done by the data flow. Just give a periodic activity to
> the first component of the chain, and eventually checks that the last
> component has published its trigger (else you have overhead).
I agree with this. And it is such a fundamental use case that we should
provide a "standard solution" in which such time triggering and scheduling
are provided. (And well documented.)
Herman
>
>> E.g.,
>>
>> // -----------
>> // In-process multi-threaded app.
>> // -----------
>> // Tasks: Task1, Task2, Task3
>> // Periods: 0.1s, 0.01s, 0.1s
>> // Mandatory execution order: Task2, Task1, Task3
>> //------------
>>
>> // TaskContexts
>> Task1 task1("Task1");
>> Task2 task2("Task2");
>> Task3 task3("Task3");
>>
>> // Connections
>> ...
>>
>> // Activities (priority is reverse exec order)
>> task1.setActivity( new Activity(2, 0.1) );
>> task2.setActivity( new Activity(3, 0.01) );
>> task3.setActivity( new Activity(1, 0.1) );
>>
>> Does Orocos *guarantee* that, with the settings above,
>> TaskContext
>> instances will *always* be executed in the desired order,
>> provided
>> that they are started in the right order? I.e,
>>
>> // Start (in the right exec order)
>> task2.start();
>> task1.start();
>> task3.start();
>>
>> Alternatively, another approach would be to create a
>> *non-periodic*
>> activity for each component, to add an Event port to each
>> TaskContext
>> and to add a periodic component to the system. This one
>> would (i) be
>> connected to the Event port of the other TaskContexts,
>> (ii) run
>> with a period that is the GCD of all the periods, and
>> (iii) trigger
>> the execution of the activities (and in turn of
>> components) in the
>> desired order. Would this approach be more effective
>> (reliable) in
>> your opinion?
>>
>> Any other approaches to suggest?
>>
>> Thank you in advance,
>>
>> --
>> Matteo
Deterministic execution order of TaskContexts
On Sat, 2 Feb 2013 12:18:22 +0100 (CET)
Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
wrote:
> On Fri, 1 Feb 2013, Willy Lambert wrote:
>
>> 2013/2/1 Matteo Morelli <matteo [dot] morelli [..] ...>:
>>> Dear all,
>>>
>>> I have a number of TaskContext instances that I need to
>>>be
>>> executed
>>> periodically and in a specific (mandatory!) order. The
>>>use
>>> cases range
>>> from in-process multi-threaded (one thread for
>>> TaskContext) to multi-
>>> process or distributed applications, hence this excludes
>>> master-slave
>>> activities and FBSched-based schedulers, since these
>>> serialize
>>> computations in a single thread. Applications will
>>>always
>>> run on top
>>> of priority-based RTOSs (RTAI, Xenomai, etc.).
>>>
>>> In the current implementation, I create an Activity
>>>object
>>> for each
>>> TaskContext. Each Activity is assigned the desired
>>>period
>>> and a
>>> priority value according to the desired execution order.
>>
>> This is a bad idea. It makes scheduling *implicit* and
>>this will
>> produce a bug sooner or later.
Why? According to the doc, activity priorities are passed
directly to the underlying RTOS. Provided that the RTOS
implements properly a priority-based scheduling policy, I
see no reason why the approach shouldn't work.
Well, in fact, I assign priority values so as a specific
execution order is defined when multiple threads are
*activated at the same time*, and that preserves
precedence constraints between TaskContexts (e.g., tcA is
the only one that can start executing; as tcA is
completed, either tcB or tcC can start according to the
arrival time), and I attempt to activate all the
activities (threads) *synchronously* at time 0 as follows:
tcA.start(); // Highest prio
tcB.start();
tcC.start(); // Lowest prio
However, TaskContext::start() does not start the
corresponding thread immediately: it calls
TaskCore::start() that calls TaskCore::trigger() that
calls Activity::trigger() that finally calls
Thread::start(). Therefore, tcA.start() may well be
interrupted by a lower priority TaskContext that starts
its thread before tcA and breaks precedence constraints.
Are you referring to this when you say that this approach
won't work?
>> A way to do what you want is to have a "trigger" in/out
>>port on each
>> component on wich you pubilsh a go when you have
>>finished your work.
>> The in port are EventPort so you can have non-periodic
>>activities and
>> you are waken up but the incoming data. Then the
>>scheduling is
>> explicitely done by the data flow. Just give a periodic
>>activity to
>> the first component of the chain, and eventually checks
>>that the last
>> component has published its trigger (else you have
>>overhead).
>
> I agree with this.
I may be wrong here but, what would be the difference from
serializing all the computations in a single thread then?
In the original post, I proposed an approach where events
are used to realize synchronous activation of a number of
threads with the same period, that are then scheduled
according to the priority order (by the RTOS). In
practice, an additional component would trigger the
execution of the activities in the desired order, but
wouldn't start() a lower priority Activity (and the
corresponding TaskContext) until the higher priority one
notifies that it is actually active. Is this approach
reliable in your opinion?
Or, do you have another solution in RTT to perform
synchronous activation of a number of TaskContexts?
Thank you in advance,
--
Matteo
>And it is such a fundamental use case
>that we should
> provide a "standard solution" in which such time
>triggering and scheduling
> are provided. (And well documented.)
>
> Herman
>
>>
>>> E.g.,
>>>
>>> // -----------
>>> // In-process multi-threaded app.
>>> // -----------
>>> // Tasks: Task1, Task2, Task3
>>> // Periods: 0.1s, 0.01s, 0.1s
>>> // Mandatory execution order: Task2, Task1, Task3
>>> //------------
>>>
>>> // TaskContexts
>>> Task1 task1("Task1");
>>> Task2 task2("Task2");
>>> Task3 task3("Task3");
>>>
>>> // Connections
>>> ...
>>>
>>> // Activities (priority is reverse exec order)
>>> task1.setActivity( new Activity(2, 0.1) );
>>> task2.setActivity( new Activity(3, 0.01) );
>>> task3.setActivity( new Activity(1, 0.1) );
>>>
>>> Does Orocos *guarantee* that, with the settings above,
>>> TaskContext
>>> instances will *always* be executed in the desired
>>>order,
>>> provided
>>> that they are started in the right order? I.e,
>>>
>>> // Start (in the right exec order)
>>> task2.start();
>>> task1.start();
>>> task3.start();
>>>
>>> Alternatively, another approach would be to create a
>>> *non-periodic*
>>> activity for each component, to add an Event port to
>>>each
>>> TaskContext
>>> and to add a periodic component to the system. This one
>>> would (i) be
>>> connected to the Event port of the other TaskContexts,
>>> (ii) run
>>> with a period that is the GCD of all the periods, and
>>> (iii) trigger
>>> the execution of the activities (and in turn of
>>> components) in the
>>> desired order. Would this approach be more effective
>>> (reliable) in
>>> your opinion?
>>>
>>> Any other approaches to suggest?
>>>
>>> Thank you in advance,
>>>
>>> --
>>> Matteo
Deterministic execution order of TaskContexts
2013/2/4 Matteo Morelli <matteo [dot] morelli [..] ...>:
> On Sat, 2 Feb 2013 12:18:22 +0100 (CET)
> Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...> wrote:
>>
>> On Fri, 1 Feb 2013, Willy Lambert wrote:
>>
>>> 2013/2/1 Matteo Morelli <matteo [dot] morelli [..] ...>:
>>>>
>>>> Dear all,
>>>>
>>>> I have a number of TaskContext instances that I need to be
>>>> executed
>>>> periodically and in a specific (mandatory!) order. The use
>>>> cases range
>>>> from in-process multi-threaded (one thread for
>>>> TaskContext) to multi-
>>>> process or distributed applications, hence this excludes
>>>> master-slave
>>>> activities and FBSched-based schedulers, since these
>>>> serialize
>>>> computations in a single thread. Applications will always
>>>> run on top
>>>> of priority-based RTOSs (RTAI, Xenomai, etc.).
>>>>
>>>> In the current implementation, I create an Activity object
>>>> for each
>>>> TaskContext. Each Activity is assigned the desired period
>>>> and a
>>>> priority value according to the desired execution order.
>>>
>>>
>>> This is a bad idea. It makes scheduling *implicit* and this will
>>> produce a bug sooner or later.
>
>
> Why? According to the doc, activity priorities are passed directly to the
> underlying RTOS. Provided that the RTOS implements properly a priority-based
> scheduling policy, I see no reason why the approach shouldn't work.
>
Doing so will always end in unterminable explanations to prove your
realtimeness, which is complex, and error prone as it is implicit and
required you to think about what will happen. So you are going to
write an endless document to say "if this, then that, by if that don't
do this because this,..."... And I'm not speaking about priority
inversions.
If you are lucky you have a tool to do mathematical proof of your
scheduling automatically, but this is very rare in real life.
Moreover, I wish you good luck to have a test that is stressing your
system in a representative way to trigger all possibilities.
On the other board, in explicitly doing your scheduling, you *specify*
what has to happen. So you know *by definition* that it will work as
expected. Which by far more convienent to do this *by proof* (which
supposed you did not forget anything, which is impossible in a real
complex scheduling.). Testing your system in this way is as simple as
any specification test. The main thing to monitor will be overheads.
In practice, and as RTOS scheduler are based on priorities and not on
explicit scheduling, you will have to mix both things. But the more
explicit priorities you have inside your application the easier is
your life ;p
It's just my young view of all this. I'm not an expert, you may balance this.
> Well, in fact, I assign priority values so as a specific execution order is
> defined when multiple threads are *activated at the same time*, and that
> preserves precedence constraints between TaskContexts (e.g., tcA is the only
> one that can start executing; as tcA is completed, either tcB or tcC can
> start according to the arrival time), and I attempt to activate all the
> activities (threads) *synchronously* at time 0 as follows:
>
> tcA.start(); // Highest prio
> tcB.start();
> tcC.start(); // Lowest prio
>
> However, TaskContext::start() does not start the corresponding thread
> immediately: it calls TaskCore::start() that calls TaskCore::trigger() that
> calls Activity::trigger() that finally calls Thread::start(). Therefore,
> tcA.start() may well be interrupted by a lower priority TaskContext that
> starts its thread before tcA and breaks precedence constraints. Are you
> referring to this when you say that this approach won't work?
>
>
>>> A way to do what you want is to have a "trigger" in/out port on each
>>> component on wich you pubilsh a go when you have finished your work.
>>> The in port are EventPort so you can have non-periodic activities and
>>> you are waken up but the incoming data. Then the scheduling is
>>> explicitely done by the data flow. Just give a periodic activity to
>>> the first component of the chain, and eventually checks that the last
>>> component has published its trigger (else you have overhead).
>>
>>
>> I agree with this.
>
>
> I may be wrong here but, what would be the difference from serializing all
> the computations in a single thread then?
>
> In the original post, I proposed an approach where events are used to
> realize synchronous activation of a number of threads with the same period,
> that are then scheduled according to the priority order (by the RTOS). In
> practice, an additional component would trigger the execution of the
> activities in the desired order, but wouldn't start() a lower priority
> Activity (and the corresponding TaskContext) until the higher priority one
> notifies that it is actually active. Is this approach reliable in your
> opinion?
>
> Or, do you have another solution in RTT to perform synchronous activation of
> a number of TaskContexts?
>
>
> Thank you in advance,
>
> --
> Matteo
>
>
>> And it is such a fundamental use case that we should
>> provide a "standard solution" in which such time triggering and scheduling
>> are provided. (And well documented.)
>>
>> Herman
>>
>>>
>>>> E.g.,
>>>>
>>>> // -----------
>>>> // In-process multi-threaded app.
>>>> // -----------
>>>> // Tasks: Task1, Task2, Task3
>>>> // Periods: 0.1s, 0.01s, 0.1s
>>>> // Mandatory execution order: Task2, Task1, Task3
>>>> //------------
>>>>
>>>> // TaskContexts
>>>> Task1 task1("Task1");
>>>> Task2 task2("Task2");
>>>> Task3 task3("Task3");
>>>>
>>>> // Connections
>>>> ...
>>>>
>>>> // Activities (priority is reverse exec order)
>>>> task1.setActivity( new Activity(2, 0.1) );
>>>> task2.setActivity( new Activity(3, 0.01) );
>>>> task3.setActivity( new Activity(1, 0.1) );
>>>>
>>>> Does Orocos *guarantee* that, with the settings above,
>>>> TaskContext
>>>> instances will *always* be executed in the desired order,
>>>> provided
>>>> that they are started in the right order? I.e,
>>>>
>>>> // Start (in the right exec order)
>>>> task2.start();
>>>> task1.start();
>>>> task3.start();
>>>>
>>>> Alternatively, another approach would be to create a
>>>> *non-periodic*
>>>> activity for each component, to add an Event port to each
>>>> TaskContext
>>>> and to add a periodic component to the system. This one
>>>> would (i) be
>>>> connected to the Event port of the other TaskContexts,
>>>> (ii) run
>>>> with a period that is the GCD of all the periods, and
>>>> (iii) trigger
>>>> the execution of the activities (and in turn of
>>>> components) in the
>>>> desired order. Would this approach be more effective
>>>> (reliable) in
>>>> your opinion?
>>>>
>>>> Any other approaches to suggest?
>>>>
>>>> Thank you in advance,
>>>>
>>>> --
>>>> Matteo
>
>
Deterministic execution order of TaskContexts
On Mon, 04 Feb 2013 00:54:20 +0100
"Matteo Morelli" <matteo [dot] morelli [..] ...> wrote:
> On Sat, 2 Feb 2013 12:18:22 +0100 (CET)
> Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> wrote:
>> On Fri, 1 Feb 2013, Willy Lambert wrote:
>>
>>> 2013/2/1 Matteo Morelli <matteo [dot] morelli [..] ...>:
>>>> Dear all,
>>>>
>>>> I have a number of TaskContext instances that I need to
>>>>be
>>>> executed
>>>> periodically and in a specific (mandatory!) order. The
>>>>use
>>>> cases range
>>>> from in-process multi-threaded (one thread for
>>>> TaskContext) to multi-
>>>> process or distributed applications, hence this excludes
>>>> master-slave
>>>> activities and FBSched-based schedulers, since these
>>>> serialize
>>>> computations in a single thread. Applications will
>>>>always
>>>> run on top
>>>> of priority-based RTOSs (RTAI, Xenomai, etc.).
>>>>
>>>> In the current implementation, I create an Activity
>>>>object
>>>> for each
>>>> TaskContext. Each Activity is assigned the desired
>>>>period
>>>> and a
>>>> priority value according to the desired execution order.
>>>
>>> This is a bad idea. It makes scheduling *implicit* and
>>>this will
>>> produce a bug sooner or later.
>
> Why? According to the doc, activity priorities are
>passed
> directly to the underlying RTOS. Provided that the RTOS
> implements properly a priority-based scheduling policy,
>I
> see no reason why the approach shouldn't work.
>
> Well, in fact, I assign priority values so as a specific
> execution order is defined when multiple threads are
> *activated at the same time*, and that preserves
> precedence constraints between TaskContexts (e.g., tcA
>is
> the only one that can start executing; as tcA is
> completed, either tcB or tcC can start according to the
> arrival time), and I attempt to activate all the
> activities (threads) *synchronously* at time 0 as
>follows:
>
> tcA.start(); // Highest prio
> tcB.start();
> tcC.start(); // Lowest prio
>
> However, TaskContext::start() does not start the
> corresponding thread immediately: it calls
> TaskCore::start() that calls TaskCore::trigger() that
> calls Activity::trigger() that finally calls
> Thread::start().
ok
> Therefore, tcA.start() may well be
> interrupted by a lower priority TaskContext that starts
> its thread before tcA and breaks precedence constraints.
well, no. This is a non-sense. Sorry. The intended
sentence was:
"therefore, there will be an offset in the activation of
TaskContexts that may break the precedence constraints in
the
long run."
Is there a way to perform synchronous activation of a set
of
TaskContexts? Or would you suggest a method that minimizes
the activation offset?
Thanks again,
--
Matteo
> Are you referring to this when you say that this
>approach
> won't work?
>
>>> A way to do what you want is to have a "trigger" in/out
>>>port on each
>>> component on wich you pubilsh a go when you have
>>>finished your work.
>>> The in port are EventPort so you can have non-periodic
>>>activities and
>>> you are waken up but the incoming data. Then the
>>>scheduling is
>>> explicitely done by the data flow. Just give a periodic
>>>activity to
>>> the first component of the chain, and eventually checks
>>>that the last
>>> component has published its trigger (else you have
>>>overhead).
>>
>> I agree with this.
>
> I may be wrong here but, what would be the difference
>from
> serializing all the computations in a single thread
>then?
>
> In the original post, I proposed an approach where
>events
> are used to realize synchronous activation of a number
>of
> threads with the same period, that are then scheduled
> according to the priority order (by the RTOS). In
> practice, an additional component would trigger the
> execution of the activities in the desired order, but
> wouldn't start() a lower priority Activity (and the
> corresponding TaskContext) until the higher priority one
> notifies that it is actually active. Is this approach
> reliable in your opinion?
>
> Or, do you have another solution in RTT to perform
> synchronous activation of a number of TaskContexts?
>
> Thank you in advance,
>
> --
> Matteo
>
>
>>And it is such a fundamental use case
>>that we should
>> provide a "standard solution" in which such time
>>triggering and scheduling
>> are provided. (And well documented.)
>>
>> Herman
>>
>>>
>>>> E.g.,
>>>>
>>>> // -----------
>>>> // In-process multi-threaded app.
>>>> // -----------
>>>> // Tasks: Task1, Task2, Task3
>>>> // Periods: 0.1s, 0.01s, 0.1s
>>>> // Mandatory execution order: Task2, Task1, Task3
>>>> //------------
>>>>
>>>> // TaskContexts
>>>> Task1 task1("Task1");
>>>> Task2 task2("Task2");
>>>> Task3 task3("Task3");
>>>>
>>>> // Connections
>>>> ...
>>>>
>>>> // Activities (priority is reverse exec order)
>>>> task1.setActivity( new Activity(2, 0.1) );
>>>> task2.setActivity( new Activity(3, 0.01) );
>>>> task3.setActivity( new Activity(1, 0.1) );
>>>>
>>>> Does Orocos *guarantee* that, with the settings above,
>>>> TaskContext
>>>> instances will *always* be executed in the desired
>>>>order,
>>>> provided
>>>> that they are started in the right order? I.e,
>>>>
>>>> // Start (in the right exec order)
>>>> task2.start();
>>>> task1.start();
>>>> task3.start();
>>>>
>>>> Alternatively, another approach would be to create a
>>>> *non-periodic*
>>>> activity for each component, to add an Event port to
>>>>each
>>>> TaskContext
>>>> and to add a periodic component to the system. This one
>>>> would (i) be
>>>> connected to the Event port of the other TaskContexts,
>>>> (ii) run
>>>> with a period that is the GCD of all the periods, and
>>>> (iii) trigger
>>>> the execution of the activities (and in turn of
>>>> components) in the
>>>> desired order. Would this approach be more effective
>>>> (reliable) in
>>>> your opinion?
>>>>
>>>> Any other approaches to suggest?
>>>>
>>>> Thank you in advance,
>>>>
>>>> --
>>>> Matteo
>
Deterministic execution order of TaskContexts
2013/2/2 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
> On Fri, 1 Feb 2013, Willy Lambert wrote:
>
>> 2013/2/1 Matteo Morelli <matteo [dot] morelli [..] ...>:
>>>
>>> Dear all,
>>>
>>> I have a number of TaskContext instances that I need to be
>>> executed
>>> periodically and in a specific (mandatory!) order. The use
>>> cases range
>>> from in-process multi-threaded (one thread for
>>> TaskContext) to multi-
>>> process or distributed applications, hence this excludes
>>> master-slave
>>> activities and FBSched-based schedulers, since these
>>> serialize
>>> computations in a single thread. Applications will always
>>> run on top
>>> of priority-based RTOSs (RTAI, Xenomai, etc.).
>>>
>>> In the current implementation, I create an Activity object
>>> for each
>>> TaskContext. Each Activity is assigned the desired period
>>> and a
>>> priority value according to the desired execution order.
>>
>>
>> This is a bad idea. It makes scheduling *implicit* and this will
>> produce a bug sooner or later. You really have to have *explicit
>> scheduling*. Some years ago I would have done this like you with
>> priorities, but thanks to pretty advices of some experimented members
>> here, i do have a much better life since then.
>>
>> A way to do what you want is to have a "trigger" in/out port on each
>> component on wich you pubilsh a go when you have finished your work.
>> The in port are EventPort so you can have non-periodic activities and
>> you are waken up but the incoming data. Then the scheduling is
>> explicitely done by the data flow. Just give a periodic activity to
>> the first component of the chain, and eventually checks that the last
>> component has published its trigger (else you have overhead).
>
>
> I agree with this.
You're the teacher ;p
> And it is such a fundamental use case that we should
> provide a "standard solution" in which such time triggering and scheduling
> are provided. (And well documented.)
>
> Herman
>
>
>>
>>> E.g.,
>>>
>>> // -----------
>>> // In-process multi-threaded app.
>>> // -----------
>>> // Tasks: Task1, Task2, Task3
>>> // Periods: 0.1s, 0.01s, 0.1s
>>> // Mandatory execution order: Task2, Task1, Task3
>>> //------------
>>>
>>> // TaskContexts
>>> Task1 task1("Task1");
>>> Task2 task2("Task2");
>>> Task3 task3("Task3");
>>>
>>> // Connections
>>> ...
>>>
>>> // Activities (priority is reverse exec order)
>>> task1.setActivity( new Activity(2, 0.1) );
>>> task2.setActivity( new Activity(3, 0.01) );
>>> task3.setActivity( new Activity(1, 0.1) );
>>>
>>> Does Orocos *guarantee* that, with the settings above,
>>> TaskContext
>>> instances will *always* be executed in the desired order,
>>> provided
>>> that they are started in the right order? I.e,
>>>
>>> // Start (in the right exec order)
>>> task2.start();
>>> task1.start();
>>> task3.start();
>>>
>>> Alternatively, another approach would be to create a
>>> *non-periodic*
>>> activity for each component, to add an Event port to each
>>> TaskContext
>>> and to add a periodic component to the system. This one
>>> would (i) be
>>> connected to the Event port of the other TaskContexts,
>>> (ii) run
>>> with a period that is the GCD of all the periods, and
>>> (iii) trigger
>>> the execution of the activities (and in turn of
>>> components) in the
>>> desired order. Would this approach be more effective
>>> (reliable) in
>>> your opinion?
>>>
>>> Any other approaches to suggest?
>>>
>>> Thank you in advance,
>>>
>>> --
>>> Matteo