On 7/8/2014 10:05 AM, Sebastian Huber wrote:
I reviewed the code and didn't spot anything obvious.
Does the Doxygen have any warnings or do we need to wait
to see the automated build?
I am sure once the SMP dust settles, we will have to work
on coverage with SMP enabled.
> diff --git a/doc/user/smp.t b/doc/user/smp.t
> index dd84c37..239a544 100644
> --- a/doc/user/smp.t
> +++ b/doc/user/smp.t
> @@ -147,6 +147,79 @@ another processor. So if we enable interrupts during
> this transition we have
> to provide an alternative task independent stack for this time frame. This
> issue needs further investigation.
>
> +@subsection Scheduler Helping Protocol
> +
> +The scheduler provides a helping protocol to support locking protocols like
> +@cite{Migratory Priority Inheritance} or the @cite{Multiprocessor Resource
> +Sharing Protocol}. Each ready task can use at least one scheduler node at a
> +time to gain access to a processor. Each scheduler node has an owner, a user
> +and an optional idle task. The owner of a scheduler node is determined a
> task
a -> at
> +creation and never changes during the life time of a scheduler node. The
> user
> +of a scheduler node may change due to the scheduler helping protocol. A
> +scheduler node is in one of the four scheduler help states:
> +
> +@table @dfn
> +
> +@item help yourself
> +
> +This scheduler node is solely used by the owner task. This task owns no
> +resources using a helping protocol and thus does not take part in the
> scheduler
> +helping protocol. No help will be provided for other tasks.
> +
> +@item help active owner
> +
> +This scheduler node is owned by a task actively owning a resource and can be
> +used to help out tasks.
> +
> +In case this scheduler node changes its state from ready to scheduled and the
> +task executes using another node, then an idle task will be provided as a
> user
> +of this node to temporarily execute on behalf of the owner task. Thus lower
> +priority tasks are denied access to the processors of this scheduler
> instance.
> +
> +In case a task actively owning a resource performs a blocking operation, then
> +an idle task will be used also in case this node is in the scheduled state.
> +
> +@item help active rival
> +
> +This scheduler node is owned by a task actively obtaining a resource
> currently
> +owned by another task and can be used to help out tasks.
help out other(?) tasks which...?
> +The task owning this node is ready and will give away its processor in case
> the
> +task owning the resource asks for help.
> +
> +@item help passive
> +
> +This scheduler node is owned by a task obtaining a resource currently owned
> by
> +another task and can be used to help out tasks.
> +
> +The task owning this node is blocked.
> +
> +@end table
> +
> +The following scheduler operations return a task in need for help
> +
> +@itemize @bullet
> +@item unblock,
> +@item change priority,
> +@item yield, and
> +@item ask for help.
> +@end itemize
> +
> +A task in need for help is a task that encounters a scheduler state change
> from
> +scheduled to ready or a task that cannot be scheduled in an unblock
> operation.
> +Such a task can ask tasks which depend on resources owned by this task for
> +help.
> +
> +In case it is not possible to schedule a task in need for help, then
> +the corresponding scheduler node will be placed into the set of ready
> +scheduler nodes of the scheduler instance. Once a state change from
> +ready to scheduled happens for this scheduler node it may be used to
> +schedule the task in need for help.
> +
> +The ask for help scheduler operation is used to help tasks in need for help
May want to use @code{ask for help} where appropriate to clearly
indicate a method.
> +returned by the operations mentioned above. This operation is also used in
> +case the root of a resource sub-tree owned by a task changes.
> +
> @subsection Critical Section Techniques and SMP
>
> As discussed earlier, SMP systems have opportunities for true parallelism
> --
> 1.7.7
>
> _______________________________________________
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
