[rtems commit] doc: Add SMP glossary

[Joel Sherrill]

A significant portion of this is not SMP specific.
Placing it in the SMP chapter implies that it is.

On 5/5/2014 2:36 AM, Sebastian Huber wrote:
> 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
>
> _______________________________________________
> rtems-vc mailing list
> rtems-vc at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-vc

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985