Changeset 87b4d03 in rtems-docs

02/03/17 10:52:51 (7 years ago)
Sebastian Huber <sebastian.huber@…>
5, master

c-user: Update scheduler helping protocol

1 edited


  • c-user/symmetric_multiprocessing_services.rst

    r785c02f r87b4d03  
    206 Scheduler Helping Protocol
    207 --------------------------
    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:
    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.
    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.
    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.
    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.
    244 The following scheduler operations return a task in need for help
    246 - unblock,
    248 - change priority,
    250 - yield, and
    252 - ask for help.
    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.
    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.
    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.
    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.
    637569   :align: center
     571Scheduler Helping Protocol
     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.
     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
     589* ask a scheduler node for help,
     590* reconsider the help request of a scheduler node,
     591* withdraw a schedule node.
     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.
     597In case a thread is allowed to use more than one scheduler node it will ask
     598these nodes for help
     600* in case of pre-emption, or
     601* an unblock did not schedule the thread, or
     602* a yield  was successful.
     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.
     614After a thread dispatch the reconsider help request operation is used to clean
     615up stale help registrations in the scheduler contexts.
     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.
    639621Thread Dispatch Details
Note: See TracChangeset for help on using the changeset viewer.