《CS：APP》 chapter 8 Exceptional Control Flow 注意事项

Exceptional Control Flow

The program counter assumes a sequence of values

                                 a0,a1,...,an−1

where each ak is the address of some corresponding instruction Ik. Each transition from ak to ak +1 is called a control transfer. A sequence of such control transfers is called the
flow of control,orcontrol flowof the processor.

Typically, abrupt changes to this smooth flow, where Ik +1 is not adjacent to Ik, are caused by familiar program instructions such as jumps, calls, and returns.

In general, we refer to these abrupt changes asexceptional control flow (ECF).   At the operating systems level, the kernel transfers control from one user process to another
via context switches.

8.1 Exceptions

Exceptions are a form of exceptional control flow that are implemented partly by the hardware and partly by the operating system.

An
exception is an abrupt change in the control flow in response to some change in the processor’s state.

The change in state is known as anevent.

In any case, when the processor detects that the event has occurred, it makes an indirect procedure call (the exception), through a jump table called anexception table, to
an operating system subroutine (the exception handler ) that is specifically designed to process this particular kind of event.

When the exception handler finishes processing, one of three things happens, depending on the type of event that caused the exception:

1. The handler returns control to the current instruction Icurr, the instruction that was executing when the event occurred.

2. The handler returns control to Inext, the instruction that would have executed next had the exception not occurred.

3. The handler aborts the interrupted program

exception 和 procedure call 的异同点

• As with a procedure call, the processor pushes a return address on the stack before branching to the handler. However, depending on the class of exception, the return address is either the current instruction (the
  instruction that was executing when the event occurred) or the next instruction (the instruc-tion that would have executed after the current instruction had the event not occurred).
• The processor also pushes some additional processor state onto the stack that will be necessary to restart the interrupted program when the handler returns. For example, an IA32 system pushes the EFLAGS register
  containing, among other things, the current condition codes, onto the stack.
• If control is being transferred from a user program to the kernel, all of these items are pushed onto the kernel’s stack rather than onto the user’s stack.
• Exception handlers run inkernel mode(Section 8.2.4), which means they have complete access to all system resources.

8.1.2 Classes of Exceptions

Exceptions can be divided into four classes:interrupts, traps, faults , and aborts .

The table in Figure 8.4 summarizes the attributes of these classes.

Interrupts

Interrupts occur asynchronously as a result of signals from I/O devices that are external to the processor. Hardware interrupts are asynchronous in the sense that they are not caused by the execution of any particular
instruction. Exception handlers for hardware interrupts are often called interrupt handlers .

Traps and System Calls

Traps are intentional exceptions that occur as a result of executing an instruction. Like interrupt handlers, trap handlers return control to the next instruction. The most important use of traps is to provide
a procedure-like interface between user programs and the kernel known as a system call

Faults

Faults result from error conditions that a handler might be able to correct. When a fault occurs, the processor transfers control to the fault handler. If the handler is able to correct the error condition, it
returns control to the faulting instruction, thereby reexecuting it. Otherwise, the handler returns to an abort routine in the kernel that terminates the application program that caused the fault.

Aborts

Aborts result from unrecoverable fatal errors, typically hardware errors such as parity errors that occur when DRAM or SRAM bits are corrupted. Abort handlers never return control to the application program. As
shown in Figure 8.8, the handler returns control to an abort routine that terminates the application program.

Aside A note on terminology

The terminology for the various classes of exceptions varies from system to system. Processor macroar-chitecture specifications often distinguish between asynchronous “interrupts” and synchronous “exceptions,”  we use the word “exception” as
the general term and distinguish between asynchronous exceptions (interrupts) and synchronous ex-ceptions (traps, faults, and aborts) only when it is appropriate.  You should be aware that some manufacturers’ manuals use the word “exception” to refer only
to those changes in control flow caused by synchronous events.

8.2 Processes

Each time a user runs a program by typing the name of an executable object file to the shell, the shell creates a new process and then runs the executable object file in the context of this new process.

An independentlogical control flow that provides the illusion that our pro-gram has exclusive use of the processor.

A private address space that provides the illusion that our program has exclu-sive use of the memory system.

关于进程的概念，这里能够看看 《MOS》的第二章，额。。还没做笔记，但愿这个月能够搞定补上啊。。。。

8.2.1 Logical Control Flow

This sequence of PC values is known as a logical control flow , or simply logical flow .

The key point in Figure 8.12 is that processes take turns using the processor. Each process executes a portion of its flow and then ispreempted (temporarily suspended) while other processes take their turns.

8.2.2 Concurrent Flows

A logical flow whose execution overlaps in time with another flow is called a concurrent flow , and the two flows are said to run concurrently.

More precisely, flows X and Y are concurrent with respect to each other if and only if X begins after Y begins and before Y finishes, or Y begins after X begins and before X finishes. For example, in Figure 8.12,
processes A and B run concurrently, as do A and C. On the other hand, B and C do not run concurrently, because the last instruction of B executes before the first instruction of C.

The general phenomenon of multiple flows executing concurrently is known as concurrency.

Notice that the idea of concurrent flows is independent of the number of processor cores or computers that the flows are running on. If two flows overlap in time, then they are concurrent, even if they are running
on the same processor. However, we will sometimes find it useful to identify a proper subset of concurrent flows known as parallel flows . If two flows are running concurrently on different processor cores or computers, then we say that they are parallel flows
, that they are running in parallel , and have parallel execution.

8.2.3 Private Address Space

On a machine withn-bit addresses, the address space is the set of 2^n possible addresses, 0, 1,..., (2 ^n) − 1. A process provides each program with its ownprivate address space. This space is private in the sense that
a byte of memory associated with a particular address in the space cannot in general be read or written by any other process.

8.2.4 User and Kernel Modes

When the mode bit is set, the process is running in kernel mode (sometimes called supervisor mode). A process running in kernel mode can execute any instruction in the instruction set and access any memory location
in the system. When the mode bit is not set, the process is running inuser mode.

User programs must instead access kernel code and data indirectly via the system call interface.

8.2.5 Context Switches

The kernel maintains a context for each process. The context is the state that the kernel needs to restart a preempted process.

At certain points during the execution of a process, the kernel can decide to preempt the current process and restart a previously preempted process. This decision is known as scheduling , and is handled by code
in the kernel called the scheduler.

A context switch can occur while the kernel is executing a system call on behalf of the user. If the system call blocks because it is waiting for some event to occur, then the kernel can put the current process
to sleep and switch to another process.

8.4 Process Control

进程控制不去看APUE天理不容啊！

！

！

眼下为止关于APUE全部的笔记：

APUE的Process control

http://blog.csdn.net/cinmyheart/article/details/22298649

8.5 Signals

信号嘛，还是去看APUE

只是这里讲的非常好：

The transfer of a signal to a destination process occurs in two distinct steps:



                Sending a signal.The kernel sends (delivers) a signal to a destination process by updating some state in the context of the destination process. The signal is delivered for one of two reasons: (1) The kernel
has detected a system event such as a divide-by-zero error or the termination of a child process. (2) A process has invoked the killfunction (discussed in the next section) to explicitly request the kernel to send a signal to the destination process. A process
can send a signal to itself.



                 Receiving a signal. A destination processreceives a signal when it is forced by the kernel to react in some way to the delivery of the signal. The process can either ignore the signal, terminate, or catchthe
signal by executing a user-level function called a signal handler. Figure 8.26 shows the basic idea of a handler catching a signal.

A signal that has been sent but not yet received is called apending signal.At any point in time, there can be at most one pending signal of a particular type. If a process has a pending
signal of typek , then any subsequent signals of type k sent to that process are not queued; they are simply discarded.

A pending signal is received at most once. For each process, the kernel main-tains the set of pending signals in the pending bit vector, and the set of blocked signals in the blocked
bit vector. The kernel sets bit k in pending whenever a sig-nal of type k is delivered and clears bit k in pending whenever a signal of typek is received.

8.7 Tools for Manipulating Processes

Linux systems provide a number of useful tools for monitoring and manipulating processes:

strace : Prints a trace of each system call invoked by a running program and its children. A fascinating tool for the curious student. Compile your
program with -static to get a cleaner trace without a lot of output related

to shared libraries.

ps : Lists processes (including zombies) currently in the system.

top: Prints information about the resource usage of current processes.

pmap: Displays the memory map of a process.

/proc : A virtual filesystem that exports the contents of numerous kernel data structures in an ASCII text form that can be read by user programs. For example,
type “ cat/proc/loadavg ” to see the current load average on

your Linux system.

衡山下的老巷子

版权声明：本文博主原创文章。博客，未经同意不得转载。