Application code is any user-supplied code operating under IRIX.

See event collection.

See context switch, current context, process context.

A context switch is an operation performed by a multitasking operating system in which the current thread of execution is switched for another. Examples of this are one process preempting another, a process delaying itself or pending on a resource (making the processor available for another thread of execution), or a process being interrupted by an ISR. See also current context, process context.

This WindView event logging mode shows the current context and where it is switched. The current context is shown as a solid horizontal line. When a context switch occurs, a dotted vertical line connects the previous context's line to the current context's line.

CPU starvation refers to a process that is “starving” for CPU time. In other words, the process never gets to run, because it is never scheduled by the IRIX scheduler.

In real-time systems, the term “current context” usually refers to the currently executing process and information needed to restore the process's state, such as the state of the processor registers, operating system control information, and the stack. For WindView, the meaning has been extended to include ISRs and the kernel's idle loop. (See process context.)

Two or more processes are in deadlock when they are keeping each other from running, for example, when taskA is pending on a semaphore waiting to be unblocked by taskB, but taskB is pending on another semaphore waiting to be unblocked by taskA. This is a common bug in real-time systems, easily diagnosed with WindView.

In WindView, an event is any action undertaken by a process or an ISR that can affect the state of the real-time system. Examples of events are process spawns and deletions, timer expirations, and interrupts. IRIX has been instrumented to log this event information. See also event logging, WindView logging mode, instrumented code, user-generated events.

The event buffer is an area of memory in IRIX that temporarily holds the event data before it is processed by WindView, when you are using the GUI to collect event data.

This is information that is logged to the WindView event buffer.

This is the process of starting event logging under IRIX, and then capturing the event data to the event buffer.

Various icons are displayed in the View Graph that correspond to events. For information on what each event icon represents, see the Legend window. To learn specific information on a particular instance of an icon, use the Event Inspector window.

The Event Inspector window displays information about the event: its name, its timestamp, the context in which it occurred, and any other event information that has been logged. Use the middle mouse button to select any event icon in the View Graph and drag it into the Event Inspector window to display this information.

An event log is a finite collection of event data that resides in shared memory. See also processed event log, raw event log.

This is the target activity of writing information about events to the WindView event buffer as the events occur. You start event logging with rtmon_client or with the Start button in the WindView Target window.

This is the host port over which the WindView GUI listens for connections from the target; specifically, where WindView listens for event data. The default event port number is 6164.

An exception is an error in program code or data, such as an illegal instruction, a bus error, or a divide-by-zero error.

A process or other context is in the executing state if it has control of the processor. For a process to be in the executing state, there must be no interrupts to service. ISRs are in the executing state after their interrupt has been acknowledged by the kernel; if there is more than one ISR to service, the one at the processor's highest interrupt level executes. The idle loop is in the executing state when there are no processes to run and no ISRs to service. See also current context, process state, process state transition.

See thread of execution.

Graphical user interface: the portion of WindView running on the system or X terminal with which you view event data.

When there are no processes ready to execute and no interrupts to service, the kernel enters its idle loop. In this “state,” the kernel services interrupts and continually checks to see if a process is ready to run. Analyzing the amount of time your application is idle can help you fine-tune the application: too much time in the idle loop may mean the application is not using the processor efficiently; too little time may mean that the application is interrupted too often to run effectively.

Instrumented code is software that has been modified to provide information about its own operation. In the case of IRIX, this information is event data that contains a record of the significant moments in the flow of control within the operating system. Application code can be instrumented with the rtmon_log_user_tstamp() routine; see user-generated events.

An interrupt is a signal from hardware that lets the processor know that something has occurred in the external world. For example, the processor may receive an interrupt when a clock tick occurs or when a character is received on a serial port. See also Interrupt Service Routine (ISR).

See Interrupt Service Routine (ISR).

Interrupt latency is the amount of time during which the processor's ability to respond to interrupts is inhibited. Both the hardware and software architecture contribute to interrupt latency. Hardware influences on interrupt latency include such things as prioritizing interrupt requests and preventing interrupt handling until the completion of lengthy instructions. Software influences stem from mode switches, context switches, and kernel preemption latencies.

Also known as an “interrupt handler,” 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.)

ISRs run in a special interrupt-level context, which is separate from any process's context.

Interprocess communication mechanisms allow processes to synchronize and communicate so that they can coordinate their activity. The IRIX interprocess communication mechanisms include semaphores, message queues, pipes, sockets, and signals.

In WindView, intrusion refers to the amount of overhead added to the target IRIX system by including instrumented code and starting event logging.

This WindView window shows what each event icon and state stipple represents. It can be displayed with the Legend Window icon on the View Graph.

An IRIX non-degrading priority is not affected by normal priority aging schemes within the kernel. Priorities between NDPHIMAX and NDPHIMIN (kernel systune parameters, by default, 30-39) are priorities higher than all other processes subject to normal scheduling and are therefore referred to as real-time priorities.

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.

A process is in the pended state if it attempted to obtain an object or resource but the object or resource was not available; for example, if it made a call to obtain a semaphore, but the semaphore was not available. A process in this state is also known as a blocked process. See also process state, process state transition.

If a process becomes ready to execute and it has a higher priority than the currently executing process, the “new” process preempts the current process. That is, the operating system saves the current process's context and switches to the context of the higher-priority process. See also process state transition.

In IRIX, each process is assigned a priority, and the kernel ensures that the processor is allocated to the highest-priority ready process. The scheduling is preemptive in that if a process of a higher priority than the executing process becomes ready, the kernel preempts the current process and switches to the higher-priority process. See also context switch, process state transition.

The standard IRIX scheduler provides 256 process priority levels, numbered 0 (highest) through 255 (lowest). Processes are assigned a priority when created; however, while executing, a process may change its priority using schedctl(2).

A process is an independent program in a IRIX application that has its own job to perform, such as the management of a robot arm. Each process has its own context, which is the processor environment and system resources the process “sees” each time it is scheduled to run by the kernel. On a context switch, a process's context is saved. Processes can communicate and synchronize with each other through interprocess communication mechanisms (IPCs).

A process consists of an address space containing the program text and data, and a number of process attributes managed by the IRIX kernel. A few examples of process attributes are: a unique process ID number; machine register contents, representing the current instruction and stack level as well as working data; UNIX user and group identities; current working directory for file searches; and signal-handling status.

This is an event log that has been imported into WindView, either directly from the target or with the “Analyze” command if you are using rtmon_client to collect event data. You can save processed event logs for later study with the “Save” command, and then import them again with the “Open” command. Files that contain processed event logs have the .wv extension. Files that contain unprocessed, “raw” event logs have the .wvr extension. See also raw event log.

In IRIX applications, process states include the following: executing, ready, and suspended.

This term refers to the action of a process exiting from one state and entering into another (this is different from context switch, which refers to a change in the controlling context within the processor). A process state transition may or may not result in a context switch, depending on the states of other processes in the system when the process in question makes its transition between states.

When the outcome of a program is erroneously determined by the first of two or more events (for example, is a particular variable read first, or updated first?), it is said that a race condition exists. This kind of problem can often be solved by using mutual exclusion semaphores to synchronize the process' use of the resource.

This is the format of an event log that has been collected with the rtmon-client tool. Files that contain raw event logs have the .wvr extension. Files that contain processed event logs have the .wv extension. See also processed event log.

A process is in the ready state if it is not waiting for any resource other than the processor; that is, it is placed on the run queue, and has not yet executed. See also process state, process state transition.

This is a general term referring to the “system” formed by the IRIX operating system, your real-time application, and the hardware. This system must respond to external events within prescribed time limits.

A system object for which a process may contend with other processes. Examples of resources are memory pool data structures, message queues, and semaphores. If the resource is not available, a process contending for that resource makes a transition to the pended state. See also process state transition.

See executing state.

See preemptive priority scheduling.

A semaphore is an IRIX system object that provides mutual exclusion of shared resources and interprocess synchronization.

IRIX supports UNIX BSD-style signals as well as POSIX-compatible signals for asynchronous transfer of control within a process, based on hardware or software exceptions.

The IRIX software signaling facility provides a set of 31 distinct signals. A process can specify a signal handler routine to take appropriate action when the associated signal is received. When signal handling is complete, normal process execution resumes, unless the signal corresponds to an exception.

A socket is a UNIX BSD 4.3-compatible interface for transferring byte streams between processes, regardless of location in a networked application.

See process state.

The state stipples are the horizontal lines on the View Graph that show the current state of each process in the real-time system. For information on what each state stipple represents, see the Legend window.

A sub-time interval is the space between two time instants. Choose the first time instant with the left mouse button, then choose the second instant in the same way. Two vertical lines are displayed in the event log, and details about the sub-interval are displayed in the Detailed Time Information field. It can be useful to know the amount of time that has occurred between events, or to select a sub-interval that you zoom in on with the Zoom In icon.

In an IRIX system, this term refers to any code that is not application code. It includes the IRIX kernel, IRIX system libraries, device drivers, and so on.

Silicon Graphics systems include a system clock, which continually runs and emits a periodic interrupt known as a tick. IRIX uses the system clock to manage process scheduling, process delays, and so on.

The target is the system where WindView is collecting events.

Tool command language; see the Tcl Guide for information.

The sequence of instructions that a particular process (such as a process or ISR) executes to carry out its job.

A time instant is a single point in time, selected with a click of the left mouse button in the View Graph. A vertical line appears in the event log, and details about the time instant are displayed in the Detailed Time Information field.

The time interval is the portion of the event log currently displayed in the View Graph. If timestamping is enabled, the time interval is an amount of time. If sequential event display is used, the time interval is a number of events.

Each process has a guaranteed time slice, which is the amount of time it is normally allowed to execute without being preempted. By default, the time slice is 3 ticks, or 30 ms. Often, a typical process will be blocked for I/O before reaching the end of its time slice.

At the end of a time slice, the kernel chooses which process to run next on the same processor, based on process priorities. When runnable processes have the same priority, the kernel runs them in turn.

When the instrumented IRIX kernel is run with the accompanying real-time monitoring daemon, certain logged events are tagged with a high-resolution timestamp. The events are displayed in the View Graph along a timeline showing when they occurred based on their timestamps.

See process state transition.

A process that is pended (blocked) on a resource is unblocked when the resource becomes available, its timeout expires, or it is explicitly unblocked.

A user-defined event icon is an event icon that has been defined to appear when a user event occurs; see user-generated events. If you have not created your own icons, the defaultUser icon appears by default, preceded by the event number. User event numbers are from 1-20000, numbers above 20000 are reserved for kernel events.

When event logging has been started, you can cause WindView to show application-specific events. This is done by inserting calls to rtmon_log_user_tstamp into application source code.

See GUI.

This is the WindView window that lets you examine event data logged about your real-time system. In this window, time is represented on the horizontal axis, while the current system's contexts are represented on the vertical axis:

Starting from the top of the screen, the interrupts used in the system are listed first. The interrupts are followed by the processes, with the process first recording events listed first, followed by others as they record events.

The last context shown is the processor's idle loop.