Linux programming signal (I): interrupt and Signal

1. What is interruption? 1. Basic concepts of Interruption

Interruptions refer to any unusual or unexpected emergency handling event in the system during the execution of a computer, this allows the CPU to temporarily interrupt the program being executed and switch to the corresponding event processing program. After the process is completed, the system returns the process of executing the new process that was originally interrupted or scheduled. An event that causes an interruption is called an interruption source. The interrupt processing signal sent from the interrupt source to the CPU is called the interrupt request, and the CPU sends the interrupt request to the corresponding event processing program, which is called the interrupt response.

In some cases, although the interrupt source and interrupt request are generated, the interrupt allowed bit of the processor status word PSW inside the CPU has been cleared, so that the CPU cannot respond to the interrupt. In this case, interruption is prohibited. After a CPU interruption is disabled, you can receive the interruption only when the allowed bit of the PSW is reset. The disconnection prohibition is also called an on-premises disconnection. the settings of the allowable bit of the PSW interrupt are also called an on-premises interruption. The open and Guanzhong disconnections are designed to ensure the atomicity of a program.

Another common concept is interrupt shielding. Interruption blocking means that after a request is interrupted, the system selectively blocks one part of the interruption and allows another part of the interruption to be responded. However, some interrupt requests cannot be blocked or even prohibited. That is to say, these interrupts have the highest priority. Once these interrupt requests are initiated, the CPU must respond immediately. For example, the interruption caused by power loss is not prohibited or unblocked.

2. Classification and priority of interruptions

According to the requirements of the system for interrupt processing, the operating system generally classifies the interruptions and assigns different processing priorities to different interruptions, so that when different interruptions occur at the same time, sort priorities.

Based on the conditions generated by the interrupt source, the interrupt can be divided into the external interrupt and the internal interrupt. External interruptions refer to external interruptions from the processor and memory, including I/O interruptions from the I/0 device and external signal interruptions (for example, user keypress ESC key ). Clock interruption caused by various timers and debugging interruption caused by breakpoints set in the debugging program. External interruptions are generally called interruptions in a narrow sense.

Internal interruption refers to the internal interruption of the processor and memory. An internal interruption is generally called a trap or exception. It includes various errors caused by program operations, such as Invalid Address, verification error, page failure, access control error, arithmetic operation overflow, illegal data format, division to zero, illegal command, user program execution privilege command, time slice interruption in time-sharing system and switching from user State to core State are examples of traps.

In order to handle response interruptions according to the priorities of the interrupt source, the operating system assigns different priorities to different interruptions. For example, in UNIX systems, the priority of external interruptions and traps is divided into eight levels. To prevent interruptions or block interruptions, the CPU processor status word PSW also has a corresponding priority. If the priority of the interrupt source is higher than that of the PSW, the CPU responds to the request from the interrupt source. Otherwise, the CPU shields the interrupt request from the interrupt source.

The priority of each interrupt source is given during system design and fixed during system operation. The processor priority is dynamically set by the system program based on the execution status.

In addition to differences in priority settings, there are also major differences between interruptions and traps:

Traps are usually caused by the current commands being executed by the processor, while interruptions are caused by the source of interruptions unrelated to the current command. The services provided by the trap Handler are used by the current process, while the services provided by the interrupt handler are not for the current process.

After the CPU executes a command, it responds to the interruption before the next command starts, and can also respond to the trap in the execution of a command. For example, if an invalid command is executed, the CPU can still process it even though it cannot be executed.

3. Soft Interrupt

The concept of Soft Interrupt mainly comes from UNIX systems. Soft interruptions correspond to hard interruptions. Hardware-based interrupt requests are called hard interruptions. Soft Interrupt is not a communication method that simulates hard interrupt between communication processes. After the interrupt source sends a soft interrupt signal, the CPU or receiving process can interrupt the processing at the appropriate time or complete the function corresponding to the soft interrupt signal. Here, the "proper time" indicates that the process receiving Soft Interrupt signals must wait until the receiving process gets the processor. If the receiving process occupies the processor, the receiving process immediately switches to the corresponding function after receiving the Soft Interrupt signal.

4. interrupt handling process

Once the CPU response is interrupted, the system starts to interrupt the handler. The following describes the interrupt handling process in detail:

1) check whether the response interruption conditions are met by the CPU. The CPU response interruption condition is: there are interrupt requests from the interrupt source, and the CPU can be interrupted. If the interrupt response condition is not met, the Interrupt Processing fails.

2) If the CPU response is interrupted, the CPU is disconnected, so that it cannot respond to the interruption again.

3) Save the interrupted process site. In order to make the process return to a breakpoint correctly after the interrupt processing is completed, the system must save the values of the current processor status word PSW and program counter PC. These values are generally stored in a specific stack or hardware register.

4) analyze the cause of the interruption and call the Interrupt Processing subroutine. When multiple interrupt requests occur at the same time, process the interrupt requests sent from the highest priority interrupt source. In the system, different interrupt processing subprograms (trap processing subprograms) are usually compiled for different interrupt sources for convenience of processing ). The population addresses of these subprograms (or the population addresses of trap commands) are stored in specific units in the memory. In addition, different interrupt sources correspond to different processor status words PSW. These different psws are placed in the corresponding memory units, which together with the population address of the interrupt processing subroutine constitute the interrupt vector. Apparently, based on the types of interruptions or traps, the system can quickly find the priority of the interrupt response, the entry address of the interrupt processing subroutine (or trap command), and the corresponding PSW from the interrupt vector table.

5) execute the Interrupt Processing subroutine. For traps, in some systems, a soft interrupt signal is sent to the current execution process through the trap command and the corresponding processing subroutine is called for execution.

6) Exit the interrupt and resume the on-site or scheduling of the interrupted process to occupy the processor.

7) the CPU continues to run when the service is interrupted.

5. device management procedures and interrupt Methods

The contradiction between the high speed of the processor and the low speed of the input and output devices is an important issue for device management. To improve overall efficiency, reduce the CPU wait time in the direct control mode of the program, and improve the parallel work efficiency of the system, the interrupt mode is used to control the data transmission between the input and output devices and the memory and the CPU, is necessary.

In terms of hardware structure, This method requires that there is an interrupt request line between the CPU and the input/output device (or controller, in addition, the control status register of the input/output device controller has the corresponding interrupt permitted bits.

2. What is a signal? 1. Signal and Signal Source

Signal nature

A signal is a simulation of the interrupt mechanism at the software level. In principle, a process receives a signal and the processor receives an interrupt request. The signal is asynchronous. A process does not have to wait for the signal to arrive through any operation. In fact, the process does not know when the signal will arrive.

Signals are the only asynchronous communication mechanism in the inter-process communication mechanism. They can be seen as asynchronous notifications to notify the processes that receive signals of what happened. After POSIX real-time expansion, the signal mechanism is more powerful. In addition to the basic notification function, it can also transmit additional information.

Signal Source

There are two sources for the occurrence of signal events: hardware sources (for example, we press the keyboard or other hardware faults); software sources, the most common system function for sending signals is kill, raise, alarm, setimer, and sigqueue functions. The software source also includes some illegal operations.

2. Signal types

Signals can be classified from two different classification perspectives: (1) Reliability: reliable and unreliable signals; (2) Relationship with time: Real-time and non-real-time signals. All signals supported by the system are listed in Appendix 1 of "inter-process communication in Linux environment (I): pipelines and famous pipelines.

(1) Reliable and unreliable Signals

"Unreliable signal"

The Linux signal mechanism is basically inherited from the Unix system. In early Unix systems, the signal mechanism was relatively simple and original, and some problems were exposed in practice. Therefore, the signals built on the early mechanism were called "unreliable signals ", signals smaller than SIGRTMIN (in Red hat 7.2, SIGRTMIN = 32, SIGRTMAX = 63) are unreliable signals. This is the source of "unreliable signal. Its main problems are:

• Each time a process processes a signal, it sets the response to the signal as the default action. In some cases, it may lead to incorrect signal processing. Therefore, if you do not want such an operation, you need to call signal () again at the end of the signal processing function (), reinstall the signal.
• The signal may be lost, which will be detailed later.
  Therefore, the unreliable signal in early unix mainly refers to the possibility that the process may make a wrong response to the signal and the possible loss of the signal.

Linux supports unreliable signals, but makes improvements to unreliable signal machines: after the signal processing function is called, you do not have to call the signal installation function again (the signal installation function is implemented in a reliable mechanism ). Therefore, the unreliable signals in Linux mainly refer to the possible loss of signals.

"Reliable signal"

With the development of time, practice has proved that it is necessary to improve and expand the original signal mechanism. Therefore, various later Unix versions were studied in this respect to achieve "reliable signals ". Because the originally defined signals have been used in many applications and cannot be modified, we have to add some new signals and define them as reliable signals at the beginning. These signals support queuing, no loss. At the same time, a new version of signal sending and installation has also emerged: the signal sending function sigqueue () and the signal installation function sigaction (). POSIX.4 standardizes reliable signal machines. However, POSIX only standardizes the functions of the reliable signal mechanism and the external interfaces of the signal mechanism, but does not specify the implementation of the signal mechanism.

The signal value between SIGRTMIN and SIGRTMAX is a reliable signal, which overcomes the possibility of signal loss. Linux supports the new version of the signal INSTALLATION function sigation () and the signal sending function sigqueue (). It also supports the early signal () signal INSTALLATION function and the signal sending function kill ().

Note: Do not misunderstand that signals sent by sigqueue () and installed by sigaction are reliable. In fact, a reliable signal is a new signal added later (the signal value is located between SIGRTMIN and SIGRTMAX). An Unreliable signal is a signal whose signal value is smaller than SIGRTMIN. The signal reliability is only related to the signal value, and is not related to the signal sending and installation functions. Currently, signal () in linux is implemented through the sigation () function. Therefore, even if the signal installed by signal () is, at the end of the signal processing function, you do not have to call the signal installation function again. At the same time, real-time signals installed by signal () Support queuing and will not be lost.

For the current two linux signal INSTALLATION functions: signal () and sigaction (), neither of them can convert the signal earlier than SIGRTMIN into a reliable signal (neither supports queuing, but may still be lost, it is still an unreliable signal) and supports queuing for signals after SIGRTMIN. The biggest difference between the two functions is that signals installed by sigaction can transmit information to the signal processing function (which is true for all signals ), however, signals installed by signal cannot transmit information to signal processing functions. The same is true for the signal sending function.

(2) Real-time and non-real-time signals

In earlier Unix systems, only 32 types of signals are defined. Ret hat7.2 supports 64 types of signals, numbered 0-63 (SIGRTMIN = 31, SIGRTMAX = 63), which may be further increased in the future, this requires Kernel support. The first 32 signals have predefined values. Each signal has a definite purpose and meaning, and each signal has its own default action. If you press CTRL ^ C on the keyboard, the SIGINT signal is generated. The default reaction to the signal is that the process is terminated. The last 32 signals represent real-time signals, which are equivalent to the reliable signals described above. This ensures that multiple real-time signals are received. Real-time signals are part of the POSIX standard and can be used in application processes.

Non-real-time signals do not support queuing and are all unreliable signals. Real-time signals support queuing and are all reliable signals.

(3), signal name

View available signals supported by linux: kill-l

A total of 64 types:

3. Process response to signals

A process can respond to a signal in three ways: (1) Ignore the signal, that is, no processing is performed on the signal. Two signals cannot be ignored: SIGKILL and SIGSTOP; (2) capture the signal. Define a signal processing function. When a signal occurs, execute the corresponding processing function. (3) perform the default operation. Linux specifies the default operation for each signal, for details, refer to [2] and other materials. Note that the default reaction of a process to a real-time signal is that the process is terminated.

In Linux, which of the above three methods is used to respond to signals depends on the parameters passed to the corresponding API functions.

Note: For more information, see http://blog.csdn.net/lmh12506/article/details/6681663and

Http://blog.csdn.net/johnny710vip/article/details/6990514