📄 kernel-overview.html
字号:
<!-- Copyright (C) 2003 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 is obtained from the copyright holder. --><HTML><HEAD><TITLE>Kernel Overview</TITLE><meta name="MSSmartTagsPreventParsing" content="TRUE"><METANAME="GENERATOR"CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+"><LINKREL="HOME"TITLE="eCos Reference Manual"HREF="ecos-ref.html"><LINKREL="UP"TITLE="The eCos Kernel"HREF="kernel.html"><LINKREL="PREVIOUS"TITLE="The eCos Kernel"HREF="kernel.html"><LINKREL="NEXT"TITLE="SMP Support"HREF="kernel-smp.html"></HEAD><BODYCLASS="REFENTRY"BGCOLOR="#FFFFFF"TEXT="#000000"LINK="#0000FF"VLINK="#840084"ALINK="#0000FF"><DIVCLASS="NAVHEADER"><TABLESUMMARY="Header navigation table"WIDTH="100%"BORDER="0"CELLPADDING="0"CELLSPACING="0"><TR><THCOLSPAN="3"ALIGN="center">eCos Reference Manual</TH></TR><TR><TDWIDTH="10%"ALIGN="left"VALIGN="bottom"><AHREF="kernel.html"ACCESSKEY="P">Prev</A></TD><TDWIDTH="80%"ALIGN="center"VALIGN="bottom"></TD><TDWIDTH="10%"ALIGN="right"VALIGN="bottom"><AHREF="kernel-smp.html"ACCESSKEY="N">Next</A></TD></TR></TABLE><HRALIGN="LEFT"WIDTH="100%"></DIV><H1><ANAME="KERNEL-OVERVIEW">Kernel Overview</H1><DIVCLASS="REFNAMEDIV"><ANAME="AEN56"></A><H2>Name</H2>Kernel -- Overview of the eCos Kernel</DIV><DIVCLASS="REFSECT1"><ANAME="KERNEL-OVERVIEW-DESCRIPTION"></A><H2>Description</H2><P>The kernel is one of the key packages in all of eCos. It provides thecore functionality needed for developing multi-threaded applications: </P><P></P><OLTYPE="1"><LI><P>The ability to create new threads in the system, either during startupor when the system is already running. </P></LI><LI><P>Control over the various threads in the system, for examplemanipulating their priorities. </P></LI><LI><P>A choice of schedulers, determining which thread should currently berunning. </P></LI><LI><P>A range of synchronization primitives, allowing threads to interactand share data safely. </P></LI><LI><P>Integration with the system's support for interrupts and exceptions. </P></LI></OL><P>In some other operating systems the kernel provides additionalfunctionality. For example the kernel may also provide memoryallocation functionality, and device drivers may be part of the kernelas well. This is not the case for eCos. Memory allocation is handledby a separate package. Similary each device driver will typically be aseparate package. Various packages are combined and configured usingthe eCos configuration technology to meet the requirements of theapplication. </P><P>The eCos kernel package is optional. It is possible to writesingle-threaded applications which do not use any kernelfunctionality, for example RedBoot. Typically such applications arebased around a central polling loop, continually checking all devicesand taking appropriate action when I/O occurs. A small amount ofcalculation is possible every iteration, at the cost of an increaseddelay between an I/O event occurring and the polling loop detectingthe event. When the requirements are straightforward it may well beeasier to develop the application using a polling loop, avoiding thecomplexities of multiple threads and synchronization between threads.As requirements get more complicated a multi-threaded solution becomesmore appropriate, requiring the use of the kernel. In fact some of themore advanced packages in eCos, for example the TCP/IP stack, usemulti-threading internally. Therefore if the application uses any ofthose packages then the kernel becomes a required package, not anoptional one. </P><P>The kernel functionality can be used in one of two ways. The kernelprovides its own C API, with functions like<TTCLASS="FUNCTION">cyg_thread_create</TT> and<TTCLASS="FUNCTION">cyg_mutex_lock</TT>. These can be called directly fromapplication code or from other packages. Alternatively there are anumber of packages which provide compatibility with existing API's,for example POSIX threads or µITRON. These allow applicationcode to call standard functions such as<TTCLASS="FUNCTION">pthread_create</TT>, and those functions areimplemented using the basic functionality provided by the eCos kernel.Using compatibility packages in an eCos application can make it mucheasier to reuse code developed in other environments, and to sharecode. </P><P>Although the different compatibility packages have similarrequirements on the underlying kernel, for example the ability tocreate a new thread, there are differences in the exact semantics. Forexample, strict µITRON compliance requires that kerneltimeslicing is disabled. This is achieved largely through theconfiguration technology. The kernel provides a number ofconfiguration options that control the exact semantics that areprovided, and the various compatibility packages require particularsettings for those options. This has two important consequences.First, it is not usually possible to have two different compatibilitypackages in one eCos configuration because they will have conflictingrequirements on the underlying kernel. Second, the semantics of thekernel's own API are only loosely defined because of the manyconfiguration options. For example <TTCLASS="FUNCTION">cyg_mutex_lock</TT>will always attempt to lock a mutex, but various configuration optionsdetermine the behaviour when the mutex is already locked and there isa possibility of priority inversion. </P><P>The optional nature of the kernel package presents some complicationsfor other code, especially device drivers. Wherever possible a devicedriver should work whether or not the kernel is present. However thereare some parts of the system, especially those related to interrupthandling, which should be implemented differently in multi-threadedenvironments containing the eCos kernel and in single-threadedenvironments without the kernel. To cope with both scenarios thecommon HAL package provides a driver API, with functions such as<TTCLASS="FUNCTION">cyg_drv_interrupt_attach</TT>. When the kernel packageis present these driver API functions map directly on to theequivalent kernel functions such as<TTCLASS="FUNCTION">cyg_interrupt_attach</TT>, using macros to avoid anyoverheads. When the kernel is absent the common HAL package implementsthe driver API directly, but this implementation is simpler than theone in the kernel because it can assume a single-threaded environment. </P></DIV><DIVCLASS="REFSECT1"><ANAME="KERNEL-OVERVIEW-SCHEDULERS"></A><H2>Schedulers</H2><P>When a system involves multiple threads, a scheduler is needed todetermine which thread should currently be running. The eCos kernelcan be configured with one of two schedulers, the bitmap scheduler andthe multi-level queue (MLQ) scheduler. The bitmap scheduler issomewhat more efficient, but has a number of limitations. Most systemswill instead use the MLQ scheduler. Other schedulers may be added inthe future, either as extensions to the kernel package or in separatepackages. </P><P>Both the bitmap and the MLQ scheduler use a simple numerical priorityto determine which thread should be running. The number of prioritylevels is configurable via the option<TTCLASS="VARNAME">CYGNUM_KERNEL_SCHED_PRIORITIES</TT>, but a typicalsystem will have up to 32 priority levels. Therefore thread prioritieswill be in the range 0 to 31, with 0 being the highest priority and 31the lowest. Usually only the system's idle thread will run at thelowest priority. Thread priorities are absolute, so the kernel willonly run a lower-priority thread if all higher-priority threads arecurrently blocked. </P><P>The bitmap scheduler only allows one thread per priority level, so ifthe system is configured with 32 priority levels then it is limited toonly 32 threads — still enough for many applications. A simplebitmap can be used to keep track of which threads are currentlyrunnable. Bitmaps can also be used to keep track of threads waiting ona mutex or other synchronization primitive. Identifying thehighest-priority runnable or waiting thread involves a simpleoperation on the bitmap, and an array index operation can then be usedto get hold of the thread data structure itself. This makes thebitmap scheduler fast and totally deterministic. </P><P>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 thesystem, other than the amount of memory available. However operationssuch as finding the highest priority runnable thread are a little bitmore expensive than for the bitmap scheduler. </P><P>Optionally the MLQ scheduler supports timeslicing, where the schedulerautomatically switches from one runnable thread to another when somenumber of clock ticks have occurred. Timeslicing only comes into playwhen there are two runnable threads at the same priority and no higherpriority runnable threads. If timeslicing is disabled then a threadwill not be preempted by another thread of the same priority, and willcontinue running until either it explicitly yields the processor oruntil it blocks by, for example, waiting on a synchronizationprimitive. The configuration options<TTCLASS="VARNAME">CYGSEM_KERNEL_SCHED_TIMESLICE</TT> and<TTCLASS="VARNAME">CYGNUM_KERNEL_SCHED_TIMESLICE_TICKS</TT> controltimeslicing. The bitmap scheduler does not provide timeslicingsupport. It only allows one thread per priority level, so it is notpossible to preempt the current thread in favour of another one withthe same priority. </P><P>Another important configuration option that affects the MLQ scheduleris <TTCLASS="VARNAME">CYGIMP_KERNEL_SCHED_SORTED_QUEUES</TT>. Thisdetermines what happens when a thread blocks, for example by waitingon a semaphore which has no pending events. The default behaviour ofthe system is last-in-first-out queuing. For example if severalthreads are waiting on a semaphore and an event is posted, the threadthat gets woken up is the last one that called<TTCLASS="FUNCTION">cyg_semaphore_wait</TT>. This allows for a simple andfast implementation of both the queue and dequeue operations. Howeverif there are several queued threads with different priorities, it maynot be the highest priority one that gets woken up. In practice thisis rarely a problem: usually there will be at most one thread waitingon a queue, or when there are several threads they will be of the samepriority. However if the application does require strict priorityqueueing then the option<TTCLASS="VARNAME">CYGIMP_KERNEL_SCHED_SORTED_QUEUES</TT> should beenabled. There are disadvantages: more work is needed whenever athread is queued, and the scheduler needs to be locked for thisoperation so the system's dispatch latency is worse. If the bitmapscheduler is used then priority queueing is automatic and does notinvolve any penalties. </P><P>Some kernel functionality is currently only supported with the MLQscheduler, not the bitmap scheduler. This includes support for SMPsystems, and protection against priority inversion using either mutexpriority ceilings or priority inheritance. </P></DIV><DIVCLASS="REFSECT1"><ANAME="KERNEL-OVERVIEW-SYNCH-PRIMITIVES"></A><H2>Synchronization Primitives</H2><P>The eCos kernel provides a number of different synchronizationprimitives: <A⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -