summaryrefslogtreecommitdiffstats
path: root/c-user
diff options
context:
space:
mode:
authorSebastian Huber <sebastian.huber@embedded-brains.de>2017-05-11 09:25:04 +0200
committerSebastian Huber <sebastian.huber@embedded-brains.de>2017-05-11 09:26:09 +0200
commit39773ce8bd21fcdf9d43739b56aba7a5fdedd828 (patch)
tree9dd6ffdf67b755d87d5da919cd1038153c965890 /c-user
parenthosts.rst: Correct Ubuntu instructions (diff)
downloadrtems-docs-39773ce8bd21fcdf9d43739b56aba7a5fdedd828.tar.bz2
c-user: Replace pre-emption with preemption
Diffstat (limited to 'c-user')
-rw-r--r--c-user/key_concepts.rst4
-rw-r--r--c-user/symmetric_multiprocessing_services.rst12
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.