[rtems commit] doc: Add SMP glossary

Sebastian Huber sebh at rtems.org
Mon May 5 07:36:18 UTC 2014


Module:    rtems
Branch:    master
Commit:    d20b029af9b09bedb637f05770aa1497d79bbf08
Changeset: http://git.rtems.org/rtems/commit/?id=d20b029af9b09bedb637f05770aa1497d79bbf08

Author:    Sebastian Huber <sebastian.huber at embedded-brains.de>
Date:      Wed Apr 16 20:54:48 2014 +0200

doc: Add SMP glossary

---

 doc/user/smp.t |  110 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 110 insertions(+), 0 deletions(-)

diff --git a/doc/user/smp.t b/doc/user/smp.t
index 3d9cc29..d0e067f 100644
--- a/doc/user/smp.t
+++ b/doc/user/smp.t
@@ -29,6 +29,116 @@ The application level services currently provided are:
 @c
 @section Background
 
+ at subsection Glossary
+
+ at table @dfn
+
+ at item scheduler
+
+A @dfn{scheduler} or @dfn{scheduling algorithm} allocates processors to a
+subset of its set of ready tasks.  So it manages access to the processor
+resource.  Various algorithms exist to choose the tasks allowed to use a
+processor out of the set of ready tasks.  One method is to assign each task a
+priority number and assign the tasks with the lowest priority number to one
+processor of the set of processors owned by a scheduler instance.
+
+ at item scheduler instance
+
+A @dfn{scheduler instance} is a scheduling algorithm with a corresponding
+context to store its internal state.  Each processor in the system is owned by
+at most one scheduler instance.  The processor to scheduler instance assignment
+is determined at application configuration time.  @xref{Configuring a System
+Configuring Clustered/Partitioned Schedulers}.
+
+ at item cluster
+
+We have clustered scheduling in case the set of processors of a system is
+partitioned into non-empty pairwise disjoint subsets.  These subsets are called
+ at dfn{clusters}.  Each cluster is owned by exactly one scheduler instance.
+
+ at item partition
+
+Clusters with a cardinality of one are @dfn{partitions}.
+
+ at item task
+
+A @dfn{task} or @dfn{thread} is a context which can execute on a processor.  It
+consists normally of a set of registers and a stack.  The terms @dfn{task} and
+ at dfn{thread} are synonym in RTEMS
+
+ at item task processor affinity
+
+The set of processors on which a task is allowed to execute.
+
+ at item task migration
+
+ at dfn{Task migration} happens in case a task stops execution on one processor
+and resumes execution on another processor.
+
+ at item blocked task
+
+A task is @dfn{blocked} if it is not allowed to execute.  There are several
+reasons why a task is blocked, for example
+
+ at itemize @bullet
+
+ at item it has to wait for a resource, currently owned by another task,
+
+ at item some time must elapse, for example the next period start or some time
+out,
+
+ at item it is explicitly suspended, or
+
+ at item it is not yet started.
+
+ at end itemize
+
+Blocked tasks are not an element of the set of ready tasks of a scheduler
+instance.
+
+ at item ready task
+
+A task is @dfn{ready} if it is allowed to execute, but has no processor
+assigned.  The scheduler decided that other tasks are currently more important.
+
+ at item scheduled task
+
+A task is @dfn{scheduled} if it is allowed to execute and has a processor
+assigned.  Such a task executes currently on a processor or is about to start
+execution.  A task about to start execution it is an heir task on exactly one
+processor in the system.
+
+ at item in the air task
+
+A task is @dfn{in the air} if it is in a transient state and has a processor
+assigned.  The next scheduler operation will turn it into a blocked, ready or
+scheduled task.
+
+ at item atomic operations
+
+Atomic operations are defined in terms of @cite{ISO/IEC 9899:2011}.
+
+ at item SMP locks
+
+The @dfn{SMP locks} ensure mutual exclusion on the lowest level and are a
+replacement for the sections of disabled interrupts.  Interrupts are usually
+disabled while holding an SMP lock.  They are implemented using atomic
+operations.  Currently a ticket lock is used in RTEMS.
+
+ at item SMP barriers
+
+The @dfn{SMP locks} ensure that a set of processors reaches a common
+synchronization point in time.  They are implemented using atomic operations.
+Currently a sense barrier is used in RTEMS.
+
+ at item Giant lock
+
+The @dfn{Giant lock} is a recursive SMP lock protecting most parts of the
+operating system state.  Virtually every operating system service must acquire
+and release the Giant lock during its operation.
+
+ at end table
+
 @subsection Uniprocessor versus SMP Parallelism
 
 Uniprocessor systems have long been used in embedded systems. In this hardware




More information about the vc mailing list