Changeset 9de1be6 in rtems-docs


Ignore:
Timestamp:
Feb 1, 2017, 12:23:56 PM (3 years ago)
Author:
Sebastian Huber <sebastian.huber@…>
Branches:
master
Children:
ba781f9
Parents:
a6a1f72
Message:

c-user: Remove duplicate thread queue section

File:
1 edited

Legend:

Unmodified
Added
Removed
  • c-user/symmetric_multiprocessing_services.rst

    ra6a1f72 r9de1be6  
    187187To set the scheduler of a task see :ref:`SCHEDULER_IDENT - Get ID of a
    188188scheduler` and :ref:`TASK_SET_SCHEDULER - Set scheduler of a task`.
    189 
    190 Task Priority Queues
    191 --------------------
    192 
    193 Due to the support for clustered scheduling the task priority queues need
    194 special attention.  It makes no sense to compare the priority values of two
    195 different scheduler instances.  Thus, it is not possible to simply use one
    196 plain priority queue for tasks of different scheduler instances.
    197 
    198 One solution to this problem is to use two levels of queues.  The top level
    199 queue provides FIFO ordering and contains priority queues.  Each priority queue
    200 is associated with a scheduler instance and contains only tasks of this
    201 scheduler instance.  Tasks are enqueued in the priority queue corresponding to
    202 their scheduler instance.  In case this priority queue was empty, then it is
    203 appended to the FIFO.  To dequeue a task the highest priority task of the first
    204 priority queue in the FIFO is selected.  Then the first priority queue is
    205 removed from the FIFO.  In case the previously first priority queue is not
    206 empty, then it is appended to the FIFO.  So there is FIFO fairness with respect
    207 to the highest priority task of each scheduler instances. See also
    208 :cite:`Brandenburg:2013:OMIP`.
    209 
    210 Such a two level queue may need a considerable amount of memory if fast enqueue
    211 and dequeue operations are desired (depends on the scheduler instance count).
    212 To mitigate this problem an approch of the FreeBSD kernel was implemented in
    213 RTEMS.  We have the invariant that a task can be enqueued on at most one task
    214 queue.  Thus, we need only as many queues as we have tasks.  Each task is
    215 equipped with spare task queue which it can give to an object on demand.  The
    216 task queue uses a dedicated memory space independent of the other memory used
    217 for the task itself. In case a task needs to block, then there are two options
    218 
    219 - the object already has task queue, then the task enqueues itself to this
    220   already present queue and the spare task queue of the task is added to a list
    221   of free queues for this object, or
    222 
    223 - otherwise, then the queue of the task is given to the object and the task
    224   enqueues itself to this queue.
    225 
    226 In case the task is dequeued, then there are two options
    227 
    228 - the task is the last task on the queue, then it removes this queue from the
    229   object and reclaims it for its own purpose, or
    230 
    231 - otherwise, then the task removes one queue from the free list of the object
    232   and reclaims it for its own purpose.
    233 
    234 Since there are usually more objects than tasks, this actually reduces the
    235 memory demands. In addition the objects contain only a pointer to the task
    236 queue structure. This helps to hide implementation details and makes it
    237 possible to use self-contained synchronization objects in Newlib and GCC (C++
    238 and OpenMP run-time support).
    239189
    240190Scheduler Helping Protocol
Note: See TracChangeset for help on using the changeset viewer.