kernel.sgml

eCos/RedBoot for勤研ARM AnywhereII(4510) 含全部源代码

<!-- {{{ Banner                         -->

<!-- =============================================================== -->
<!--                                                                 -->
<!--     kernel.sgml                                                 -->
<!--                                                                 -->
<!--     eCos kernel documentation.                                  -->
<!--                                                                 -->
<!-- =============================================================== -->
<!-- ####COPYRIGHTBEGIN####                                          -->
<!--                                                                 -->
<!-- =============================================================== -->
<!-- Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002 Red Hat, Inc.  -->
<!-- This material may be distributed only subject to the terms      -->
<!-- and conditions set forth in the Open Publication License, v1.0  -->
<!-- or later (the latest version is presently available at          -->
<!-- http://www.opencontent.org/openpub/)                            -->
<!-- Distribution of the work or derivative of the work in any       -->
<!-- standard (paper) book form is prohibited unless prior           -->
<!-- permission obtained from the copyright holder                   -->
<!-- =============================================================== -->
<!--                                                                 -->      
<!-- ####COPYRIGHTEND####                                            -->
<!-- =============================================================== -->
<!-- #####DESCRIPTIONBEGIN####                                       -->
<!--                                                                 -->
<!-- Author(s):    nickg, bartv, markg                               -->
<!-- Contributors: eCos team                                         -->
<!-- Date:        2002/02/13                                         -->
<!-- Version:     0.02                                               -->
<!--                                                                 -->
<!-- ####DESCRIPTIONEND####                                          -->
<!-- =============================================================== -->

<!-- }}} -->

<part id="kernel">
  <title>The eCos Kernel</title>

<!-- {{{ Overview                       -->

  <refentry id="kernel-overview">

    <refmeta>
    <refentrytitle>Kernel Overview</refentrytitle>
    </refmeta>

    <refnamediv>
      <refname>Kernel</refname>
      <refpurpose>Overview of the eCos Kernel</refpurpose>
    </refnamediv>

<!-- {{{ Description                    -->

    <refsect1 id="kernel-overview-description">
      <title>Description</title>
      <para>
The kernel is one of the key packages in all of eCos. It provides the
core functionality needed for developing multi-threaded applications:
      </para>
      <orderedlist>
        <listitem><para>
The ability to create new threads in the system, either during startup
or when the system is already running.
        </para></listitem>
        <listitem><para>
Control over the various threads in the system, for example
manipulating their priorities.
        </para></listitem>
        <listitem><para>
A choice of schedulers, determining which thread should currently be
running. 
        </para></listitem>
        <listitem><para>
A range of synchronization primitives, allowing threads to interact
and share data safely.
        </para></listitem>
        <listitem><para>
Integration with the system's support for interrupts and exceptions.
        </para></listitem>
      </orderedlist>
      <para>
In some other operating systems the kernel provides additional
functionality. For example the kernel may also provide memory
allocation functionality, and device drivers may be part of the kernel
as well. This is not the case for eCos. Memory allocation is handled
by a separate package. Similary each device driver will typically be a
separate package. Various packages are combined and configured using
the eCos configuration technology to meet the requirements of the
application.
      </para>
      <para>
The eCos kernel package is optional. It is possible to write
single-threaded applications which do not use any kernel
functionality, for example RedBoot. Typically such applications are
based around a central polling loop, continually checking all devices
and taking appropriate action when I/O occurs. A small amount of
calculation is possible every iteration, at the cost of an increased
delay between an I/O event occurring and the polling loop detecting
the event. When the requirements are straightforward it may well be
easier to develop the application using a polling loop, avoiding the
complexities of multiple threads and synchronization between threads.
As requirements get more complicated a multi-threaded solution becomes
more appropriate, requiring the use of the kernel. In fact some of the
more advanced packages in eCos, for example the TCP/IP stack, use
multi-threading internally. Therefore if the application uses any of
those packages then the kernel becomes a required package, not an
optional one.
      </para>
      <para>
The kernel functionality can be used in one of two ways. The kernel
provides its own C API, with functions like
<function>cyg_thread_create</function> and
<function>cyg_mutex_lock</function>. These can be called directly from
application code or from other packages. Alternatively there are a
number of packages which provide compatibility with existing API's,
for example POSIX threads or &micro;ITRON. These allow application
code to call standard functions such as
<function>pthread_create</function>, and those functions are
implemented using the basic functionality provided by the eCos kernel.
Using compatibility packages in an eCos application can make it much
easier to reuse code developed in other environments, and to share
code.
      </para>
      <para>
Although the different compatibility packages have similar
requirements on the underlying kernel, for example the ability to
create a new thread, there are differences in the exact semantics. For
example, strict &micro;ITRON compliance requires that kernel
timeslicing is disabled. This is achieved largely through the
configuration technology. The kernel provides a number of
configuration options that control the exact semantics that are
provided, and the various compatibility packages require particular
settings for those options. This has two important consequences.
First, it is not usually possible to have two different compatibility
packages in one eCos configuration because they will have conflicting
requirements on the underlying kernel. Second, the semantics of the
kernel's own API are only loosely defined because of the many
configuration options. For example <function>cyg_mutex_lock</function>
will always attempt to lock a mutex, but various configuration options
determine the behaviour when the mutex is already locked and there is
a possibility of priority inversion.
      </para>
      <para>
The optional nature of the kernel package presents some complications
for other code, especially device drivers. Wherever possible a device
driver should work whether or not the kernel is present. However there
are some parts of the system, especially those related to interrupt
handling, which should be implemented differently in multi-threaded
environments containing the eCos kernel and in single-threaded
environments without the kernel. To cope with both scenarios the
common HAL package provides a driver API, with functions such as
<function>cyg_drv_interrupt_attach</function>. When the kernel package
is present these driver API functions map directly on to the
equivalent kernel functions such as
<function>cyg_interrupt_attach</function>, using macros to avoid any
overheads. When the kernel is absent the common HAL package implements
the driver API directly, but this implementation is simpler than the
one in the kernel because it can assume a single-threaded environment. 
      </para>
    </refsect1>

<!-- }}} -->
<!-- {{{ Schedulers                     -->

    <refsect1 id="kernel-overview-schedulers">
      <title>Schedulers</title>
      <para>
When a system involves multiple threads, a scheduler is needed to
determine which thread should currently be running. The eCos kernel
can be configured with one of two schedulers, the bitmap scheduler and
the multi-level queue (MLQ) scheduler. The bitmap scheduler is
somewhat more efficient, but has a number of limitations. Most systems
will instead use the MLQ scheduler. Other schedulers may be added in
the future, either as extensions to the kernel package or in separate
packages.
      </para>
      <para>
Both the bitmap and the MLQ scheduler use a simple numerical priority
to determine which thread should be running. The number of priority
levels is configurable via the option
<varname>CYGNUM_KERNEL_SCHED_PRIORITIES</varname>, but a typical
system will have up to 32 priority levels. Therefore thread priorities
will be in the range 0 to 31, with 0 being the highest priority and 31
the lowest. Usually only the system's idle thread will run at the
lowest priority. Thread priorities are absolute, so the kernel will
only run a lower-priority thread if all higher-priority threads are
currently blocked.
      </para>
      <para>
The bitmap scheduler only allows one thread per priority level, so if
the system is configured with 32 priority levels then it is limited to
only 32 threads &mdash; still enough for many applications. A simple
bitmap can be used to keep track of which threads are currently
runnable. Bitmaps can also be used to keep track of threads waiting on
a mutex or other synchronization primitive. Identifying the
highest-priority runnable or waiting thread involves a simple
operation on the bitmap, and an array index operation can then be used
to get hold of the thread data structure itself. This makes the
bitmap scheduler fast and totally deterministic.
      </para>
      <para>
The MLQ scheduler allows multiple threads to run at the same priority.
This means that there is no limit on the number of threads in the
system, other than the amount of memory available. However operations
such as finding the highest priority runnable thread are a little bit
more expensive than for the bitmap scheduler.
      </para>
      <para>
Optionally the MLQ scheduler supports timeslicing, where the scheduler
automatically switches from one runnable thread to another when some
number of clock ticks have occurred. Timeslicing only comes into play
when there are two runnable threads at the same priority and no higher
priority runnable threads. If timeslicing is disabled then a thread
will not be preempted by another thread of the same priority, and will
continue running until either it explicitly yields the processor or
until it blocks by, for example, waiting on a synchronization
primitive. The configuration options
<varname>CYGSEM_KERNEL_SCHED_TIMESLICE</varname> and
<varname>CYGNUM_KERNEL_SCHED_TIMESLICE_TICKS</varname> control
timeslicing. The bitmap scheduler does not provide timeslicing
support. It only allows one thread per priority level, so it is not
possible to preempt the current thread in favour of another one with
the same priority.
      </para>
      <para>
Another important configuration option that affects the MLQ scheduler
is <varname>CYGIMP_KERNEL_SCHED_SORTED_QUEUES</varname>. This
determines what happens when a thread blocks, for example by waiting
on a semaphore which has no pending events. The default behaviour of
the system is last-in-first-out queuing. For example if several
threads are waiting on a semaphore and an event is posted, the thread
that gets woken up is the last one that called
<function>cyg_semaphore_wait</function>. This allows for a simple and
fast implementation of both the queue and dequeue operations. However
if there are several queued threads with different priorities, it may
not be the highest priority one that gets woken up. In practice this
is rarely a problem: usually there will be at most one thread waiting
on a queue, or when there are several threads they will be of the same
priority. However if the application does require strict priority
queueing then the option
<varname>CYGIMP_KERNEL_SCHED_SORTED_QUEUES</varname> should be
enabled. There are disadvantages: more work is needed whenever a
thread is queued, and the scheduler needs to be locked for this
operation so the system's dispatch latency is worse. If the bitmap
scheduler is used then priority queueing is automatic and does not
involve any penalties.
      </para>
      <para>
Some kernel functionality is currently only supported with the MLQ
scheduler, not the bitmap scheduler. This includes support for SMP
systems, and protection against priority inversion using either mutex
priority ceilings or priority inheritance.
      </para>
    </refsect1>

<!-- }}} -->
<!-- {{{ Synch primitives               -->

    <refsect1 id="kernel-overview-synch-primitives">
      <title>Synchronization Primitives</title>
      <para>
The eCos kernel provides a number of different synchronization
primitives: <link linkend="kernel-mutexes">mutexes</link>,
<link linkend="kernel-condition-variables">condition variables</link>,
<link linkend="kernel-semaphores">counting semaphores</link>,
<link linkend="kernel-mail-boxes">mail boxes</link> and
<link linkend="kernel-flags">event flags</link>.
      </para>
      <para>