Changeset 5c3d250 in rtems for doc


Ignore:
Timestamp:
07/04/14 12:34:23 (10 years ago)
Author:
Sebastian Huber <sebastian.huber@…>
Branches:
4.11, 5, master
Children:
9f228bea
Parents:
52f8e90d
git-author:
Sebastian Huber <sebastian.huber@…> (07/04/14 12:34:23)
git-committer:
Sebastian Huber <sebastian.huber@…> (07/09/14 08:05:17)
Message:

score: Implement scheduler helping protocol

The following scheduler operations return a thread in need for help

  • unblock,
  • change priority, and
  • yield.

A thread in need for help is a thread that encounters a scheduler state
change from scheduled to ready or a thread that cannot be scheduled in
an unblock operation. Such a thread can ask threads which depend on
resources owned by this thread for help.

Add a new ask for help scheduler operation. This operation is used by
_Scheduler_Ask_for_help() to help threads in need for help returned by
the operations mentioned above. This operation is also used by
_Scheduler_Thread_change_resource_root() in case the root of a resource
sub-tree changes. A use case is the ownership change of a resource.

In case it is not possible to schedule a thread 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 thread in need for help.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/user/smp.t

    r52f8e90d r5c3d250  
    148148issue needs further investigation.
    149149
     150@subsection Scheduler Helping Protocol
     151
     152The scheduler provides a helping protocol to support locking protocols like
     153@cite{Migratory Priority Inheritance} or the @cite{Multiprocessor Resource
     154Sharing Protocol}.  Each ready task can use at least one scheduler node at a
     155time to gain access to a processor.  Each scheduler node has an owner, a user
     156and an optional idle task.  The owner of a scheduler node is determined a task
     157creation and never changes during the life time of a scheduler node.  The user
     158of a scheduler node may change due to the scheduler helping protocol.  A
     159scheduler node is in one of the four scheduler help states:
     160
     161@table @dfn
     162
     163@item help yourself
     164
     165This scheduler node is solely used by the owner task.  This task owns no
     166resources using a helping protocol and thus does not take part in the scheduler
     167helping protocol.  No help will be provided for other tasks.
     168
     169@item help active owner
     170
     171This scheduler node is owned by a task actively owning a resource and can be
     172used to help out tasks.
     173
     174In case this scheduler node changes its state from ready to scheduled and the
     175task executes using another node, then an idle task will be provided as a user
     176of this node to temporarily execute on behalf of the owner task.  Thus lower
     177priority tasks are denied access to the processors of this scheduler instance.
     178
     179In case a task actively owning a resource performs a blocking operation, then
     180an idle task will be used also in case this node is in the scheduled state.
     181
     182@item help active rival
     183
     184This scheduler node is owned by a task actively obtaining a resource currently
     185owned by another task and can be used to help out tasks.
     186
     187The task owning this node is ready and will give away its processor in case the
     188task owning the resource asks for help.
     189
     190@item help passive
     191
     192This scheduler node is owned by a task obtaining a resource currently owned by
     193another task and can be used to help out tasks.
     194
     195The task owning this node is blocked.
     196
     197@end table
     198
     199The following scheduler operations return a task in need for help
     200
     201@itemize @bullet
     202@item unblock,
     203@item change priority,
     204@item yield, and
     205@item ask for help.
     206@end itemize
     207
     208A task in need for help is a task that encounters a scheduler state change from
     209scheduled to ready (this is a pre-emption by a higher priority task) or a task
     210that cannot be scheduled in an unblock operation.  Such a task can ask tasks
     211which depend on resources owned by this task for help.
     212
     213In case it is not possible to schedule a task in need for help, then the
     214scheduler nodes available for the task will be placed into the set of ready
     215scheduler nodes of the corresponding scheduler instances.  Once a state change
     216from ready to scheduled happens for one of scheduler nodes it will be used to
     217schedule the task in need for help.
     218
     219The ask for help scheduler operation is used to help tasks in need for help
     220returned by the operations mentioned above.  This operation is also used in
     221case the root of a resource sub-tree owned by a task changes.
     222
     223The run-time of the ask for help procedures depend on the size of the resource
     224tree of the task needing help and other resource trees in case tasks in need
     225for help are produced during this operation.  Thus the worst-case latency in
     226the system depends on the maximum resource tree size of the application.
     227
    150228@subsection Critical Section Techniques and SMP
    151229
Note: See TracChangeset for help on using the changeset viewer.