|author||Sebastian Huber <email@example.com>||2018-09-07 15:47:43 +0200|
|committer||Sebastian Huber <firstname.lastname@example.org>||2018-09-10 07:09:46 +0200|
c-user: Mention thread pinning
1 files changed, 22 insertions, 0 deletions
diff --git a/c-user/symmetric_multiprocessing_services.rst b/c-user/symmetric_multiprocessing_services.rst
index b2773e7..91c1d27 100644
@@ -809,3 +809,25 @@ RTEMS provides two means for per-processor data:
This API is not intended for general application use. Please ask on the
development mailing list in case you want to use it.
+Thread pinning ensures that a thread is only dispatched to the processor on
+which it is pinned. It may be used to access per-processor data structures in
+critical sections with enabled thread dispatching, e.g. a pinned thread is
+allowed to block. The `_Thread_Pin()` operation will pin the executing thread
+to its current processor. A thread may be pinned recursively, the last unpin
+request via `_Thread_Unpin()` revokes the pinning.
+Thread pinning should be used only for short critical sections and not all
+the time. Thread pinning is a very low overhead operation in case the
+thread is not preempted during the pinning. A preemption will result in
+scheduler operations to ensure that the thread executes only on its pinned
+processor. Thread pinning must be used with care, since it prevents help
+through the locking protocols. This makes the :ref:`OMIP <OMIP>` and
+:ref:`MrsP <MrsP>` locking protocols ineffective if pinned threads are
+The thread pinning is not intended for general application use. Please ask on
+the development mailing list in case you want to use it.