Changeset 87b4d03 in rtems-docs


Ignore:
Timestamp:
02/03/17 10:52:51 (7 years ago)
Author:
Sebastian Huber <sebastian.huber@…>
Branches:
5, master
Children:
90a3c41
Parents:
785c02f
Message:

c-user: Update scheduler helping protocol

File:
1 edited

Legend:

Unmodified
Added
Removed
  • c-user/symmetric_multiprocessing_services.rst

    r785c02f r87b4d03  
    204204<rtems_task_set_scheduler>`.
    205205
    206 Scheduler Helping Protocol
    207 --------------------------
    208 
    209 The scheduler provides a helping protocol to support locking protocols like
    210 *Migratory Priority Inheritance* or the *Multiprocessor Resource Sharing
    211 Protocol*.  Each ready task can use at least one scheduler node at a time to
    212 gain access to a processor.  Each scheduler node has an owner, a user and an
    213 optional idle task.  The owner of a scheduler node is determined a task
    214 creation and never changes during the life time of a scheduler node.  The user
    215 of a scheduler node may change due to the scheduler helping protocol.  A
    216 scheduler node is in one of the four scheduler help states:
    217 
    218 :dfn:`help yourself`
    219     This scheduler node is solely used by the owner task.  This task owns no
    220     resources using a helping protocol and thus does not take part in the
    221     scheduler helping protocol.  No help will be provided for other tasks.
    222 
    223 :dfn:`help active owner`
    224     This scheduler node is owned by a task actively owning a resource and can
    225     be used to help out tasks.  In case this scheduler node changes its state
    226     from ready to scheduled and the task executes using another node, then an
    227     idle task will be provided as a user of this node to temporarily execute on
    228     behalf of the owner task.  Thus lower priority tasks are denied access to
    229     the processors of this scheduler instance.  In case a task actively owning
    230     a resource performs a blocking operation, then an idle task will be used
    231     also in case this node is in the scheduled state.
    232 
    233 :dfn:`help active rival`
    234     This scheduler node is owned by a task actively obtaining a resource
    235     currently owned by another task and can be used to help out tasks.  The
    236     task owning this node is ready and will give away its processor in case the
    237     task owning the resource asks for help.
    238 
    239 :dfn:`help passive`
    240     This scheduler node is owned by a task obtaining a resource currently owned
    241     by another task and can be used to help out tasks.  The task owning this
    242     node is blocked.
    243 
    244 The following scheduler operations return a task in need for help
    245 
    246 - unblock,
    247 
    248 - change priority,
    249 
    250 - yield, and
    251 
    252 - ask for help.
    253 
    254 A task in need for help is a task that encounters a scheduler state change from
    255 scheduled to ready (this is a pre-emption by a higher priority task) or a task
    256 that cannot be scheduled in an unblock operation.  Such a task can ask tasks
    257 which depend on resources owned by this task for help.
    258 
    259 In case it is not possible to schedule a task in need for help, then the
    260 scheduler nodes available for the task will be placed into the set of ready
    261 scheduler nodes of the corresponding scheduler instances.  Once a state change
    262 from ready to scheduled happens for one of scheduler nodes it will be used to
    263 schedule the task in need for help.
    264 
    265 The ask for help scheduler operation is used to help tasks in need for help
    266 returned by the operations mentioned above.  This operation is also used in
    267 case the root of a resource sub-tree owned by a task changes.
    268 
    269 The run-time of the ask for help procedures depend on the size of the resource
    270 tree of the task needing help and other resource trees in case tasks in need
    271 for help are produced during this operation.  Thus the worst-case latency in
    272 the system depends on the maximum resource tree size of the application.
    273 
    274206OpenMP
    275207------
     
    637569   :align: center
    638570
     571Scheduler Helping Protocol
     572--------------------------
     573
     574The scheduler provides a helping protocol to support locking protocols like the
     575:ref:`OMIP` or the :ref:`MrsP`.  Each thread has a scheduler node for each
     576scheduler instance in the system which are located in its :term:`TCB`.  A
     577thread has exactly one home scheduler instance which is set during thread
     578creation.  The home scheduler instance can be changed with
     579:ref:`rtems_task_set_scheduler() <rtems_task_set_scheduler>`.  Due to the
     580locking protocols a thread may gain access to scheduler nodes of other
     581scheduler instances.  This allows the thread to temporarily migrate to another
     582scheduler instance in case of pre-emption.
     583
     584The scheduler infrastructure is based on an object-oriented design.  The
     585scheduler operations for a thread are defined as virtual functions.  For the
     586scheduler helping protocol the following operations must be implemented by an
     587SMP-aware scheduler
     588
     589* ask a scheduler node for help,
     590* reconsider the help request of a scheduler node,
     591* withdraw a schedule node.
     592
     593All currently available SMP-aware schedulers use a framework which is
     594customized via inline functions.  This eases the implementation of scheduler
     595variants.  Up to now, only priority-based schedulers are implemented.
     596
     597In case a thread is allowed to use more than one scheduler node it will ask
     598these nodes for help
     599
     600* in case of pre-emption, or
     601* an unblock did not schedule the thread, or
     602* a yield  was successful.
     603
     604The actual ask for help scheduler operations are carried out as a side-effect
     605of the thread dispatch procedure.  Once a need for help is recognized, a help
     606request is registered in one of the processors related to the thread and a
     607thread dispatch is issued.  This indirection leads to a better decoupling of
     608scheduler instances.  Unrelated processors are not burdened with extra work for
     609threads which participate in resource sharing.  Each ask for help operation
     610indicates if it could help or not.  The procedure stops after the first
     611successful ask for help.  Unsuccessful ask for help operations will register
     612this need in the scheduler context.
     613
     614After a thread dispatch the reconsider help request operation is used to clean
     615up stale help registrations in the scheduler contexts.
     616
     617The withdraw operation takes away scheduler nodes once the thread is no longer
     618allowed to use them, e.g. it released a mutex.  The availability of scheduler
     619nodes for a thread is controlled by the thread queues.
     620
    639621Thread Dispatch Details
    640622-----------------------
Note: See TracChangeset for help on using the changeset viewer.