summaryrefslogtreecommitdiffstats
path: root/doc/user/smp.t (unfollow)
Commit message (Collapse)AuthorFilesLines
2017-01-11Remove texinfo format documentation. Replaced by Sphinx formatted documentation.Joel Sherrill1-1016/+0
closes #2812.
2016-01-05doc: Mention potential SMP scheduler improvementSebastian Huber1-0/+3
2015-12-16doc: SMP status of RTEMSSebastian Huber1-0/+3
2015-12-16doc: SMP introductionSebastian Huber1-0/+17
2015-09-04smp: DocumentationSebastian Huber1-1/+1
2015-09-04smp: DocumentationSebastian Huber1-0/+65
Close #2274.
2015-09-04score: Implement priority boostingSebastian Huber1-2/+4
2015-09-04score: Implement SMP-specific priority queueSebastian Huber1-0/+54
2015-09-04smp: DocumentationSebastian Huber1-0/+39
2015-09-04smp: DocumentationSebastian Huber1-2/+2
2015-07-17doc: Add thread dispatch details for SMPSebastian Huber1-0/+69
2015-07-17doc: Clarify interrupts disable problems on SMPSebastian Huber1-11/+64
2015-07-17doc: Fix SMP task variables sectionSebastian Huber1-10/+10
2014-07-09score: Implement scheduler helping protocolSebastian Huber1-0/+78
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.
2014-06-02score: _Scheduler_Set_affinity()Sebastian Huber1-1/+9
Do not change the scheduler with this function. Documentation. Coding style.
2014-05-20rtems: Clarify task set/get scheduler parametersSebastian Huber1-5/+7
2014-05-08doc: Move SMP glossary to global glossarySebastian Huber1-110/+0
Add some terms.
2014-05-07score: Implement forced thread migrationSebastian Huber1-0/+46
The current implementation of task migration in RTEMS has some implications with respect to the interrupt latency. It is crucial to preserve the system invariant that a task can execute on at most one processor in the system at a time. This is accomplished with a boolean indicator in the task context. The processor architecture specific low-level task context switch code will mark that a task context is no longer executing and waits that the heir context stopped execution before it restores the heir context and resumes execution of the heir task. So there is one point in time in which a processor is without a task. This is essential to avoid cyclic dependencies in case multiple tasks migrate at once. Otherwise some supervising entity is necessary to prevent life-locks. Such a global supervisor would lead to scalability problems so this approach is not used. Currently the thread dispatch is performed with interrupts disabled. So in case the heir task is currently executing on another processor then this prolongs the time of disabled interrupts since one processor has to wait for another processor to make progress. It is difficult to avoid this issue with the interrupt latency since interrupts normally store the context of the interrupted task on its stack. In case a task is marked as not executing we must not use its task stack to store such an interrupt context. We cannot use the heir stack before it stopped execution on another processor. So if we enable interrupts during this transition we have to provide an alternative task independent stack for this time frame. This issue needs further investigation.
2014-05-05score: SMP_FATAL_SCHEDULER_WITHOUT_PROCESSORSSebastian Huber1-1/+3
Avoid the SMP_FATAL_SCHEDULER_WITHOUT_PROCESSORS fatal error and make it a run-time error in rtems_scheduler_ident() and _Scheduler_Get_by_id().
2014-05-05doc: Add SMP glossarySebastian Huber1-0/+110
2014-04-22doc: Setting Affinity to a Single ProcessorSebastian Huber1-8/+20
2014-04-17doc: rtems_task_set_scheduler()Sebastian Huber1-0/+77
2014-04-17doc: rtems_task_get_scheduler()Sebastian Huber1-0/+35
2014-04-17doc: rtems_scheduler_get_processor_set()Sebastian Huber1-0/+40
2014-04-17doc: rtems_scheduler_ident()Sebastian Huber1-0/+37
2014-04-17doc: rtems_task_set_affinity()Sebastian Huber1-31/+14
2014-04-17doc: rtems_task_get_affinity()Sebastian Huber1-24/+15
2014-04-17doc: rtems_get_current_processor()Sebastian Huber1-0/+39
2014-04-17doc: rtems_get_processor_count()Sebastian Huber1-11/+14
2014-03-11smp.t: Add Background and Operation SectionsJoel Sherrill1-7/+200
2014-03-11Classic API Users Guide: Add SMP and affinity services.Joel Sherrill1-0/+165
This patch adds the initial version of the SMP chapter to the Users Guide.