[rtems-docs commit] c-user: Replace pre-emption with preemption

[Sebastian Huber]

Module:    rtems-docs
Branch:    master
Commit:    39773ce8bd21fcdf9d43739b56aba7a5fdedd828
Changeset: http://git.rtems.org/rtems-docs/commit/?id=39773ce8bd21fcdf9d43739b56aba7a5fdedd828

Author:    Sebastian Huber <sebastian.huber at embedded-brains.de>
Date:      Thu May 11 09:25:04 2017 +0200

c-user: Replace pre-emption with preemption

---

 c-user/key_concepts.rst                       |  4 ++--
 c-user/symmetric_multiprocessing_services.rst | 12 ++++++------
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/c-user/key_concepts.rst b/c-user/key_concepts.rst
index cd41c7f..52e416c 100644
--- a/c-user/key_concepts.rst
+++ b/c-user/key_concepts.rst
@@ -271,7 +271,7 @@ Priority Inversion
 .. index:: priority inversion
 
 Priority inversion is a form of indefinite postponement which is common in
-multitasking, pre-emptive executives with shared resources.  Priority inversion
+multitasking, preemptive executives with shared resources.  Priority inversion
 occurs when a high priority tasks requests access to shared resource which is
 currently allocated to a low priority task.  The high priority task must block
 until the low priority task releases the resource.  This problem is exacerbated
@@ -333,7 +333,7 @@ scheduler instance.  In case the thread owning the mutex releases the mutex,
 then the normal priority of the thread is restored.  Threads that wait for
 mutex ownership are not blocked with respect to the scheduler and instead
 perform a busy wait.  The MrsP uses temporary thread migrations to foreign
-scheduler instances in case of a pre-emption of the mutex owner.  This locking
+scheduler instances in case of a preemption of the mutex owner.  This locking
 protocol is available since RTEMS 4.11. It was re-implemented in RTEMS 4.12 to
 overcome some shortcomings of the original implementation
 :cite:`Catellani:2015:MrsP`.
diff --git a/c-user/symmetric_multiprocessing_services.rst b/c-user/symmetric_multiprocessing_services.rst
index 2a2d669..16005f3 100644
--- a/c-user/symmetric_multiprocessing_services.rst
+++ b/c-user/symmetric_multiprocessing_services.rst
@@ -347,15 +347,15 @@ executed in a uni-processor configuration and should be assumed to have data
 synchronization conflicts with what was formerly the highest priority task
 which executed without conflict.
 
-Disabling of Thread Pre-Emption
--------------------------------
+Disabling of Thread Preemption
+------------------------------
 
-A thread which disables pre-emption prevents that a higher priority thread gets
+A thread which disables preemption prevents that a higher priority thread gets
 hold of its processor involuntarily.  In uni-processor 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
-applications using pre-emption for this purpose, would show inappropriate
+applications using preemption for this purpose, would show inappropriate
 behaviour, this feature is disabled in SMP configurations and its use would
 case run-time errors.
 
@@ -706,7 +706,7 @@ creation.  The home scheduler instance can be changed with
 :ref:`rtems_task_set_scheduler() <rtems_task_set_scheduler>`.  Due to the
 locking protocols a thread may gain access to scheduler nodes of other
 scheduler instances.  This allows the thread to temporarily migrate to another
-scheduler instance in case of pre-emption.
+scheduler instance in case of preemption.
 
 The scheduler infrastructure is based on an object-oriented design.  The
 scheduler operations for a thread are defined as virtual functions.  For the
@@ -724,7 +724,7 @@ variants.  Up to now, only priority-based schedulers are implemented.
 In case a thread is allowed to use more than one scheduler node it will ask
 these nodes for help
 
-* in case of pre-emption, or
+* in case of preemption, or
 * an unblock did not schedule the thread, or
 * a yield  was successful.