summaryrefslogtreecommitdiffstats
path: root/doc/user/smp.t (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Remove texinfo format documentation. Replaced by Sphinx formatted documentation.Joel Sherrill2017-01-111-1016/+0
| | | | closes #2812.
* doc: Mention potential SMP scheduler improvementSebastian Huber2016-01-051-0/+3
|
* doc: SMP status of RTEMSSebastian Huber2015-12-161-0/+3
|
* doc: SMP introductionSebastian Huber2015-12-161-0/+17
|
* smp: DocumentationSebastian Huber2015-09-041-1/+1
|
* smp: DocumentationSebastian Huber2015-09-041-0/+65
| | | | Close #2274.
* score: Implement priority boostingSebastian Huber2015-09-041-2/+4
|
* score: Implement SMP-specific priority queueSebastian Huber2015-09-041-0/+54
|
* smp: DocumentationSebastian Huber2015-09-041-0/+39
|
* smp: DocumentationSebastian Huber2015-09-041-2/+2
|
* doc: Add thread dispatch details for SMPSebastian Huber2015-07-171-0/+69
|
* doc: Clarify interrupts disable problems on SMPSebastian Huber2015-07-171-11/+64
|
* doc: Fix SMP task variables sectionSebastian Huber2015-07-171-10/+10
|
* score: Implement scheduler helping protocolSebastian Huber2014-07-091-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.
* score: _Scheduler_Set_affinity()Sebastian Huber2014-06-021-1/+9
| | | | | Do not change the scheduler with this function. Documentation. Coding style.
* rtems: Clarify task set/get scheduler parametersSebastian Huber2014-05-201-5/+7
|
* doc: Move SMP glossary to global glossarySebastian Huber2014-05-081-110/+0
| | | | Add some terms.
* score: Implement forced thread migrationSebastian Huber2014-05-071-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.
* score: SMP_FATAL_SCHEDULER_WITHOUT_PROCESSORSSebastian Huber2014-05-051-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().
* doc: Add SMP glossarySebastian Huber2014-05-051-0/+110
|
* doc: Setting Affinity to a Single ProcessorSebastian Huber2014-04-221-8/+20
|
* doc: rtems_task_set_scheduler()Sebastian Huber2014-04-171-0/+77
|
* doc: rtems_task_get_scheduler()Sebastian Huber2014-04-171-0/+35
|
* doc: rtems_scheduler_get_processor_set()Sebastian Huber2014-04-171-0/+40
|
* doc: rtems_scheduler_ident()Sebastian Huber2014-04-171-0/+37
|
* doc: rtems_task_set_affinity()Sebastian Huber2014-04-171-31/+14
|
* doc: rtems_task_get_affinity()Sebastian Huber2014-04-171-24/+15
|
* doc: rtems_get_current_processor()Sebastian Huber2014-04-171-0/+39
|
* doc: rtems_get_processor_count()Sebastian Huber2014-04-171-11/+14
|
* smp.t: Add Background and Operation SectionsJoel Sherrill2014-03-111-7/+200
|
* Classic API Users Guide: Add SMP and affinity services.Joel Sherrill2014-03-111-0/+165
This patch adds the initial version of the SMP chapter to the Users Guide.
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-05 04:13:26 +0000