About default activities for components

I'm working on the Activity/Thread classes which are part of
"1.5 Default to activity with one thread per component"

The primary idea was that each component is created
with an activity attached to it. Practically this means that, after creation,
you could try to c->start() it immediately and that c->getActivity() always
returns a valid object (and never null). In addition the component is the
owner of this object. In 1.8, this object is a SequentialActivity (a thread-less
implementation), and voices were raised that defaulting to a thread-backed
activity were more secure and more what new people (the hello world kind of
people) would expect to be present. Enter 'RTT::Activity'.

Having such a rule means you need a default. Defaulting to 'RTT::Activity'
is a good option since it can be made periodic, non periodic, and if necessary,
be replaced by a slave or sequential activity, all during the
configuration phase.
By default, activities would start non-periodic (and the component could still
refuse to start when the user didn't assign an execution period).

However, having a thread created (in the background) also means that
you *must* assign it a priority and put it in a scheduler. The only meaningfull
default here looks like ORO_SCHED_OTHER with a priority of OS::LowestPriority
(so not real-time by default). But I might be missing something here...

Any comments on these defaults ?

Peter

About default activities for components

> I'm working on the Activity/Thread classes which are part of
> "1.5 Default to activity with one thread per component"
>
> The primary idea was that each component is created
> with an activity attached to it. Practically this means that, after
> creation,
> you could try to c->start() it immediately and that c->getActivity()
> always
> returns a valid object (and never null). In addition the component is
the
> owner of this object. In 1.8, this object is a SequentialActivity (a
> thread-less
> implementation), and voices were raised that defaulting to a
thread-backed
> activity were more secure and more what new people (the hello world
kind
> of
> people) would expect to be present. Enter 'RTT::Activity'.
>
> Having such a rule means you need a default. Defaulting to
'RTT::Activity'
> is a good option since it can be made periodic, non periodic, and if
> necessary,
> be replaced by a slave or sequential activity, all during the
> configuration phase.
> By default, activities would start non-periodic (and the component
could
> still
> refuse to start when the user didn't assign an execution period).
>
> However, having a thread created (in the background) also means that
> you *must* assign it a priority and put it in a scheduler. The only
> meaningfull
> default here looks like ORO_SCHED_OTHER with a priority of
> OS::LowestPriority
> (so not real-time by default). But I might be missing something
here...
>
I'm not a big fan of this 'thread creation in background'. We can't
create a thread for each component. So there should be a ctor which
allows me to setup a components activity, pretty much like it its today.
And without any thread creation behind the scene. Also it should be
possible to share resources as much as possible. I'm thinking of sharing
an ExecutionEngine for example, if there is still one needed.

Sander.

About default activities for components

On Fri, 12 Jun 2009, Vandenbroucke Sander wrote:

>>> Because having different scheduling policies is a reality on most
>>> operating systems.
>>
>> It is a reality indeed, but it is not a property of the 'execution
>> container' which is the Activity!
>>
>> This coupling of the execution container with the execution scheduler
> has
>> been introduced early on in the life of Orocos, when we were not
>> sufficiently aware of the consequences. I think it's time to change
> this
>> coupling. Also the naming of the Activities (IRQActivity,
> SlaveActivity,
>> ...) reflects this coupling: nothing in the _inside_ of an Activity
> should
>> reflect this type of an activity, that is, if a computation inside an
>> Activity has to know about it, it should do so by reading a _property_
> of
>> the
>> Activity container. For example, a control law that runs inside of a
>> "classical" "PeriodicActivity" should only know about the period of
>> execution via a corresponding property (and its code should not rely
> on
>> any
>> particular value!), such that an external Coordinator can change this
>> value
>> when needed.
>>
> This example clearly shows that the components internal computation
> implies a periodic invocation. So it is hard to define a default
> activity from the framework's POV, isn't it?

Yes! (Well, it is not _hard_ by itself, but it is hard to provide a default
that is _meaningful_ :-))

> Because in most cases the
> decision what activity to use depends on the component's internal
> computation and the context in which a controller is used in. I really
> don't think that choosing a default activity is the responsibility of
> the framework.

I tend to agree. On the other hand, not choosing a default requires some
user-friendly approach to select the approriate activity property. What
would be, for your use case, such user friendly support approaches...?

Herman

About default activities for components

On Fri, Jun 12, 2009 at 09:09, Vandenbroucke
Sander<Sander [dot] Vandenbroucke [..] ...> wrote:
> I'm not a big fan of this 'thread creation in background'. We can't
> create a thread for each component. So there should be a ctor which
> allows me to setup a components activity, pretty much like it its today.
> And without any thread creation behind the scene. Also it should be
> possible to share resources as much as possible. I'm thinking of sharing
> an ExecutionEngine for example, if there is still one needed.

There will be a compile-time configuration option that dictates what
the default activity will be for a component, such that embedded users
won't be put in front of a completed fact.

We are doing it for lowering the entry barrier of a new user, and to
cover the 95% of the cases where one-thread-per-component is the
reality.

Peter

Overview of Configuration within Orocos/RTT ( About default acti

On Fri, 12 Jun 2009, Peter Soetens wrote:

> On Fri, Jun 12, 2009 at 09:09, Vandenbroucke
> Sander<Sander [dot] Vandenbroucke [..] ...> wrote:
>> I'm not a big fan of this 'thread creation in background'. We can't
>> create a thread for each component. So there should be a ctor which
>> allows me to setup a components activity, pretty much like it its today.
>> And without any thread creation behind the scene. Also it should be
>> possible to share resources as much as possible. I'm thinking of sharing
>> an ExecutionEngine for example, if there is still one needed.
>
> There will be a compile-time configuration option that dictates what
> the default activity will be for a component, such that embedded users
> won't be put in front of a completed fact.
>
> We are doing it for lowering the entry barrier of a new user, and to
> cover the 95% of the cases where one-thread-per-component is the
> reality.
>
Both of you make very valid points, form somewhat different use cases. I
have always claimed that Orocos should do it utmost best to support _all_
usecases, and that was the reason for the high amount of configurability.
I still think this is a good strategy, but we have of course already
encountered several times the drawbacks of this flexibility: steeper
learning curves...

The proven approach to satisfy both centripetal forces (learning curve vs
flexibility) is to provide good documentation and code templates, but
nothing beats "conceptual clearness": things should be designed and named
in such a way that their functionality is "natural". Therefore, I suggest
that the 2.0 milestone is taken as an opportunity to think a bit more about
how we (want to) do configuration within Orocos. There are several
possibilities (compile time, deployment time, runtime) and we should try to
make configuration at all these levels as complementary and consistent as
possible. A first step would be to use very similar names for similar
configuration options, maybe only differing in a pre- or post-fix that
indicates the configuration context (compile time, deployment, runtime)?

Any more concrete suggestions?

Herman

About default activities for components

On Fri, 12 Jun 2009, Vandenbroucke Sander wrote:

>> I'm working on the Activity/Thread classes which are part of
>> "1.5 Default to activity with one thread per component"
>>
>> The primary idea was that each component is created
>> with an activity attached to it. Practically this means that, after
>> creation,
>> you could try to c->start() it immediately and that c->getActivity()
>> always
>> returns a valid object (and never null). In addition the component is
> the
>> owner of this object. In 1.8, this object is a SequentialActivity (a
>> thread-less
>> implementation), and voices were raised that defaulting to a
> thread-backed
>> activity were more secure and more what new people (the hello world
> kind
>> of
>> people) would expect to be present. Enter 'RTT::Activity'.
>>
>> Having such a rule means you need a default. Defaulting to
> 'RTT::Activity'
>> is a good option since it can be made periodic, non periodic, and if
>> necessary,
>> be replaced by a slave or sequential activity, all during the
>> configuration phase.
>> By default, activities would start non-periodic (and the component
> could
>> still
>> refuse to start when the user didn't assign an execution period).
>>
>> However, having a thread created (in the background) also means that
>> you *must* assign it a priority and put it in a scheduler. The only
>> meaningfull
>> default here looks like ORO_SCHED_OTHER with a priority of
>> OS::LowestPriority
>> (so not real-time by default). But I might be missing something
> here...
>>
> I'm not a big fan of this 'thread creation in background'.

Me neither! Execution selection/Configuration/Coordination should be
separated from Activity/Computation definition...

> We can't
> create a thread for each component. So there should be a ctor which
> allows me to setup a components activity, pretty much like it its today.
> And without any thread creation behind the scene. Also it should be
> possible to share resources as much as possible. I'm thinking of sharing
> an ExecutionEngine for example, if there is still one needed.
There _is_ one needed, in my vision: the ExecutionEngine should get a more
visible, even prominent place, as _the_ place to do the "Coordination".

> Sander.

Herman

About default activities for components

> Any comments on these defaults ?
They seem reasonable to me. If someone actually *knows* about what a priority
is, then he probably will be able to find out how to change it ...

About default activities for components

2009/6/11 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
>> Any comments on these defaults ?
> They seem reasonable to me. If someone actually *knows* about what a priority
> is, then he probably will be able to find out how to change it ...

Which made me think... So if no priority is given, we assume a not
real-time task (ORO_SCHED_OTHER).
but when a priority is given, we will assume a real-time task
(ORO_SCHED_RT). This brings me
to this set of constructors:

&#10;       /**&#10;         * @brief Create a not real-time Activity.&#10;         * This creates a not real-time, non-periodic thread.&#10;         *&#10;         * @param _r The optional runner, if none, this-&gt;loop() is called.&#10;         * @param name The name of the underlying thread.&#10;         */&#10;        Activity(RunnableInterface* r = 0, const std::string&amp; name&#10;=&quot;Activity&quot; );&#10;&#10;        /**&#10;         * Create a real-time Activity with a given priority.&#10;         * The thread will run in the ORO_SCHED_RT scheduler.&#10;         *&#10;         * @param priority The priority of the underlying thread.&#10;         * @param _r The optional runner, if none, this-&gt;loop() is called.&#10;         * @param name The name of the underlying thread.&#10;         */&#10;        Activity(int priority, RunnableInterface* _r = 0, const&#10;std::string&amp; name =&quot;Activity&quot; );&#10;&#10;        /**&#10;         * @brief Create a real-time Activity with a given priority and period.&#10;         * The thread is run in the ORO_SCHED_RT scheduler.&#10;         *&#10;         * @param priority&#10;         *        The priority of this activity.&#10;         * @param period&#10;         *        The periodicity of the Activity. A zero is&#10;interpreted as non periodic.&#10;         * @param r&#10;         *        The optional RunnableInterface to run exclusively&#10;within this Activity&#10;         * @param name The name of the underlying thread.&#10;         */&#10;        Activity(int priority, Seconds period, RunnableInterface* r =&#10;0, const std::string&amp; name =&quot;Activity&quot;);&#10;&#10;        /**&#10;         * Create an Activity with a given scheduler type, priority and&#10;         * RunnableInterface instance.&#10;         * @param scheduler&#10;         *        The scheduler in which the activitie&#039;s thread must&#10;run. Use ORO_SCHED_OTHER or&#10;         *        ORO_SCHED_RT.&#10;         * @param priority The priority of the underlying thread.&#10;         * @param _r The optional runner, if none, this-&gt;loop() is called.&#10;         * @param name The name of the underlying thread.&#10;         */&#10;        Activity(int scheduler, int priority, RunnableInterface* _r =&#10;0, const std::string&amp; name =&quot;Activity&quot; );&#10;&#10;        /**&#10;         * @brief Create an Activity with a given scheduler type,&#10;priority and period.&#10;         *&#10;         * @param scheduler&#10;         *        The scheduler in which the activity&#039;s thread must&#10;run. Use ORO_SCHED_OTHER or&#10;         *        ORO_SCHED_RT.&#10;         * @param priority&#10;         *        The priority of this activity.&#10;         * @param period&#10;         *        The periodicity of the Activity&#10;         * @param r&#10;         *        The optional RunnableInterface to run exclusively&#10;within this Activity&#10;         * @param name The name of the underlying thread.&#10;         */&#10;        Activity(int scheduler, int priority, Seconds period,&#10;                RunnableInterface* r = 0, const std::string&amp; name =&quot;Activity&quot;);&#10;

For the constructors with 'scheduler', maybe only the last one should
be kept, users
that want to specify the scheduler, must specify everything
(scheduler, periority, period).

Peter

About default activities for components

On Thu, Jun 11, 2009 at 04:11:12PM +0200, Peter Soetens wrote:
> 2009/6/11 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
> >> Any comments on these defaults ?
> > They seem reasonable to me. If someone actually *knows* about what a priority
> > is, then he probably will be able to find out how to change it ...
>
> Which made me think... So if no priority is given, we assume a not
> real-time task (ORO_SCHED_OTHER).
> but when a priority is given, we will assume a real-time task
> (ORO_SCHED_RT). This brings me
> to this set of constructors:
...

> For the constructors with 'scheduler', maybe only the last one should
> be kept, users
> that want to specify the scheduler, must specify everything
> (scheduler, periority, period).

I agree. I think it is much better understandable to have less
constructors/methods and pass some nil values.

Markus

About default activities for components

On Fri, 12 Jun 2009, Markus Klotzbuecher wrote:

> On Thu, Jun 11, 2009 at 04:11:12PM +0200, Peter Soetens wrote:
>> 2009/6/11 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
>>>> Any comments on these defaults ?
>>> They seem reasonable to me. If someone actually *knows* about what a
>>> priority is, then he probably will be able to find out how to change it
>>> ...

"Probably" is not good enough for me...! :-)

>> Which made me think... So if no priority is given, we assume a not
>> real-time task (ORO_SCHED_OTHER).
>> but when a priority is given, we will assume a real-time task
>> (ORO_SCHED_RT). This brings me
>> to this set of constructors:

Here, I raise my traditional objection against introducing implicit
assumptions into the interfaces.

>> For the constructors with 'scheduler', maybe only the last one should
>> be kept, users that want to specify the scheduler, must specify
>> everything (scheduler, periority, period).
>
> I agree. I think it is much better understandable to have less
> constructors/methods and pass some nil values.

Even better is to separate out the "Coordination" aspects (scheduler,
priorities) from the constructors of Activities, for the simple reason that
the coordination of the execution of an Activity should not be defined by
(the creator of) an Activity, but by the Coordinating component in the
system.

Herman

About default activities for components

On Friday 12 June 2009 09:39:46 Herman Bruyninckx wrote:
> On Fri, 12 Jun 2009, Markus Klotzbuecher wrote:
> > On Thu, Jun 11, 2009 at 04:11:12PM +0200, Peter Soetens wrote:
> >> 2009/6/11 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
> >>>> Any comments on these defaults ?
> >>>
> >>> They seem reasonable to me. If someone actually *knows* about what a
> >>> priority is, then he probably will be able to find out how to change it
> >>> ...
>
> "Probably" is not good enough for me...! :-)
>
> >> Which made me think... So if no priority is given, we assume a not
> >> real-time task (ORO_SCHED_OTHER).
> >> but when a priority is given, we will assume a real-time task
> >> (ORO_SCHED_RT). This brings me
> >> to this set of constructors:
>
> Here, I raise my traditional objection against introducing implicit
> assumptions into the interfaces.
>
> >> For the constructors with 'scheduler', maybe only the last one should
> >> be kept, users that want to specify the scheduler, must specify
> >> everything (scheduler, periority, period).
> >
> > I agree. I think it is much better understandable to have less
> > constructors/methods and pass some nil values.
>
> Even better is to separate out the "Coordination" aspects (scheduler,
> priorities) from the constructors of Activities, for the simple reason that
> the coordination of the execution of an Activity should not be defined by
> (the creator of) an Activity, but by the Coordinating component in the
> system.
Which is the one, in the end, that will determine what are the right values
for those parameters (and maybe change them at runtime if that is supported by
the OS). Having it in the constructor is not incompatible with what you are
seeking, because deployment (providing those parameters) is part of
coordination.

About default activities for components

On Fri, 12 Jun 2009, Sylvain Joyeux wrote:

> On Friday 12 June 2009 09:39:46 Herman Bruyninckx wrote:
>> On Fri, 12 Jun 2009, Markus Klotzbuecher wrote:
>>> On Thu, Jun 11, 2009 at 04:11:12PM +0200, Peter Soetens wrote:
>>>> 2009/6/11 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
>>>>>> Any comments on these defaults ?
>>>>>
>>>>> They seem reasonable to me. If someone actually *knows* about what a
>>>>> priority is, then he probably will be able to find out how to change it
>>>>> ...
>>
>> "Probably" is not good enough for me...! :-)
>>
>>>> Which made me think... So if no priority is given, we assume a not
>>>> real-time task (ORO_SCHED_OTHER).
>>>> but when a priority is given, we will assume a real-time task
>>>> (ORO_SCHED_RT). This brings me
>>>> to this set of constructors:
>>
>> Here, I raise my traditional objection against introducing implicit
>> assumptions into the interfaces.
>>
>>>> For the constructors with 'scheduler', maybe only the last one should
>>>> be kept, users that want to specify the scheduler, must specify
>>>> everything (scheduler, periority, period).
>>>
>>> I agree. I think it is much better understandable to have less
>>> constructors/methods and pass some nil values.
>>
>> Even better is to separate out the "Coordination" aspects (scheduler,
>> priorities) from the constructors of Activities, for the simple reason that
>> the coordination of the execution of an Activity should not be defined by
>> (the creator of) an Activity, but by the Coordinating component in the
>> system.
> Which is the one, in the end, that will determine what are the right values
> for those parameters (and maybe change them at runtime if that is supported by
> the OS). Having it in the constructor is not incompatible with what you are
> seeking, because deployment (providing those parameters) is part of
> coordination.

I agree very much that deployment is part of coordination (and
configuration), but I do not agree that the object-to-be-coordinated
(externally!) gets a creator that defines/configures its (external!)
coordination.

Herman

About default activities for components

On Thu, Jun 11, 2009 at 4:11 PM, Peter Soetens <peter [..] ...>wrote:

> 2009/6/11 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
> >> Any comments on these defaults ?
> > They seem reasonable to me. If someone actually *knows* about what a
> priority
> > is, then he probably will be able to find out how to change it ...
>
> Which made me think... So if no priority is given, we assume a not
> real-time task (ORO_SCHED_OTHER).
> but when a priority is given, we will assume a real-time task
> (ORO_SCHED_RT). This brings me
> to this set of constructors:
>
> &#10;&gt;       /**&#10;&gt;         * @brief Create a not real-time Activity.&#10;&gt;         * This creates a not real-time, non-periodic thread.&#10;&gt;         *&#10;&gt;         * @param _r The optional runner, if none, this-&gt;loop() is called.&#10;&gt;         * @param name The name of the underlying thread.&#10;&gt;         */&#10;&gt;        Activity(RunnableInterface* r = 0, const std::string&amp; name&#10;&gt; =&quot;Activity&quot; );&#10;&gt;&#10;&gt;        /**&#10;&gt;         * Create a real-time Activity with a given priority.&#10;&gt;         * The thread will run in the ORO_SCHED_RT scheduler.&#10;&gt;         *&#10;&gt;         * @param priority The priority of the underlying thread.&#10;&gt;         * @param _r The optional runner, if none, this-&gt;loop() is called.&#10;&gt;         * @param name The name of the underlying thread.&#10;&gt;         */&#10;&gt;        Activity(int priority, RunnableInterface* _r = 0, const&#10;&gt; std::string&amp; name =&quot;Activity&quot; );&#10;&gt;&#10;&gt;        /**&#10;&gt;         * @brief Create a real-time Activity with a given priority and&#10;&gt; period.&#10;&gt;         * The thread is run in the ORO_SCHED_RT scheduler.&#10;&gt;         *&#10;&gt;         * @param priority&#10;&gt;         *        The priority of this activity.&#10;&gt;         * @param period&#10;&gt;         *        The periodicity of the Activity. A zero is&#10;&gt; interpreted as non periodic.&#10;&gt;         * @param r&#10;&gt;         *        The optional RunnableInterface to run exclusively&#10;&gt; within this Activity&#10;&gt;         * @param name The name of the underlying thread.&#10;&gt;         */&#10;&gt;        Activity(int priority, Seconds period, RunnableInterface* r =&#10;&gt; 0, const std::string&amp; name =&quot;Activity&quot;);&#10;&gt;&#10;&gt;        /**&#10;&gt;         * Create an Activity with a given scheduler type, priority and&#10;&gt;         * RunnableInterface instance.&#10;&gt;         * @param scheduler&#10;&gt;         *        The scheduler in which the activitie&#039;s thread must&#10;&gt; run. Use ORO_SCHED_OTHER or&#10;&gt;         *        ORO_SCHED_RT.&#10;&gt;         * @param priority The priority of the underlying thread.&#10;&gt;         * @param _r The optional runner, if none, this-&gt;loop() is called.&#10;&gt;         * @param name The name of the underlying thread.&#10;&gt;         */&#10;&gt;        Activity(int scheduler, int priority, RunnableInterface* _r =&#10;&gt; 0, const std::string&amp; name =&quot;Activity&quot; );&#10;&gt;&#10;&gt;        /**&#10;&gt;         * @brief Create an Activity with a given scheduler type,&#10;&gt; priority and period.&#10;&gt;         *&#10;&gt;         * @param scheduler&#10;&gt;         *        The scheduler in which the activity&#039;s thread must&#10;&gt; run. Use ORO_SCHED_OTHER or&#10;&gt;         *        ORO_SCHED_RT.&#10;&gt;         * @param priority&#10;&gt;         *        The priority of this activity.&#10;&gt;         * @param period&#10;&gt;         *        The periodicity of the Activity&#10;&gt;         * @param r&#10;&gt;         *        The optional RunnableInterface to run exclusively&#10;&gt; within this Activity&#10;&gt;         * @param name The name of the underlying thread.&#10;&gt;         */&#10;&gt;        Activity(int scheduler, int priority, Seconds period,&#10;&gt;                RunnableInterface* r = 0, const std::string&amp; name&#10;&gt; =&quot;Activity&quot;);&#10;&gt;
>
> For the constructors with 'scheduler', maybe only the last one should
> be kept, users
> that want to specify the scheduler, must specify everything
> (scheduler, periority, period).

If you do away with the second-to-last constructor, how would I specify a
non-periodic activity (with a specific scheduler)?

>
> Peter
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>

About default activities for components

2009/6/11 Adolfo Rodríguez Tsouroukdissian <adolfo [dot] rodriguez [..] ...>:
>
>
> On Thu, Jun 11, 2009 at 4:11 PM, Peter Soetens <peter [..] ...>
> wrote:
>>
>> 2009/6/11 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
>> >> Any comments on these defaults ?
>> > They seem reasonable to me. If someone actually *knows* about what a
>> > priority
>> > is, then he probably will be able to find out how to change it ...
>>
>> Which made me think... So if no priority is given, we assume a not
>> real-time task (ORO_SCHED_OTHER).
>> but when a priority is given, we will assume a real-time task
>> (ORO_SCHED_RT). This brings me
>> to this set of constructors:
>>
>> &#10;&gt;&gt;       /**&#10;&gt;&gt;         * @brief Create a not real-time Activity.&#10;&gt;&gt;         * This creates a not real-time, non-periodic thread.&#10;&gt;&gt;         *&#10;&gt;&gt;         * @param _r The optional runner, if none, this-&gt;loop() is called.&#10;&gt;&gt;         * @param name The name of the underlying thread.&#10;&gt;&gt;         */&#10;&gt;&gt;        Activity(RunnableInterface* r = 0, const std::string&amp; name&#10;&gt;&gt; =&quot;Activity&quot; );&#10;&gt;&gt;&#10;&gt;&gt;        /**&#10;&gt;&gt;         * Create a real-time Activity with a given priority.&#10;&gt;&gt;         * The thread will run in the ORO_SCHED_RT scheduler.&#10;&gt;&gt;         *&#10;&gt;&gt;         * @param priority The priority of the underlying thread.&#10;&gt;&gt;         * @param _r The optional runner, if none, this-&gt;loop() is called.&#10;&gt;&gt;         * @param name The name of the underlying thread.&#10;&gt;&gt;         */&#10;&gt;&gt;        Activity(int priority, RunnableInterface* _r = 0, const&#10;&gt;&gt; std::string&amp; name =&quot;Activity&quot; );&#10;&gt;&gt;&#10;&gt;&gt;        /**&#10;&gt;&gt;         * @brief Create a real-time Activity with a given priority and&#10;&gt;&gt; period.&#10;&gt;&gt;         * The thread is run in the ORO_SCHED_RT scheduler.&#10;&gt;&gt;         *&#10;&gt;&gt;         * @param priority&#10;&gt;&gt;         *        The priority of this activity.&#10;&gt;&gt;         * @param period&#10;&gt;&gt;         *        The periodicity of the Activity. A zero is&#10;&gt;&gt; interpreted as non periodic.&#10;&gt;&gt;         * @param r&#10;&gt;&gt;         *        The optional RunnableInterface to run exclusively&#10;&gt;&gt; within this Activity&#10;&gt;&gt;         * @param name The name of the underlying thread.&#10;&gt;&gt;         */&#10;&gt;&gt;        Activity(int priority, Seconds period, RunnableInterface* r =&#10;&gt;&gt; 0, const std::string&amp; name =&quot;Activity&quot;);&#10;&gt;&gt;&#10;&gt;&gt;        /**&#10;&gt;&gt;         * Create an Activity with a given scheduler type, priority and&#10;&gt;&gt;         * RunnableInterface instance.&#10;&gt;&gt;         * @param scheduler&#10;&gt;&gt;         *        The scheduler in which the activitie&#039;s thread must&#10;&gt;&gt; run. Use ORO_SCHED_OTHER or&#10;&gt;&gt;         *        ORO_SCHED_RT.&#10;&gt;&gt;         * @param priority The priority of the underlying thread.&#10;&gt;&gt;         * @param _r The optional runner, if none, this-&gt;loop() is called.&#10;&gt;&gt;         * @param name The name of the underlying thread.&#10;&gt;&gt;         */&#10;&gt;&gt;        Activity(int scheduler, int priority, RunnableInterface* _r =&#10;&gt;&gt; 0, const std::string&amp; name =&quot;Activity&quot; );&#10;&gt;&gt;&#10;&gt;&gt;        /**&#10;&gt;&gt;         * @brief Create an Activity with a given scheduler type,&#10;&gt;&gt; priority and period.&#10;&gt;&gt;         *&#10;&gt;&gt;         * @param scheduler&#10;&gt;&gt;         *        The scheduler in which the activity&#039;s thread must&#10;&gt;&gt; run. Use ORO_SCHED_OTHER or&#10;&gt;&gt;         *        ORO_SCHED_RT.&#10;&gt;&gt;         * @param priority&#10;&gt;&gt;         *        The priority of this activity.&#10;&gt;&gt;         * @param period&#10;&gt;&gt;         *        The periodicity of the Activity&#10;&gt;&gt;         * @param r&#10;&gt;&gt;         *        The optional RunnableInterface to run exclusively&#10;&gt;&gt; within this Activity&#10;&gt;&gt;         * @param name The name of the underlying thread.&#10;&gt;&gt;         */&#10;&gt;&gt;        Activity(int scheduler, int priority, Seconds period,&#10;&gt;&gt;                RunnableInterface* r = 0, const std::string&amp; name&#10;&gt;&gt; =&quot;Activity&quot;);&#10;&gt;&gt;
>>
>> For the constructors with 'scheduler', maybe only the last one should
>> be kept, users
>> that want to specify the scheduler, must specify everything
>> (scheduler, periority, period).
>
> If you do away with the second-to-last constructor, how would I specify a
> non-periodic activity (with a specific scheduler)?

By providing 0.0 as the execution period.

Peter

About default activities for components

On Jun 11, 2009, at 10:11 , Peter Soetens wrote:

> 2009/6/11 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
>>> Any comments on these defaults ?
>> They seem reasonable to me. If someone actually *knows* about what
>> a priority
>> is, then he probably will be able to find out how to change it ...
>
> Which made me think... So if no priority is given, we assume a not
> real-time task (ORO_SCHED_OTHER).
> but when a priority is given, we will assume a real-time task
> (ORO_SCHED_RT). This brings me
> to this set of constructors:
>
> &#10;&gt;       /**&#10;&gt;         * @brief Create a not real-time Activity.&#10;&gt;         * This creates a not real-time, non-periodic thread.&#10;&gt;         *&#10;&gt;         * @param _r The optional runner, if none, this-&gt;loop() is  &#10;&gt; called.&#10;&gt;         * @param name The name of the underlying thread.&#10;&gt;         */&#10;&gt;        Activity(RunnableInterface* r = 0, const std::string&amp; name&#10;&gt; =&quot;Activity&quot; );&#10;&gt;&#10;&gt;        /**&#10;&gt;         * Create a real-time Activity with a given priority.&#10;&gt;         * The thread will run in the ORO_SCHED_RT scheduler.&#10;&gt;         *&#10;&gt;         * @param priority The priority of the underlying thread.&#10;&gt;         * @param _r The optional runner, if none, this-&gt;loop() is  &#10;&gt; called.&#10;&gt;         * @param name The name of the underlying thread.&#10;&gt;         */&#10;&gt;        Activity(int priority, RunnableInterface* _r = 0, const&#10;&gt; std::string&amp; name =&quot;Activity&quot; );&#10;&gt;&#10;&gt;        /**&#10;&gt;         * @brief Create a real-time Activity with a given priority  &#10;&gt; and period.&#10;&gt;         * The thread is run in the ORO_SCHED_RT scheduler.&#10;&gt;         *&#10;&gt;         * @param priority&#10;&gt;         *        The priority of this activity.&#10;&gt;         * @param period&#10;&gt;         *        The periodicity of the Activity. A zero is&#10;&gt; interpreted as non periodic.&#10;&gt;         * @param r&#10;&gt;         *        The optional RunnableInterface to run exclusively&#10;&gt; within this Activity&#10;&gt;         * @param name The name of the underlying thread.&#10;&gt;         */&#10;&gt;        Activity(int priority, Seconds period, RunnableInterface* r =&#10;&gt; 0, const std::string&amp; name =&quot;Activity&quot;);&#10;&gt;&#10;&gt;        /**&#10;&gt;         * Create an Activity with a given scheduler type, priority and&#10;&gt;         * RunnableInterface instance.&#10;&gt;         * @param scheduler&#10;&gt;         *        The scheduler in which the activitie&#039;s thread must&#10;&gt; run. Use ORO_SCHED_OTHER or&#10;&gt;         *        ORO_SCHED_RT.&#10;&gt;         * @param priority The priority of the underlying thread.&#10;&gt;         * @param _r The optional runner, if none, this-&gt;loop() is  &#10;&gt; called.&#10;&gt;         * @param name The name of the underlying thread.&#10;&gt;         */&#10;&gt;        Activity(int scheduler, int priority, RunnableInterface* _r =&#10;&gt; 0, const std::string&amp; name =&quot;Activity&quot; );&#10;&gt;&#10;&gt;        /**&#10;&gt;         * @brief Create an Activity with a given scheduler type,&#10;&gt; priority and period.&#10;&gt;         *&#10;&gt;         * @param scheduler&#10;&gt;         *        The scheduler in which the activity&#039;s thread must&#10;&gt; run. Use ORO_SCHED_OTHER or&#10;&gt;         *        ORO_SCHED_RT.&#10;&gt;         * @param priority&#10;&gt;         *        The priority of this activity.&#10;&gt;         * @param period&#10;&gt;         *        The periodicity of the Activity&#10;&gt;         * @param r&#10;&gt;         *        The optional RunnableInterface to run exclusively&#10;&gt; within this Activity&#10;&gt;         * @param name The name of the underlying thread.&#10;&gt;         */&#10;&gt;        Activity(int scheduler, int priority, Seconds period,&#10;&gt;                RunnableInterface* r = 0, const std::string&amp; name  &#10;&gt; =&quot;Activity&quot;);&#10;&gt;
>
> For the constructors with 'scheduler', maybe only the last one should
> be kept, users
> that want to specify the scheduler, must specify everything
> (scheduler, periority, period).

So we have?

a = new Activity() // non-realtime, non-periodic
a = new Activity(priority) // realtime, non-periodic
a = new Activity(priority, period) // realtime, non-periodic or
periodic
a = new Activity(scheduler, priority) // realtime or non-realtime,
non-periodic
a = new Activity(scheduler, priority, period) // realtime or non-
realtime, periodic

Seems to have unnecessary duplication. Also, the last should assume
period==0 implies non-periodic, to match with 3rd?

Can the compiler coerce the 4th version into the 3rd?

a = new Activity(ORO_SCHED_RT, 3) // (int, int)
a = new Activity(ORO_SCHED_RT, 3.1) // (int, double) ** possibly not
what was intended?

What about simplifying to this:

a = new Activity() // non-realtime, non-periodic
a = new Activity(priority, period) // realtime, non-periodic or
periodic
a = new Activity(scheduler, priority, period) // realtime or non-
realtime, non-periodic or periodic

And period==0 implies non-periodic for both the last two.

One could also argue that priority==0 implies ORO_SCHED_OTHER,
reducing to

a = new Activity() // non-realtime, non-periodic
a = new Activity(priority, period) // realtime or non-realtime, non-
periodic or periodic

Stephen

About default activities for components

On Thu, Jun 11, 2009 at 17:17, S Roderick<kiwi [dot] net [..] ...> wrote:
>
> So we have?
>
> a = new Activity()                                                      //
> non-realtime, non-periodic
> a = new Activity(priority)                                      // realtime,
> non-periodic
> a = new Activity(priority, period)                      // realtime,
> non-periodic or periodic
> a = new Activity(scheduler, priority)                   // realtime or
> non-realtime, non-periodic
> a = new Activity(scheduler, priority, period)   // realtime or non-realtime,
> periodic
>
> Seems to have unnecessary duplication. Also, the last should assume
> period==0 implies non-periodic, to match with 3rd?
>
> Can the compiler coerce the 4th version into the 3rd?
>
> a = new Activity(ORO_SCHED_RT, 3)               // (int, int)
> a = new Activity(ORO_SCHED_RT, 3.1)             // (int, double) ** possibly
> not what was intended?

That could indeed be a nasty issue. Not good.

>
> What about simplifying to this:
>
> a = new Activity()                                                      //
> non-realtime, non-periodic
> a = new Activity(priority, period)                      // realtime,
> non-periodic or periodic
> a = new Activity(scheduler, priority, period)   // realtime or non-realtime,
> non-periodic or periodic
>
> And period==0 implies non-periodic for both the last two.

Fine for me too. Given these three constructors,
am I right that we could default argument period = 0.0 for the
second case (but not for the third) ?

>
> One could also argue that priority==0 implies ORO_SCHED_OTHER, reducing to

We can't interprete priorities, since they are passed directly to the RTOS. In
Linux 0 is lowest, in RTAI, 0 is highest. I have no idea yet what you
get on WIN32.

>
> a = new Activity()                                                      //
> non-realtime, non-periodic
> a = new Activity(priority, period)                      // realtime or
> non-realtime, non-periodic or periodic
>

Peter

About default activities for components

On Thu, Jun 11, 2009 at 05:52:23PM +0200, Peter Soetens wrote:
> On Thu, Jun 11, 2009 at 17:17, S Roderick<kiwi [dot] net [..] ...> wrote:

> > What about simplifying to this:
> >
> > a = new Activity()                                                      //
> > non-realtime, non-periodic
> > a = new Activity(priority, period)                      // realtime,
> > non-periodic or periodic
> > a = new Activity(scheduler, priority, period)   // realtime or non-realtime,
> > non-periodic or periodic
> >
> > And period==0 implies non-periodic for both the last two.
>
> Fine for me too. Given these three constructors,
> am I right that we could default argument period = 0.0 for the
> second case (but not for the third) ?

Or even drop the middle one? Why would one specify a priority without
a scheduler? If the priority matters, then so will the scheduler, no?

> We can't interprete priorities, since they are passed directly to the RTOS. In
> Linux 0 is lowest, in RTAI, 0 is highest. I have no idea yet what you
> get on WIN32.

Why don't you introduce rtt priorities? Of course there will not be a
clean mapping but it could be easily looked up in a conversion table
and would have the major advantage of beeing portable.

Markus

About default activities for components

On Fri, 12 Jun 2009, Markus Klotzbuecher wrote:

> On Thu, Jun 11, 2009 at 05:52:23PM +0200, Peter Soetens wrote:
>> On Thu, Jun 11, 2009 at 17:17, S Roderick<kiwi [dot] net [..] ...> wrote:
>
>>> What about simplifying to this:
>>>
>>> a = new Activity()                                                      //
>>> non-realtime, non-periodic
>>> a = new Activity(priority, period)                      // realtime,
>>> non-periodic or periodic
>>> a = new Activity(scheduler, priority, period)   // realtime or non-realtime,
>>> non-periodic or periodic
>>>
>>> And period==0 implies non-periodic for both the last two.
>>
>> Fine for me too. Given these three constructors,
>> am I right that we could default argument period = 0.0 for the
>> second case (but not for the third) ?
>
> Or even drop the middle one? Why would one specify a priority without
> a scheduler? If the priority matters, then so will the scheduler, no?

Since the Activity is responsible for (basically) the "Computation", and
periods, priorities and scheduling are "Coordination", I suggest to look
into the option of separating both. In other words, the arguments
"priority", "scheduler" and "period" belong to a "Coordination" object (we
used to call this the ExecutionEngine in old Orocos days...), and not to
the Activity itself. So, a "Coordination object" is created, and it could
then be configured to take some "Activities" as arguments for its own
"Computation", which would be a scheduler, an FSM, or some other
Coordination mechanism.

Does this make sense...?

>> We can't interprete priorities, since they are passed directly to the RTOS. In
>> Linux 0 is lowest, in RTAI, 0 is highest. I have no idea yet what you
>> get on WIN32.

> Why don't you introduce rtt priorities? Of course there will not be a
> clean mapping but it could be easily looked up in a conversion table
> and would have the major advantage of beeing portable.

This discussion is right to the point, and it fits with my comments above:
priorities and schedulers are too raw, low-level, OS-dependent Coordination
primitives to be visible directly in the RTT interface. In all, they are
"just" particular implementations of Coordination algorithms, and hence
they should not get a "first class" treatment with respect to others (the
FSM-based Coordination in the first place). Even on the contrary: if I have
learned one lesson from 20 years of realtime control then it is the fact
that priorities and static priority-based scheduling are not at all the
"best practice" to guarantee deterministic Coordination.

And the technical solution of lookup table is indeed just that: a
_technical_ one, which will keep on confusing developers for the rest of
RTT's life, because of their complete arbitrariness and variation over
platforms. So, if we can avoid them (in the RTT context at least), we
should!

Herman

About default activities for components

On Fri, Jun 12, 2009 at 09:13:52AM +0200, Herman Bruyninckx wrote:
> On Fri, 12 Jun 2009, Markus Klotzbuecher wrote:
>
>> On Thu, Jun 11, 2009 at 05:52:23PM +0200, Peter Soetens wrote:
>>> On Thu, Jun 11, 2009 at 17:17, S Roderick<kiwi [dot] net [..] ...> wrote:
>>
>>>> What about simplifying to this:
>>>>
>>>> a = new Activity()                                                      //
>>>> non-realtime, non-periodic
>>>> a = new Activity(priority, period)                      // realtime,
>>>> non-periodic or periodic
>>>> a = new Activity(scheduler, priority, period)   // realtime or non-realtime,
>>>> non-periodic or periodic
>>>>
>>>> And period==0 implies non-periodic for both the last two.
>>>
>>> Fine for me too. Given these three constructors,
>>> am I right that we could default argument period = 0.0 for the
>>> second case (but not for the third) ?
>>
>> Or even drop the middle one? Why would one specify a priority without
>> a scheduler? If the priority matters, then so will the scheduler, no?
>
> Since the Activity is responsible for (basically) the "Computation", and
> periods, priorities and scheduling are "Coordination", I suggest to look
> into the option of separating both. In other words, the arguments
> "priority", "scheduler" and "period" belong to a "Coordination" object (we
> used to call this the ExecutionEngine in old Orocos days...), and not to
> the Activity itself. So, a "Coordination object" is created, and it could
> then be configured to take some "Activities" as arguments for its own
> "Computation", which would be a scheduler, an FSM, or some other
> Coordination mechanism.
>
> Does this make sense...?

It makes a lot of sense! But wouldn't that be already achieved by
renaming the Activitiy to Coordination (and eventually adding the fsm
support)? Isn't the current Activity already the coordination? Or
asked differently, what is the role of an Activity once we have such a
coordination object?

>>> We can't interprete priorities, since they are passed directly to the RTOS. In
>>> Linux 0 is lowest, in RTAI, 0 is highest. I have no idea yet what you
>>> get on WIN32.
>
>> Why don't you introduce rtt priorities? Of course there will not be a
>> clean mapping but it could be easily looked up in a conversion table
>> and would have the major advantage of beeing portable.
>
> This discussion is right to the point, and it fits with my comments above:
> priorities and schedulers are too raw, low-level, OS-dependent Coordination
> primitives to be visible directly in the RTT interface. In all, they are
> "just" particular implementations of Coordination algorithms, and hence
> they should not get a "first class" treatment with respect to others (the
> FSM-based Coordination in the first place). Even on the contrary: if I have
> learned one lesson from 20 years of realtime control then it is the fact
> that priorities and static priority-based scheduling are not at all the
> "best practice" to guarantee deterministic Coordination.

Yes I agree, a system which depends strongly on priorities to achieve
its functional properties is in a fragile state already. Ideally we
would be able to derive priorities from the coordination
specification.

> And the technical solution of lookup table is indeed just that: a
> _technical_ one, which will keep on confusing developers for the rest of
> RTT's life, because of their complete arbitrariness and variation over
> platforms. So, if we can avoid them (in the RTT context at least), we
> should!

You're right that such a table would be confusing, but it would be
portable wrt deployment specifications. I fully agree that the best
solution is to make priorities just much less important - something
one would only touch for performance tuning in the very end...

Markusw

About default activities for components

On Fri, 12 Jun 2009, Markus Klotzbuecher wrote:

> On Fri, Jun 12, 2009 at 09:13:52AM +0200, Herman Bruyninckx wrote:
>> On Fri, 12 Jun 2009, Markus Klotzbuecher wrote:
>>
>>> On Thu, Jun 11, 2009 at 05:52:23PM +0200, Peter Soetens wrote:
>>>> On Thu, Jun 11, 2009 at 17:17, S Roderick<kiwi [dot] net [..] ...> wrote:
>>>
>>>>> What about simplifying to this:
>>>>>
>>>>> a = new Activity()                                                      //
>>>>> non-realtime, non-periodic
>>>>> a = new Activity(priority, period)                      // realtime,
>>>>> non-periodic or periodic
>>>>> a = new Activity(scheduler, priority, period)   // realtime or non-realtime,
>>>>> non-periodic or periodic
>>>>>
>>>>> And period==0 implies non-periodic for both the last two.
>>>>
>>>> Fine for me too. Given these three constructors,
>>>> am I right that we could default argument period = 0.0 for the
>>>> second case (but not for the third) ?
>>>
>>> Or even drop the middle one? Why would one specify a priority without
>>> a scheduler? If the priority matters, then so will the scheduler, no?
>>
>> Since the Activity is responsible for (basically) the "Computation", and
>> periods, priorities and scheduling are "Coordination", I suggest to look
>> into the option of separating both. In other words, the arguments
>> "priority", "scheduler" and "period" belong to a "Coordination" object (we
>> used to call this the ExecutionEngine in old Orocos days...), and not to
>> the Activity itself. So, a "Coordination object" is created, and it could
>> then be configured to take some "Activities" as arguments for its own
>> "Computation", which would be a scheduler, an FSM, or some other
>> Coordination mechanism.
>>
>> Does this make sense...?
>
> It makes a lot of sense! But wouldn't that be already achieved by
> renaming the Activitiy to Coordination (and eventually adding the fsm
> support)? Isn't the current Activity already the coordination? Or
> asked differently, what is the role of an Activity once we have such a
> coordination object?

Mmmm... Isn't the Activity implementing the "Computation" concept within
RTT? That is, the container for all the useful functionality that your
application is interested in? (And _without_ the "burden" of specifying
_how_ to schedule/coordinate that "Computation".)

>>>> We can't interprete priorities, since they are passed directly to the RTOS. In
>>>> Linux 0 is lowest, in RTAI, 0 is highest. I have no idea yet what you
>>>> get on WIN32.
>>
>>> Why don't you introduce rtt priorities? Of course there will not be a
>>> clean mapping but it could be easily looked up in a conversion table
>>> and would have the major advantage of beeing portable.
>>
>> This discussion is right to the point, and it fits with my comments above:
>> priorities and schedulers are too raw, low-level, OS-dependent Coordination
>> primitives to be visible directly in the RTT interface. In all, they are
>> "just" particular implementations of Coordination algorithms, and hence
>> they should not get a "first class" treatment with respect to others (the
>> FSM-based Coordination in the first place). Even on the contrary: if I have
>> learned one lesson from 20 years of realtime control then it is the fact
>> that priorities and static priority-based scheduling are not at all the
>> "best practice" to guarantee deterministic Coordination.
>
> Yes I agree, a system which depends strongly on priorities to achieve
> its functional properties is in a fragile state already. Ideally we
> would be able to derive priorities from the coordination
> specification.

"Ideally"????? That's not the ideal situation, but the worst thinkable one! :-)

>> And the technical solution of lookup table is indeed just that: a
>> _technical_ one, which will keep on confusing developers for the rest of
>> RTT's life, because of their complete arbitrariness and variation over
>> platforms. So, if we can avoid them (in the RTT context at least), we
>> should!
>
> You're right that such a table would be confusing, but it would be
> portable wrt deployment specifications.

That's just 'technical convenience', without any added semantic convenience
or added value! A FSM (or other) Coordination specification is at least
equally portable.

It's high time we get rid of the bad practices of 40 years of development
on nothing but the bare OS primitives... :-)

> I fully agree that the best
> solution is to make priorities just much less important - something
> one would only touch for performance tuning in the very end...

Yes. And "tuning" means "Configuration", which is to be done either in the
Deployer (= start-up time Configuration) or in the ExecutionEngine (=
runtime Configuration).

Herman

About default activities for components

On Fri, Jun 12, 2009 at 09:56:35AM +0200, Herman Bruyninckx wrote:
> On Fri, 12 Jun 2009, Markus Klotzbuecher wrote:

>> It makes a lot of sense! But wouldn't that be already achieved by
>> renaming the Activitiy to Coordination (and eventually adding the fsm
>> support)? Isn't the current Activity already the coordination? Or
>> asked differently, what is the role of an Activity once we have such a
>> coordination object?
>
> Mmmm... Isn't the Activity implementing the "Computation" concept within
> RTT? That is, the container for all the useful functionality that your
> application is interested in? (And _without_ the "burden" of specifying
> _how_ to schedule/coordinate that "Computation".)

Not really. Currently the computation is defined by the set of
implemented TaskContext methods. The Activity is attached to the
TaskContext and specifies how/when these methods are executed.

>>> This discussion is right to the point, and it fits with my comments above:
>>> priorities and schedulers are too raw, low-level, OS-dependent Coordination
>>> primitives to be visible directly in the RTT interface. In all, they are
>>> "just" particular implementations of Coordination algorithms, and hence
>>> they should not get a "first class" treatment with respect to others (the
>>> FSM-based Coordination in the first place). Even on the contrary: if I have
>>> learned one lesson from 20 years of realtime control then it is the fact
>>> that priorities and static priority-based scheduling are not at all the
>>> "best practice" to guarantee deterministic Coordination.
>>
>> Yes I agree, a system which depends strongly on priorities to achieve
>> its functional properties is in a fragile state already. Ideally we
>> would be able to derive priorities from the coordination
>> specification.
>
> "Ideally"????? That's not the ideal situation, but the worst thinkable one! :-)

:-) Huh? It would not be desireable to minimize the role of priorities
by deriving them from a more formal, declarative specification of
coordination?

>>> And the technical solution of lookup table is indeed just that: a
>>> _technical_ one, which will keep on confusing developers for the rest of
>>> RTT's life, because of their complete arbitrariness and variation over
>>> platforms. So, if we can avoid them (in the RTT context at least), we
>>> should!
>>
>> You're right that such a table would be confusing, but it would be
>> portable wrt deployment specifications.
>
> That's just 'technical convenience', without any added semantic convenience
> or added value! A FSM (or other) Coordination specification is at least
> equally portable.

True.

> It's high time we get rid of the bad practices of 40 years of development
> on nothing but the bare OS primitives... :-)

Ok!!! I'm all for it!

>> I fully agree that the best
>> solution is to make priorities just much less important - something
>> one would only touch for performance tuning in the very end...
>
> Yes. And "tuning" means "Configuration", which is to be done either in the
> Deployer (= start-up time Configuration) or in the ExecutionEngine (=
> runtime Configuration).

Agreed!

Markus

About default activities for components

On Fri, 12 Jun 2009, Markus Klotzbuecher wrote:

> On Fri, Jun 12, 2009 at 09:56:35AM +0200, Herman Bruyninckx wrote:
>> On Fri, 12 Jun 2009, Markus Klotzbuecher wrote:
>
>>> It makes a lot of sense! But wouldn't that be already achieved by
>>> renaming the Activitiy to Coordination (and eventually adding the fsm
>>> support)? Isn't the current Activity already the coordination? Or
>>> asked differently, what is the role of an Activity once we have such a
>>> coordination object?
>>
>> Mmmm... Isn't the Activity implementing the "Computation" concept within
>> RTT? That is, the container for all the useful functionality that your
>> application is interested in? (And _without_ the "burden" of specifying
>> _how_ to schedule/coordinate that "Computation".)
>
> Not really. Currently the computation is defined by the set of
> implemented TaskContext methods. The Activity is attached to the
> TaskContext and specifies how/when these methods are executed.

Okay... It seems time to update not only the implementation but also the
description of the real semantics of our RTT concepts :-)

>>>> This discussion is right to the point, and it fits with my comments above:
>>>> priorities and schedulers are too raw, low-level, OS-dependent Coordination
>>>> primitives to be visible directly in the RTT interface. In all, they are
>>>> "just" particular implementations of Coordination algorithms, and hence
>>>> they should not get a "first class" treatment with respect to others (the
>>>> FSM-based Coordination in the first place). Even on the contrary: if I have
>>>> learned one lesson from 20 years of realtime control then it is the fact
>>>> that priorities and static priority-based scheduling are not at all the
>>>> "best practice" to guarantee deterministic Coordination.
>>>
>>> Yes I agree, a system which depends strongly on priorities to achieve
>>> its functional properties is in a fragile state already. Ideally we
>>> would be able to derive priorities from the coordination
>>> specification.
>>
>> "Ideally"????? That's not the ideal situation, but the worst thinkable one! :-)
>
> :-) Huh? It would not be desireable to minimize the role of priorities
> by deriving them from a more formal, declarative specification of
> coordination?

Depends on what exactly this nice phrase of you means... :-)

>>>> And the technical solution of lookup table is indeed just that: a
>>>> _technical_ one, which will keep on confusing developers for the rest of
>>>> RTT's life, because of their complete arbitrariness and variation over
>>>> platforms. So, if we can avoid them (in the RTT context at least), we
>>>> should!

>>> You're right that such a table would be confusing, but it would be
>>> portable wrt deployment specifications.

>> That's just 'technical convenience', without any added semantic convenience
>> or added value! A FSM (or other) Coordination specification is at least
>> equally portable.
>
> True.
>
>> It's high time we get rid of the bad practices of 40 years of development
>> on nothing but the bare OS primitives... :-)
>
> Ok!!! I'm all for it!
>
>>> I fully agree that the best
>>> solution is to make priorities just much less important - something
>>> one would only touch for performance tuning in the very end...
>>
>> Yes. And "tuning" means "Configuration", which is to be done either in the
>> Deployer (= start-up time Configuration) or in the ExecutionEngine (=
>> runtime Configuration).
>
> Agreed!

If you agree on the latter part (the runtime Configuration in the
ExecutionEngine) you implicitly agree on not using OS-level priorities as
an RTT concept, because they should, as such, not be visible at runtime.

> Markus

Herman

About default activities for components

On Fri, Jun 12, 2009 at 10:21, Herman
Bruyninckx<Herman [dot] Bruyninckx [..] ...> wrote:
>
> If you agree on the latter part (the runtime Configuration in the
> ExecutionEngine) you implicitly agree on not using OS-level priorities as
> an RTT concept, because they should, as such, not be visible at runtime.

The reality is however that we're not writing an operating system and
that as such, we can not define how threads are to be created. All
OS's we have ported RTT to, require that you specify a scheduler and a
priority of the to be created thread. If you don't specify it, you
don't get your thread. There are defaults however, which is exactly
what we were proposing too. If you want an Activity (=Coordination by
OS scheduler, based on priorities) to execute a taskcontext
(=Computation), you have these options:

Activity() // default to not real-time, lowest priority, not periodic,
ie the default of all OS's which provide one when a thread is created.
Activity(priority, period) // oops, user cares about priority, lets
make it real-time
Activity(scheduler, priority, period) // the holy trinity with stack
being a process wide setting

Any of these parameters can be changed after creation.

Which brings me to your remark about 'implicit' choices. The choice is
not implicit if you say that it's the default. For example, a POSIX
mutex is 'implicitly' not recursive, ie created by default with not
recursive locks, which you can override with setting the attr struct
(~ Activity constructor arguments).

Peter

About default activities for components

> The reality is however that we're not writing an operating system and
> that as such, we can not define how threads are to be created. All
> OS's we have ported RTT to, require that you specify a scheduler and a
My OS has only one scheduler, so the ORO_SHED_XXX defines are useless to
me. Btw, I never understood why they where dragged into the Activity
interface in the first place.

> priority of the to be created thread. If you don't specify it, you
> don't get your thread. There are defaults however, which is exactly
> what we were proposing too. If you want an Activity (=Coordination by
> OS scheduler, based on priorities) to execute a taskcontext
> (=Computation), you have these options:
>
> Activity() // default to not real-time, lowest priority, not periodic,
> ie the default of all OS's which provide one when a thread is created.
> Activity(priority, period) // oops, user cares about priority, lets
> make it real-time
> Activity(scheduler, priority, period) // the holy trinity with stack
> being a process wide setting
>
> Any of these parameters can be changed after creation.
>
Nope, not in our case. A task's priority can not be changed once
created... Maybe the period can.

> Which brings me to your remark about 'implicit' choices. The choice is
> not implicit if you say that it's the default. For example, a POSIX
> mutex is 'implicitly' not recursive, ie created by default with not
> recursive locks, which you can override with setting the attr struct
> (~ Activity constructor arguments).
>
Sander.

About default activities for components

On Fri, Jun 12, 2009 at 13:24, Vandenbroucke
Sander<Sander [dot] Vandenbroucke [..] ...> wrote:
>
>> The reality is however that we're not writing an operating system and
>> that as such, we can not define how threads are to be created. All
>> OS's we have ported RTT to, require that you specify a scheduler and a
> My OS has only one scheduler, so the ORO_SHED_XXX defines are useless to
> me. Btw, I never understood why they where dragged into the Activity
> interface in the first place.

Because having different scheduling policies is a reality on most
operating systems.

>
>> priority of the to be created thread. If you don't specify it, you
>> don't get your thread. There are defaults however, which is exactly
>> what we were proposing too. If you want an Activity (=Coordination by
>> OS scheduler, based on priorities) to execute a taskcontext
>> (=Computation), you have these options:
>>
>> Activity() // default to not real-time, lowest priority, not periodic,
>> ie the default of all OS's which provide one when a thread is created.
>> Activity(priority, period) // oops, user cares about priority, lets
>> make it real-time
>> Activity(scheduler, priority, period) //  the holy trinity with stack
>> being a process wide setting
>>
>> Any of these parameters can be changed after creation.
>>
> Nope, not in our case. A task's priority can not be changed once
> created... Maybe the period can.

That's the job of the FOSI to translate that constraint. In your case,
rtos_task_set_priority( arg) will always return false.

Peter

About default activities for components

On Fri, 12 Jun 2009, Peter Soetens wrote:

> On Fri, Jun 12, 2009 at 13:24, Vandenbroucke
> Sander<Sander [dot] Vandenbroucke [..] ...> wrote:
>>
>>> The reality is however that we're not writing an operating system and
>>> that as such, we can not define how threads are to be created. All
>>> OS's we have ported RTT to, require that you specify a scheduler and a
>> My OS has only one scheduler, so the ORO_SHED_XXX defines are useless to
>> me. Btw, I never understood why they where dragged into the Activity
>> interface in the first place.
>
> Because having different scheduling policies is a reality on most
> operating systems.

It is a reality indeed, but it is not a property of the 'execution
container' which is the Activity!

This coupling of the execution container with the execution scheduler has
been introduced early on in the life of Orocos, when we were not
sufficiently aware of the consequences. I think it's time to change this
coupling. Also the naming of the Activities (IRQActivity, SlaveActivity,
...) reflects this coupling: nothing in the _inside_ of an Activity should
reflect this type of an activity, that is, if a computation inside an
Activity has to know about it, it should do so by reading a _property_ of the
Activity container. For example, a control law that runs inside of a
"classical" "PeriodicActivity" should only know about the period of
execution via a corresponding property (and its code should not rely on any
particular value!), such that an external Coordinator can change this value
when needed.

Herman

>>> priority of the to be created thread. If you don't specify it, you
>>> don't get your thread. There are defaults however, which is exactly
>>> what we were proposing too. If you want an Activity (=Coordination by
>>> OS scheduler, based on priorities) to execute a taskcontext
>>> (=Computation), you have these options:
>>>
>>> Activity() // default to not real-time, lowest priority, not periodic,
>>> ie the default of all OS's which provide one when a thread is created.
>>> Activity(priority, period) // oops, user cares about priority, lets
>>> make it real-time
>>> Activity(scheduler, priority, period) //  the holy trinity with stack
>>> being a process wide setting
>>>
>>> Any of these parameters can be changed after creation.
>>>
>> Nope, not in our case. A task's priority can not be changed once
>> created... Maybe the period can.
>
> That's the job of the FOSI to translate that constraint. In your case,
> rtos_task_set_priority( arg) will always return false.
>
> Peter

About default activities for components

> >
> > Because having different scheduling policies is a reality on most
> > operating systems.
>
> It is a reality indeed, but it is not a property of the 'execution
> container' which is the Activity!
>
> This coupling of the execution container with the execution scheduler
has
> been introduced early on in the life of Orocos, when we were not
> sufficiently aware of the consequences. I think it's time to change
this
> coupling. Also the naming of the Activities (IRQActivity,
SlaveActivity,
> ...) reflects this coupling: nothing in the _inside_ of an Activity
should
> reflect this type of an activity, that is, if a computation inside an
> Activity has to know about it, it should do so by reading a _property_
of
> the
> Activity container. For example, a control law that runs inside of a
> "classical" "PeriodicActivity" should only know about the period of
> execution via a corresponding property (and its code should not rely
on
> any
> particular value!), such that an external Coordinator can change this
> value
> when needed.
>
This example clearly shows that the components internal computation
implies a periodic invocation. So it is hard to define a default
activity from the framework's POV, isn't it? Because in most cases the
decision what activity to use depends on the component's internal
computation and the context in which a controller is used in. I really
don't think that choosing a default activity is the responsibility of
the framework.

Sander.

About default activities for components

On Fri, 12 Jun 2009, Peter Soetens wrote:

> On Fri, Jun 12, 2009 at 10:21, Herman
> Bruyninckx<Herman [dot] Bruyninckx [..] ...> wrote:
>>
>> If you agree on the latter part (the runtime Configuration in the
>> ExecutionEngine) you implicitly agree on not using OS-level priorities as
>> an RTT concept, because they should, as such, not be visible at runtime.
>
> The reality is however that we're not writing an operating system and
> that as such, we can not define how threads are to be created. All
> OS's we have ported RTT to, require that you specify a scheduler and a
> priority of the to be created thread.

That is only true under the assumption that "Activity == Thread" and that
is the assumption that I want to discuss, at this moment of "2.0
preparation". In more concrete terms, are we sure that we will never want
to 'schedule' (= 'coordinate' the execution of) our activities in another
way then via priorities and a priority-based scheduler? The whole concept
of "models of computation" comes to my mind in this context...

> If you don't specify it, you
> don't get your thread. There are defaults however, which is exactly
> what we were proposing too. If you want an Activity (=Coordination by
> OS scheduler, based on priorities) to execute a taskcontext
> (=Computation), you have these options:
>
> Activity() // default to not real-time, lowest priority, not periodic,
> ie the default of all OS's which provide one when a thread is created.
> Activity(priority, period) // oops, user cares about priority, lets
> make it real-time
> Activity(scheduler, priority, period) // the holy trinity with stack
> being a process wide setting
>
> Any of these parameters can be changed after creation.
>
> Which brings me to your remark about 'implicit' choices. The choice is
> not implicit if you say that it's the default.

That's engineering nonsense! :-)

> For example, a POSIX
> mutex is 'implicitly' not recursive, ie created by default with not
> recursive locks, which you can override with setting the attr struct
> (~ Activity constructor arguments).

Recursivity is an _additional_ property of the semantic concept of a mutex,
so talking about "defaults" is not appropriate in this context :-)

Herman

About default activities for components

On Fri, Jun 12, 2009 at 11:32, Herman
Bruyninckx<Herman [dot] Bruyninckx [..] ...> wrote:
> On Fri, 12 Jun 2009, Peter Soetens wrote:
>
>> On Fri, Jun 12, 2009 at 10:21, Herman
>> Bruyninckx<Herman [dot] Bruyninckx [..] ...> wrote:
>>>
>>> If you agree on the latter part (the runtime Configuration in the
>>> ExecutionEngine) you implicitly agree on not using OS-level priorities as
>>> an RTT concept, because they should, as such, not be visible at runtime.
>>
>> The reality is however that we're not writing an operating system and
>> that as such, we can not define how threads are to be created. All
>> OS's we have ported RTT to, require that you specify a scheduler and a
>> priority of the to be created thread.
>
> That is only true under the assumption that "Activity == Thread" and that
> is the assumption that I want to discuss, at this moment of "2.0
> preparation". In more concrete terms, are we sure that we will never want
> to 'schedule' (= 'coordinate' the execution of) our activities in another
> way then via priorities and a priority-based scheduler? The whole concept
> of "models of computation" comes to my mind in this context...

There are already many kinds of activities: SlaveActivity,
SequentialActivity, IRQActivity, FileActivity, etc. The new one,
'Activity', is only meant to merge PeriodicActivity and
NonPeriodicActivity, which were subject of many discussions before.
They all implement 'ActivityInterface', some of them use a thread to
do the work, some of them don't. So this is not a discussion about the
'general' activity, only about a very specific implementation of it,
which will be our default if the user doesn't specify an alternative.

Peter

About default activities for components

On Fri, 12 Jun 2009, Peter Soetens wrote:

> On Fri, Jun 12, 2009 at 11:32, Herman
> Bruyninckx<Herman [dot] Bruyninckx [..] ...> wrote:
>> On Fri, 12 Jun 2009, Peter Soetens wrote:
>>
>>> On Fri, Jun 12, 2009 at 10:21, Herman
>>> Bruyninckx<Herman [dot] Bruyninckx [..] ...> wrote:
>>>>
>>>> If you agree on the latter part (the runtime Configuration in the
>>>> ExecutionEngine) you implicitly agree on not using OS-level priorities as
>>>> an RTT concept, because they should, as such, not be visible at runtime.
>>>
>>> The reality is however that we're not writing an operating system and
>>> that as such, we can not define how threads are to be created. All
>>> OS's we have ported RTT to, require that you specify a scheduler and a
>>> priority of the to be created thread.
>>
>> That is only true under the assumption that "Activity == Thread" and that
>> is the assumption that I want to discuss, at this moment of "2.0
>> preparation". In more concrete terms, are we sure that we will never want
>> to 'schedule' (= 'coordinate' the execution of) our activities in another
>> way then via priorities and a priority-based scheduler? The whole concept
>> of "models of computation" comes to my mind in this context...
>
> There are already many kinds of activities: SlaveActivity,
> SequentialActivity, IRQActivity, FileActivity, etc.

Indeed, and that's what I am referring to: these activities do not
rely on a scheduler or prirorities.

> The new one, 'Activity', is only meant to merge PeriodicActivity and
> NonPeriodicActivity, which were subject of many discussions before.

I understand this, but that is not a reason to narrow down the merging to
only scheduler/priority-based properties, I think. So, a better name would
be "ScheduledActivity", instead of using 'scheduling' as a 'default'
semantic meaning.

> They all implement 'ActivityInterface', some of them use a thread to
> do the work, some of them don't. So this is not a discussion about the
> 'general' activity, only about a very specific implementation of it,
> which will be our default if the user doesn't specify an alternative.

Again, such implicit defaults without clear semantic backing cause too many
confusions...

Herman

About default activities for components

On Friday 12 June 2009 11:53:04 Herman Bruyninckx wrote:
> On Fri, 12 Jun 2009, Peter Soetens wrote:
> > On Fri, Jun 12, 2009 at 11:32, Herman
> >
> > Bruyninckx<Herman [dot] Bruyninckx [..] ...> wrote:
> >> On Fri, 12 Jun 2009, Peter Soetens wrote:
> >>> On Fri, Jun 12, 2009 at 10:21, Herman
> >>>
> >>> Bruyninckx<Herman [dot] Bruyninckx [..] ...> wrote:
> >>>> If you agree on the latter part (the runtime Configuration in the
> >>>> ExecutionEngine) you implicitly agree on not using OS-level priorities
> >>>> as an RTT concept, because they should, as such, not be visible at
> >>>> runtime.
> >>>
> >>> The reality is however that we're not writing an operating system and
> >>> that as such, we can not define how threads are to be created. All
> >>> OS's we have ported RTT to, require that you specify a scheduler and a
> >>> priority of the to be created thread.
> >>
> >> That is only true under the assumption that "Activity == Thread" and
> >> that is the assumption that I want to discuss, at this moment of "2.0
> >> preparation". In more concrete terms, are we sure that we will never
> >> want to 'schedule' (= 'coordinate' the execution of) our activities in
> >> another way then via priorities and a priority-based scheduler? The
> >> whole concept of "models of computation" comes to my mind in this
> >> context...
> >
> > There are already many kinds of activities: SlaveActivity,
> > SequentialActivity, IRQActivity, FileActivity, etc.
>
> Indeed, and that's what I am referring to: these activities do not
> rely on a scheduler or prirorities.
Some of them do.

I agree that the ideal level is to have a coordination model (which does not
have to be represented in the framework !) from which are derived the actual
parameters. Peter is right: threads *have* a priority/scheduler assigned to
them, and these values are a valuable tool in the low-level toolkit of the
coordination mechanism. Right now, these mechanisms are:
- period
- port-triggering
- explicit triggering with step()
- using different kinds of triggers through the FileActivity/IRQActivity/...

The point being: you have to cope with the fact that your threads are running
under the supervision of the OS scheduler, and therefore the Coordination
mechanism you are using has to tell that scheduler how it should handle the
threads so that the system's coordination works as expected.

About default activities for components

On Fri, 12 Jun 2009, Sylvain Joyeux wrote:

> On Friday 12 June 2009 11:53:04 Herman Bruyninckx wrote:
>> On Fri, 12 Jun 2009, Peter Soetens wrote:
>>> On Fri, Jun 12, 2009 at 11:32, Herman
>>>
>>> Bruyninckx<Herman [dot] Bruyninckx [..] ...> wrote:
>>>> On Fri, 12 Jun 2009, Peter Soetens wrote:
>>>>> On Fri, Jun 12, 2009 at 10:21, Herman
>>>>>
>>>>> Bruyninckx<Herman [dot] Bruyninckx [..] ...> wrote:
>>>>>> If you agree on the latter part (the runtime Configuration in the
>>>>>> ExecutionEngine) you implicitly agree on not using OS-level priorities
>>>>>> as an RTT concept, because they should, as such, not be visible at
>>>>>> runtime.
>>>>>
>>>>> The reality is however that we're not writing an operating system and
>>>>> that as such, we can not define how threads are to be created. All
>>>>> OS's we have ported RTT to, require that you specify a scheduler and a
>>>>> priority of the to be created thread.
>>>>
>>>> That is only true under the assumption that "Activity == Thread" and
>>>> that is the assumption that I want to discuss, at this moment of "2.0
>>>> preparation". In more concrete terms, are we sure that we will never
>>>> want to 'schedule' (= 'coordinate' the execution of) our activities in
>>>> another way then via priorities and a priority-based scheduler? The
>>>> whole concept of "models of computation" comes to my mind in this
>>>> context...
>>>
>>> There are already many kinds of activities: SlaveActivity,
>>> SequentialActivity, IRQActivity, FileActivity, etc.
>>
>> Indeed, and that's what I am referring to: these activities do not
>> rely on a scheduler or prirorities.
> Some of them do.

yes, in the sense that, in the traditional OS-centric view of coordination,
some of these activities are becoming active through actions from the
scheduler. But that is an "implementation detail", not a semantic property
of the activities! And I am sensitive to keeping semantics and
implementations as separate as possible (without sacrificing runtime
efficiency).

> I agree that the ideal level is to have a coordination model (which does not
> have to be represented in the framework !) from which are derived the actual
> parameters. Peter is right: threads *have* a priority/scheduler assigned to
> them, and these values are a valuable tool in the low-level toolkit of the
> coordination mechanism.

Yes, but only there! So, probably this long thread is caused by the
semantic confusion of what an Activity is/should be within RTT: (i) a
faithful but minimal OS-agnostic generalisation of the thread concept, or
(ii) a new concept in its own right, without any legacy of the OS
terminology, semantics and practices. I would argue for (ii), but that
would maybe just shift the discussion to that of defining where (i) is to
be given a place within Orocos, because in most cases (i) _has_ to be there
somewhere...

> Right now, these mechanisms are:
> - period
> - port-triggering
> - explicit triggering with step()
> - using different kinds of triggers through the FileActivity/IRQActivity/...
Yes, and none has only OS-centric semantics, but semantics that have their
right place in a "higher level" framework, i.e., a level where 'scheduler'
and 'priority' are undefined concepts.

> The point being: you have to cope with the fact that your threads are running
> under the supervision of the OS scheduler, and therefore the Coordination
> mechanism you are using has to tell that scheduler how it should handle the
> threads so that the system's coordination works as expected.

Yes, the "FOSI Coordination" support has. But not the "RTT Coordination"
support. Maybe this implies that we need (at least) two kinds of
Coordination support...? (Just as we have at least three kinds of
Configuration support (compile/link time, deploy time, run time).)

Herman

About default activities for components

As a side note, I actually prefer keeping the current design, in which the
(very rich) ways to control coordination are provided *on the objects that
provide them*, thus forming a "low-level toolkit for coordination"

I like that because
- you can also have a Coordination class in which these parameters are
gathered and then propagated both at deployment and runtime

BUT
- someone (like me) can have a complete different way to think the whole
coordination problem and will not have to use this Coordination class.

About default activities for components

On Thu, Jun 11, 2009 at 02:58:50PM +0200, Sylvain Joyeux wrote:
> > Any comments on these defaults ?
> They seem reasonable to me. If someone actually *knows* about what a priority
> is, then he probably will be able to find out how to change it ...

Yes, I agree that assigning a non rt priority is a good default!

Markus