From 464d541653f0ca478b0bfc0bc7f5e3270dead6e5 Mon Sep 17 00:00:00 2001 From: Sebastian Huber Date: Wed, 7 Mar 2018 14:18:10 +0100 Subject: c-user: Use uniprocessor throughout --- c-user/configuring_a_system.rst | 10 +++++----- c-user/interrupt_manager.rst | 6 +++--- c-user/key_concepts.rst | 4 ++-- c-user/self_contained_objects.rst | 2 +- c-user/semaphore_manager.rst | 2 +- c-user/symmetric_multiprocessing_services.rst | 24 ++++++++++++------------ c-user/timer_manager.rst | 2 +- 7 files changed, 25 insertions(+), 25 deletions(-) (limited to 'c-user') diff --git a/c-user/configuring_a_system.rst b/c-user/configuring_a_system.rst index 6ea025a..bfeba20 100644 --- a/c-user/configuring_a_system.rst +++ b/c-user/configuring_a_system.rst @@ -603,7 +603,7 @@ DESCRIPTION: NOTES: This configuration option is only used in SMP configurations. In - uni-processor configurations, the :ref:`PriorityCeiling` is used for MrsP + uniprocessor configurations, the :ref:`PriorityCeiling` is used for MrsP semaphores and thus no extra memory is necessary. .. index:: CONFIGURE_MAXIMUM_MESSAGE_QUEUES @@ -1435,7 +1435,7 @@ DESCRIPTION: NOTES: If there are more processors available than configured, the rest will be - ignored. This configuration define is ignored in uni-processor + ignored. This configuration define is ignored in uniprocessor configurations. .. index:: CONFIGURE_MICROSECONDS_PER_TICK @@ -3327,7 +3327,7 @@ DEFAULT VALUE: DESCRIPTION: The Constant Bandwidth Server Scheduler (CBS) is an alternative scheduler - in RTEMS for uni-processor applications. The CBS is a budget aware + in RTEMS for uniprocessor applications. The CBS is a budget aware extension of EDF scheduler. The goal of this scheduler is to ensure temporal isolation of tasks. The CBS is equipped with a set of additional rules and provides with an extensive API. @@ -3359,7 +3359,7 @@ DEFAULT VALUE: DESCRIPTION: The Earliest Deadline First Scheduler (EDF) is an alternative scheduler in - RTEMS for uni-processor applications. The EDF schedules tasks with dynamic + RTEMS for uniprocessor applications. The EDF schedules tasks with dynamic priorities equal to deadlines. The deadlines are declared using only Rate Monotonic manager which handles periodic behavior. Period is always equal to deadline. If a task does not have any deadline declared or the deadline @@ -3457,7 +3457,7 @@ DEFAULT VALUE: DESCRIPTION: The Deterministic Priority Scheduler is the default scheduler in RTEMS for - uni-processor applications and is designed for predictable performance + uniprocessor applications and is designed for predictable performance under the highest loads. It can block or unblock a thread in a constant amount of time. This scheduler requires a variable amount of memory based upon the number of priorities configured in the system. diff --git a/c-user/interrupt_manager.rst b/c-user/interrupt_manager.rst index e971d60..2734f17 100644 --- a/c-user/interrupt_manager.rst +++ b/c-user/interrupt_manager.rst @@ -341,7 +341,7 @@ NOTES: This directive will not cause the calling task to be preempted. - This directive is only available in uni-processor configurations. The + This directive is only available in uniprocessor configurations. The directive ``rtems_interrupt_local_disable`` is available in all configurations. @@ -414,7 +414,7 @@ NOTES: This directive will not cause the calling task to be preempted. - This directive is only available in uni-processor configurations. The + This directive is only available in uniprocessor configurations. The directive ``rtems_interrupt_local_enable`` is available in all configurations. @@ -454,7 +454,7 @@ NOTES: This directive will not cause the calling task to be preempted. - This directive is only available in uni-processor configurations. The + This directive is only available in uniprocessor configurations. The directives ``rtems_interrupt_local_disable`` and ``rtems_interrupt_local_enable`` are available in all configurations. diff --git a/c-user/key_concepts.rst b/c-user/key_concepts.rst index ff28430..f717a87 100644 --- a/c-user/key_concepts.rst +++ b/c-user/key_concepts.rst @@ -359,7 +359,7 @@ The :math:`O(m)` Independence-Preserving Protocol (OMIP) is a generalization of the priority inheritance protocol to clustered scheduling which avoids the non-preemptive sections present with priority boosting :cite:`Brandenburg:2013:OMIP`. The :math:`m` denotes the number of processors -in the system. Similar to the uni-processor priority inheritance protocol, the +in the system. Similar to the uniprocessor priority inheritance protocol, the OMIP mutexes do not need any external configuration data, e.g. a ceiling priority. This makes them a good choice for general purpose libraries that need internal locking. The complex part of the implementation is contained in @@ -378,7 +378,7 @@ the Classic API. There are two thread queuing disciplines available which define the order of the threads on a particular thread queue. Threads can wait in FIFO or priority order. -In uni-processor configurations, the priority queuing discipline just orders +In uniprocessor configurations, the priority queuing discipline just orders the threads according to their current priority and in FIFO order in case of equal priorities. However, in SMP configurations, the situation is a bit more difficult due to the support for clustered scheduling. It makes no sense to diff --git a/c-user/self_contained_objects.rst b/c-user/self_contained_objects.rst index ee43463..28c9839 100644 --- a/c-user/self_contained_objects.rst +++ b/c-user/self_contained_objects.rst @@ -122,7 +122,7 @@ Mutual Exclusion The :c:type:`rtems_mutex` and :c:type:`rtems_recursive_mutex` objects provide mutual-exclusion synchronization using the :ref:`PriorityInheritance` in -uni-processor configurations or the :ref:`OMIP` in SMP configurations. +uniprocessor configurations or the :ref:`OMIP` in SMP configurations. Recursive locking should be used with care :cite:`Williams:2012:CA`. The storage space for these object must be provided by the user. There are no defined comparison or assignment operators for these type. Only the object diff --git a/c-user/semaphore_manager.rst b/c-user/semaphore_manager.rst index 32c762e..695d75a 100644 --- a/c-user/semaphore_manager.rst +++ b/c-user/semaphore_manager.rst @@ -114,7 +114,7 @@ Multiprocessor Resource Sharing Protocol ---------------------------------------- RTEMS supports the :ref:`MrsP` for local, binary semaphores that use the -priority task wait queue blocking discipline. In uni-processor configurations, +priority task wait queue blocking discipline. In uniprocessor configurations, the :ref:`PriorityCeiling` is used instead. .. _Building a Semaphore Attribute Set: diff --git a/c-user/symmetric_multiprocessing_services.rst b/c-user/symmetric_multiprocessing_services.rst index 15edfdd..7714bf7 100644 --- a/c-user/symmetric_multiprocessing_services.rst +++ b/c-user/symmetric_multiprocessing_services.rst @@ -304,14 +304,14 @@ priority four. Application Issues ================== -Most operating system services provided by the uni-processor RTEMS are +Most operating system services provided by the uniprocessor RTEMS are available in SMP configurations as well. However, applications designed for an -uni-processor environment may need some changes to correctly run in an SMP +uniprocessor environment may need some changes to correctly run in an SMP configuration. As discussed earlier, SMP systems have opportunities for true parallelism which -was not possible on uni-processor systems. Consequently, multiple techniques -that provided adequate critical sections on uni-processor systems are unsafe on +was not possible on uniprocessor systems. Consequently, multiple techniques +that provided adequate critical sections on uniprocessor systems are unsafe on SMP systems. In this section, some of these unsafe techniques will be discussed. @@ -333,7 +333,7 @@ task variable API has been removed in RTEMS 5.1. Highest Priority Thread Never Walks Alone ----------------------------------------- -On a uni-processor system, it is safe to assume that when the highest priority +On a uniprocessor system, it is safe to assume that when the highest priority task in an application executes, it will execute without being preempted until it voluntarily blocks. Interrupts may occur while it is executing, but there will be no context switch to another task unless the highest priority task @@ -347,7 +347,7 @@ data. In an SMP system, it cannot be assumed there will never be a single task executing. It should be assumed that every processor is executing another application task. Further, those tasks will be ones which would not have been -executed in a uni-processor configuration and should be assumed to have data +executed in a uniprocessor configuration and should be assumed to have data synchronization conflicts with what was formerly the highest priority task which executed without conflict. @@ -355,7 +355,7 @@ Disabling of Thread Preemption ------------------------------ A thread which disables preemption prevents that a higher priority thread gets -hold of its processor involuntarily. In uni-processor configurations, this can +hold of its processor involuntarily. In uniprocessor configurations, this can be used to ensure mutual exclusion at thread level. In SMP configurations, however, more than one executing thread may exist. Thus, it is impossible to ensure mutual exclusion using this mechanism. In order to prevent that @@ -366,7 +366,7 @@ case run-time errors. Disabling of Interrupts ----------------------- -A low overhead means that ensures mutual exclusion in uni-processor +A low overhead means that ensures mutual exclusion in uniprocessor configurations is the disabling of interrupts around a critical section. This is commonly used in device driver code. In SMP configurations, however, disabling the interrupts on one processor has no effect on other processors. @@ -392,7 +392,7 @@ Since disabling of interrupts is insufficient to ensure system-wide mutual exclusion on SMP a new low-level synchronization primitive was added -- interrupt locks. The interrupt locks are a simple API layer on top of the SMP locks used for low-level synchronization in the operating system core. -Currently, they are implemented as a ticket lock. In uni-processor +Currently, they are implemented as a ticket lock. In uniprocessor configurations, they degenerate to simple interrupt disable/enable sequences by means of the C pre-processor. It is disallowed to acquire a single interrupt lock in a nested way. This will result in an infinite loop with interrupts @@ -470,7 +470,7 @@ Timers Do Not Stop Immediately ------------------------------ Timer service routines run in the context of the clock interrupt. On -uni-processor configurations, it is sufficient to disable interrupts and remove +uniprocessor configurations, it is sufficient to disable interrupts and remove a timer from the set of active timers to stop it. In SMP configurations, however, the timer service routine may already run and wait on an SMP lock owned by the thread which is about to stop the timer. This opens the door to @@ -520,7 +520,7 @@ DIRECTIVE STATUS CODES: application (if a scheduler is assigned) plus one. DESCRIPTION: - In uni-processor configurations, a value of one will be returned. + In uniprocessor configurations, a value of one will be returned. In SMP configurations, this returns the value of a global variable set during system initialization to indicate the count of utilized processors. @@ -549,7 +549,7 @@ DIRECTIVE STATUS CODES: The index of the current processor. DESCRIPTION: - In uni-processor configurations, a value of zero will be returned. + In uniprocessor configurations, a value of zero will be returned. In SMP configurations, an architecture specific method is used to obtain the index of the current processor in the system. The set of processor indices diff --git a/c-user/timer_manager.rst b/c-user/timer_manager.rst index 8e41b47..a1e5fd9 100644 --- a/c-user/timer_manager.rst +++ b/c-user/timer_manager.rst @@ -67,7 +67,7 @@ Timer Server The Timer Server task is responsible for executing the timer service routines associated with all task-based timers. This task executes at a priority specified by :ref:`rtems_timer_initiate_server() ` -and it may have a priority of zero (the highest priority). In uni-processor +and it may have a priority of zero (the highest priority). In uniprocessor configurations, it is created non-preemptible. By providing a mechanism where timer service routines execute in task rather -- cgit v1.2.3