c-user: Use uniprocessor throughout

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