x-glossary.html

vxworks相关论文

<dd><p class="Body"><a name="90332"> </a>Code can guarantee exclusive access to the CPU by locking out interrupts with the <b class="routine"><i class="routine">intLock</i></b><b>(&nbsp;)</b> routine (they are re-enabled with the <b class="routine"><i class="routine">intUnlock</i></b><b>(&nbsp;)</b> routine). Because such an action can be unacceptable for many real-time systems because of the inherent inability to respond to external events for the duration of the lock, it is important to keep interrupt locks short. Note that context switches among tasks can still occur while interrupts are locked, but only as a result of calls made by the task that performed the <b class="routine"><i class="routine">intLock</i></b><b>(&nbsp;)</b>. If a context switch occurs, interrupts are unlocked while any other tasks execute. See also mutual exclusion, preemption locks.</p>
</dl>

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="90340">interrupt service routine (ISR)</a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="90341"> </a>Also known as an <i class="term">interrupt handler</i>, an ISR is a routine that is called when a particular interrupt occurs. For example, when a character is received on a serial port, the associated ISR is called to handle that interrupt. (Handling such an interrupt typically consists of copying the input character to a buffer and clearing the serial device for the next character.)</p>
<dd><p class="Body"><a name="90343"> </a>ISRs run in a special interrupt-level context, which is separate from any task's context.</p>
<dd><p class="Body"><a name="90345"> </a>In a VxWorks application, ISRs that call VxWorks routines are connected to their interrupts with <b class="routine"><i class="routine">intConnect</i></b><b>(&nbsp;)</b>. Note that there are some restrictions on what ISRs can do: the primary restriction is that they must not invoke functions that might cause blocking (pending) of the caller; see the <i class="title">VxWorks Programmer's Guide</i> for details.</p>
</dl>

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="90349">intertask communication facilities</a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="90351"> </a>Intertask communication facilities allow tasks to synchronize and communicate so that they can coordinate their activity. The VxWorks intertask communication facilities include semaphores, message queues, pipes, sockets, and signals.</p>
</dl>

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="90359">intrusion</a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="90361"> </a>In WindView, intrusion refers to the amount of overhead added to the target system by including instrumented code and starting event logging.</p>
</dl>

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="90366">I/O system</a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="90367"> </a>The VxWorks I/O system provides uniform device-independent access to many kinds of devices and a <i class="acronym_lc">stdio</i> buffered I/O package that includes UNIX-compatible routines. VxWorks also includes device drivers for serial communications lines, disks, pipes, and network devices, and allows dynamic installation and removal of many drivers without rebooting the system.</p>
</dl>

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="90370">Legend </a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="90373"> </a>This WindView window shows what each event icon and state stipple represents. It can be displayed with the <b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans">Legend</font></b> command in the event pop-up menu or by selecting <b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans">Legend </font></b>in the main <b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans">Help&gt;WindView Help</font></b> menu.  </p>
</dl>

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="90379">locked state</a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="90380"> </a>The VxWorks scheduler can be explicitly disabled and enabled on a per-task basis with the <b class="routine"><i class="routine">taskLock</i></b><b>(&nbsp;)</b> and <b class="routine"><i class="routine">taskUnlock</i></b><b>(&nbsp;)</b> routines. When preemption locking is enabled (shown by the <img class="figure" border="0" src="images/x-glossary9.gif">
 stipple), priority-based preemption does not occur unless the task explicitly blocks or suspends. When the preemption-locked task unblocks and begins running again, preemption is again disabled. Note that multiple nested calls to <b class="routine"><i class="routine">taskLock</i></b><b>(&nbsp;)</b> may be made; each one must be explicitly unlocked before normal priority-based scheduling is enabled. In addition, note that preemption-locked tasks are still subject to interrupts.</p>
</dl>

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="90392">logging level</a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="90396"> </a>See event-logging level.</p>
</dl>

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="90399">main window</a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="90400"> </a>In the context of the <i class="title"><a href="./index.html">WindView User's Guide</a></i>, the main window means the window which contains the WindView toolbar and the <b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans">Control</font></b> window. It also contains the menu referred to as the main menu. On a Windows host, this is the Tornado window. On a UNIX host, this is a separate window that opens when you launch WindView. For more information, see <a href="c-start2.html#92851">Figure&nbsp;2-1</a>. </p>
</dl>

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="90406">message logging</a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="90407"> </a>VxWorks includes a message logging facility that allows error or status messages to be sent to a logging task. The logging task then formats and outputs the messages to a system-wide logging device, such as the system console, disk, or specific memory area. The message logging facility can be used from interrupt level or task level. For details, see the manual entry for <b class="library">logLib</b> in the <i class="title">VxWorks Reference Manual</i>.</p>
</dl>

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="90412">message queue</a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="90413"> </a>VxWorks message queues allow a variable number of messages, each of variable length, to be queued in FIFO or priority order. Any task or ISR can send messages to a message queue, and any task can receive messages from a message queue. Multiple tasks can send to and receive from the same message queue. Full-duplex communication between two tasks generally requires two message queues, one for each direction.</p>
<dd><p class="Body"><a name="90416"> </a>When a task attempts to receive a message, if a message is in the message queue, the task gets the message and continues executing. If no messages are available, the task pends on the message queue until one becomes available or until the specified timeout expires. Tasks can pend on the message queue in FIFO or priority order.</p>
<dd><p class="Body"><a name="90420"> </a>When a task (or an ISR) sends a message, if there are no tasks waiting for a message, the sender continues executing. If there are tasks waiting on the message queue, the first one makes a transition to the ready state. A context switch occurs if the newly readied task is of higher priority than the task that sent the message. </p>
</dl>

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="90426">multitasking</a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="90427"> </a>Multitasking provides the fundamental mechanism for an application to control and react to multiple, discrete real-world events. Multitasking creates the appearance of many threads of execution running concurrently, but actually, the operating system interleaves the threads' execution on the basis of a scheduling algorithm. Multitasking also permits much more flexible and modular application designs than does a single-threaded model. See also preemptive priority scheduling, round-robin scheduling, task.</p>
</dl>

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="90434">mutual exclusion</a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="90436"> </a>Mutual exclusion is the restriction of access to a particular resource (such as a data structure in memory) to only one task at a time. If mutual exclusion is not provided to certain resources, task execution order can affect the integrity of the resource, leading to race conditions. For example, if a task is writing to memory and is interrupted before it is finished, another task may write to the same area, corrupting memory. See also interrupt lock, preemption lock, semaphore.</p>
</dl>

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="90444">mutual exclusion semaphore</a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="90446"> </a>A mutual exclusion ("mutex") semaphore is a specialized binary semaphore designed to address issues inherent in mutual exclusion, including priority inversion, deletion safety, and recursive access to resources. A mutex semaphore's behavior is identical to a binary semaphore's, with the following exceptions: it can be used only for mutual exclusion (not for synchronization); it can be given only by the task that took it; it may not be given from interrupt-level code; the <b class="routine"><i class="routine">semFlush</i></b><b>(&nbsp;)</b> operation is illegal. See also counting semaphore.</p>
</dl>

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="90454">nonexistent state</a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="90456"> </a>A task is in the nonexistent state before it is spawned with the <b class="routine"><i class="routine">taskSpawn</i></b><b>(&nbsp;)</b> or <b class="routine"><i class="routine">taskInit</i></b><b>(&nbsp;)</b> routine. There is no stipple for this state, but users can define one if they wish to track it. See also task state, task state transition.</p>
</dl>

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="90462">object</a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="93834"> </a>In a VxWorks system, objects include tasks, semaphores, watchdog timers, and message queues. The objects that can be instrumented are tasks, semaphores, watchdog timers, message queues, signals, and memory calls. For all objects except signals, you can enable instrumentation programmatically for a particular object, such as task <b class="task">t1</b>, or a group of objects, such as all semaphores. You can instrument combinations of objects: for example, you might be interested in how task <b class="task">t1</b>, all semaphores, and message queues <b class="task">mq1</b> and <b class="task">mq2</b> interact. For signals, you cannot specify particular signals to instrument: either all signals are instrumented, or none of them are. See also additional instrumentation event-logging level.</p>
</dl>

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="90491">page</a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="90494"> </a>In a view graph, a page is the width of the current time interval; that is, the portion of the event log currently displayed in the view graph.</p>
</dl>

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="90497">pended state</a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="90503"> </a>A task is in the pended state (shown by the <img class="figure" border="0" src="images/x-glossary10.gif">
 stipple) if it attempted to obtain an object but the object was not available; for example, if it made a call to the <b class="routine"><i class="routine">semTake</i></b><b>(&nbsp;)</b> or <b class="routine"><i class="routine">msgQReceive</i></b><b>(&nbsp;)</b> routine but the semaphore or a message was not available. A task in this state is also known as a blocked task. See also task state, task state transition.</p>
</dl>

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="90509">pipe</a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="90511"> </a>Pipes provide an alternative interface to the message queue facility: the interaction occurs through the VxWorks I/O system. Pipes are named virtual I/O devices managed by the <b class="library">pipeDrv</b> driver. Because pipes are built on top of message queues, pipes and pipe operations are displayed in WindView as message queues and message queue operations. </p>
</dl>

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="90515">post-mortem mode</a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="90516"> </a>In this event upload mode, you must configure WindView to locate the WindView buffer in memory that is not that is not overwritten if the target reboots. The event buffer is written to this memory and overwritten cyclically when it is filled. The buffer contents are uploaded when you request it, and are preserved in the event of a system failure.</p>
</dl>

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="90520">preemption</a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="90523"> </a>If a task becomes ready to execute and it has a higher priority than the currently executing task, the "new" task preempts the current task. That is, the operating system immediately saves the current task's context and switches to the context of the higher-priority task. See also task state transition.</p>
</dl>

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="90529">preemption lock</a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="90531"> </a>See locked state.</p>
</dl>

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="90534">preemptive priority scheduling</a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="90537"> </a>In VxWorks, each task is assigned a priority, and the kernel ensures that the CPU is allocated to the highest-priority ready task. The scheduling is preemptive in that if a task of a higher priority than the executing task becomes ready, the kernel preempts the current task and switches to the higher-priority task. See also context switch, task state transition.</p>
</dl>

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="90545">preserved memory region </a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="90546"> </a>A region of memory that is not overwritten during a warm reboot. It is used to store the event buffer in <i class="textVariable">post-mortem mode</i> so that it can be uploaded after reboot. </p>
</dl>