Changeset 9de1be6 in rtems-docs

Feb 1, 2017, 12:23:56 PM (3 years ago)
Sebastian Huber <sebastian.huber@…>

c-user: Remove duplicate thread queue section

1 edited


  • 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`.
    190 Task Priority Queues
    191 --------------------
    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.
    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`.
    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
    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
    223 - otherwise, then the queue of the task is given to the object and the task
    224   enqueues itself to this queue.
    226 In case the task is dequeued, then there are two options
    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
    231 - otherwise, then the task removes one queue from the free list of the object
    232   and reclaims it for its own purpose.
    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).
    240190Scheduler Helping Protocol
Note: See TracChangeset for help on using the changeset viewer.