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

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

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

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:

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

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

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