[rtems-docs commit] c-user: Use uniprocessor throughout
Sebastian Huber
sebh at rtems.org
Wed Mar 7 14:35:21 UTC 2018
Module: rtems-docs
Branch: master
Commit: 464d541653f0ca478b0bfc0bc7f5e3270dead6e5
Changeset: http://git.rtems.org/rtems-docs/commit/?id=464d541653f0ca478b0bfc0bc7f5e3270dead6e5
Author: Sebastian Huber <sebastian.huber at embedded-brains.de>
Date: Wed Mar 7 14:18:10 2018 +0100
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(-)
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() <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
More information about the vc
mailing list