Signaling &Interrupts in the Operating System

DYPCOE ,AMBI

Signaling & Interrupts in the Operating System

Rohit S. Ragmahale
D.Y.Patil COE,Ambi,Pune

Abstract The design of modern operating systems is based around the concept of memory as

a cache for data that flows between applications, storage, and I/O devices. With the increasing
disparity be- tween I/O bandwidth and CPU performance, this architecture ex- poses the
processor and memory subsystems as the bottlenecks to system performance. Furthermore, this
design does not easily lend itself to exploitation of new capabilities in peripheral devices, such
as programmable network cards or special-purpose hardware accelerators, capable of cardto-card data transfers.
Index Terms - Operating system, signaling in Operating system, Interrupt Mechanism.

1. Introduction:
A signal is a software interrupt, a way to communicate information to a process about the state of
other processes, the operating system, and the hardware. A signal is an interrupt in the sense that it can
change the flow of the program when a signal is delivered to a process, the process will stop what its
doing, either handle or ignore the signal, or in some cases terminate, depending on the signal.
There are varieties of factors impacting a systems real-time. Among these factors, operating
system and its own factors play crucial roles, including process management, task scheduling, context
switching time, memory management mechanism, the time of interrupt handle, and so on.

2.Signaling in Operating system:

Signals also are delivered in an unpredictable way out of sequence with the program because signals
usually originate outside of the current executing process. Another way to view signals is a mechanism for
handling asynchronous events. As opposed to synchronous events, which is when a standard program
executing iteratively, one line of code following another, asynchronous events is when portions of the
program may execute out of order, or not immediately in a iterative style. Asynchronous events are typically
due to external events at the interaction layer between the hardware and the operating system; the signal,
itself, is the way for the operating system to communicate these events to the processes.

Signaling &Interrupts in the Operating System

DYPCOE ,AMBI

Signals are software generated interrupts that are sent to a process when a event happens. Signals can be
synchronously generated by an error in an application, such as SIGFPE and SIGSEGV, but most signals are
asynchronous. Signals can be posted to a process when the system detects a software event, such as a user
entering an interrupt or stop or a kill request from another process. Signals can also be come directly from
the OS kernel when a hardware event such as a bus error or an illegal instruction is encountered. The system
defines a set of signals that can be posted to a process. Signal delivery is analogous to hardware interrupts in
that a signal can be blocked from being delivered in the future. Most signals cause termination of the
receiving process if no action is taken by the process in response to the signal. Some signals stop the
receiving process and other signals can be ignored. Each signal has a default action which is one of the
following:

The signal is discarded after being received

The process is terminated after the signal is received

A core file is written, then the process is terminated

Stop the process after the signal is received

Each signal defined by the system falls into one of five classes:

Hardware conditions

Software conditions

Input/output notification

Process control

Resource control

Signal Handling --signal()

An application program can specify a function called a signal handler to be invoked when a specific signal is
received. When a signal handler is invoked on receipt of a signal, it is said to catch the signal. A process can
deal with a signal in one of the following ways:

The process can let the default action happen

The process can block the signal (some signals cannot be ignored)

the process can catch the signal with a handler.

Signal handlers usually execute on the current stack of the process. This lets the signal handler return to the
point that execution was interrupted in the process. This can be changed on a per-signal basis so that a signal
handler executes on a special stack. If a process must resume in a different context than the interrupted one,
it must restore the previous context itself
Receiving signals is straighforward with the function:
int (*signal(int sig, void (*func)()))() - that is to say the function signal() will call the func functions if the
process receives a signal sig. Signal returns a pointer to function func if successful or it returns an error to
errno and -1 otherwise.

Signaling &Interrupts in the Operating System

DYPCOE ,AMBI

func() can have three values:

SIG_DFL-- a pointer to a system default function SID_DFL(), which will terminate the process upon receipt
of sig.
SIG_IGN-- a pointer to system ignore function SIG_IGN() which will disregard the sig action (UNLESS it is
SIGKILL).
A function address-- a user specified function.
SIG_DFL and SIG_IGN are defined in signal.h (standard library) header file.
Thus to ignore a ctrl-c command from the command line. we could do: signal(SIGINT, SIG_IGN);
TO reset system so that SIGINT causes a termination at any place in our program, we would do:
signal(SIGINT, SIG_DFL);

3. Interrupts in the Operating System:

The operating system does not enable them while it is in system mode.The context switch back to user
mode in the dispatcher will reenable interrupts.This makes it easier to write the operating system code,since
we do not have to worry about an interrupt when it is not ready for it.But it is long time to keep interrupts
disable.This is not a realistic restriction for an operating system,since it is generally not a good idea to inhibit
interrupts for too long,Some device will just wait,so inhibiting their interrupts only reduces their actual speed
of operation,but other devices cannot be ignored for very long or else data will be lost. It is not hard to
improve this situation by reenabling interrupts while in system mode,but it requires some careful planning to
make this work.For now,let us just look at an example of what could go wrong if we did not have this
restriction.Suppose a process makes a system call and control SystemCallInterryptHandler.The procedure
saves the register state Current_Process,and then disk interrupt occurs.The first action the disk interrupt
handler will take is to save the register state into the very same save area( since the value of Current_Process
will not have changed yet).The old state will have been lost.This is called a reentrancy failure,since the
second time we enter the operating system we write over a common data area. The problem is that the
operating system needs a few instruction to save the state of the interrupted process before it can tolerate
another interrupt
An interrupt is a request of the processor to suspend its current program and transfer control to a
new program called the Interrupt Service Routine (ISR). Special hardware mechanisms that are designed for
maximum speed force the transfer. The ISR determines the cause of the interrupt, takes the appropriate
action, and then returns control to the original process that was suspended.
Why do you need interrupts? The structure of the processor of any computer is conceived so it can carry
out instructions endlessly. As soon as an instruction has been executed, the next one is loaded and executed.
Even if it appears the computer is inactive, when it is waiting in the DOS prompt or in Windows for your
next action, it does not mean it has stopped working , only to start again when instructed to. No, not at all. In
fact, many routines are always running in the background independently of your instructions , such as
checking the keyboard to determine whether a character has been typed in. Thus, a program loop is carried
out. To interrupt the processor in its never-ending execution of these instructions, a so-called interrupt is
issued. That is why it is possible for you to reactivate the CPU whenever you press a key (fortunately...).

Signaling &Interrupts in the Operating System

DYPCOE ,AMBI

Another example, this time an internal one, is the timer interrupt, a periodic interrupt, that is used to activate
the resident program PRINT regularly for a short time.
For the 80x86 256 different interrupts (ranging from 0-255) are available in total. Intel has reserved the
first 32 interrupts for exclusive use by the processor but this unfortunately hasn't prevented IBM from
placing all hardware interrupts and the interrupts of the PC BIOS in exactly this region which can give rise to
some strange situations.
Speaking of hardware interrupts, you can distinguish three types of interrupts:
- Software Interrupts
- Hardware Interrupts
- Exceptions
1) Software Interrupts:
Software interrupts are initiated with an INT instruction and, as the name implies, are triggered via
software. For example, the instruction INT 33h issues the interrupt with the hex number 33h.
In the real mode address space of the i386, 1024 (1k) bytes are reserved for the interrupt vector table
(IVT). This table contains an interrupt vector for each of the 256 possible interrupts. Every interrupt vector in
real mode consists of four bytes and gives the jump address of the ISR (also known as interrupt handler) for
the particular interrupt in segment:offset format.
When an interrupt is issued, the processor automatically transfers the current flags, the code segment CS
and the instruction pointer EIP (or IP in 16-bit mode) onto the stack. The interrupt number is internally
multiplied by four and then provides the offset in the segment 00h where the interrupt vector for handling the
interrupt is located. The processor then loads EIP and CS with the values in the table. That way, CS:EIP of
the interrupt vector gives the entry point of the interrupt handler. The return to the original program that
launched the interrupt occurs with an IRET instruction.
Software interrupts are always synchronised with program execution; this means that every time the
program gets to a point where there is an INT instruction, an interrupt is issued. This is very different from
hardware interrupts and exceptions as you'll soon find out.
2) Hardware Interrupts:
As the name suggests, these interrupts are set by hardware components (like for instance the timer
component) or by peripheral devices such as a hard disk. There are two basic types of hardware interrupts:
Non Maskable Interrupts (NMI) and (maskable) Interrupt Requests (IRQ).
An NMI in the PC is, generally, not good news as it is often the result of a serious hardware problem,
such as a memory parity error or a erroneous bus arbitration. An NMI cannot be suppressed (or masked as
the name suggests). This is quite easy to understand since it normally indicates a serious failure and a
computer with incorrectly functioning hardware must be prevented from destroying data.
Interrupt requests, on the other hand, can be masked with a CLI instruction that ignores all interrupt
requests. The opposite STI instruction reactivates these interrupts. Interrupt requests are generally issued by a
peripherical device.

Signaling &Interrupts in the Operating System

DYPCOE ,AMBI

Hardware interrupts (NMI or IRQ) are, contrary to software interrupts, asynchronous to the program
execution. This is understandable because, for example, a parity error does not always occur at the same
program execution point. This makes the detection of program errors very difficult if they only occur in
connection with hardware interrupts.
3) Exceptions:
This particular type of interrupt originates in the processor itself. The production of an exception
corresponds to that of a software interrupt. This means that an interrupt whose number is set by the processor
itself is issued. When do exceptions occur? Generally, when the processor can't handle alone an internal error
caused by system software.
There are three main classes of exceptions which I will discuss briefly.
- Fault : A fault issues an exception prior to completing the instruction. The saved EIP value then points
to the same instruction that created the exception. Thus, it is possible to reload the EIP (with IRET for
instance) and the processor will be able to re-execute the instruction, hopefully without another exception.
- Trap : A trap issues an exception after completing the instruction execution. The saved EIP points to the
instruction immediately following the one that gave rise to the exception. The instruction is therefore not reexecuted again. Why would you need this? Traps are useful when, despite the fact the instruction was
processed without errors, program execution should be stopped as with the case of debugger breakpoints.
- Abort : This is not a good omen. Aborts usually translate very serious failures, such as hardware
failures or invalid system tables. Because of this, it may happen that the address of the error cannot be found.
Therefore, recovering program execution after an abort is not always possible.

Figure - Interrupt-driven I/O cycle.

Signaling &Interrupts in the Operating System

DYPCOE ,AMBI

The above description is adequate for simple interrupt-driven I/O, but there are three needs in
modern computing which complicate the picture:
1
The need to defer interrupt handling during critical processing,
2
The need to determine which interrupt handler to invoke, without having to poll all devices
to see which one needs attention, and
3
The need for multi-level interrupts, so the system can differentiate between high- and lowpriority interrupts for proper response.

Efficiency and treatment methods of interrupt :

As the driving force for operating system scheduling, interrupt provides approaches of interaction between
external events and operating system. The interrupt response speed is one of the most important ingredients
which impact the real-time performance of system. At the end of each instruction execution, CPU will detect
the status of interrupt. If there is an interrupt request and the interrupt is not prohibited, the system will
execute a series of interrupt treatments: pushing values of CPU registers to stacks, obtaining the interrupt
vector and getting the procedures counter register value, then jumping to the entrance of ISR and beginning
to run, etc. What have mentioned above requires some system consumption. For a specific system, the
consumption is identifiable, that is to say: it is possible to calculate the time delay of interrupt treatment
caused by this part of work.
As interrupt management strategy, allowing interrupt nesting can further improve the response of highpriority incidents real-time, but relatively low-priority interrupt handling will be suffer negative impact. It
should be considered under certain situation.
Non-emergency interruption may cause delay to important and urgent tasks, because interrupt handling is
executed before task and thread. In order to reduce the delay, the handle process should be divided into two
parts, just like Linux divided it into the top half and bottom half. Also Windows CEs interrupt handling is
divided into two parts: ISR and IST. They tried to keep ISR as a short program, while allowing tasks do more
work, and make full use of the in a hybrid system. Basically, real-time and non-realtime
interrupt requests are passed to the interrupt handling code through the interrupt request entry. The interrupt
handling code can be separated into two parts, the interrupt distribution routine and interrupt service routine
(ISR). First, the interrupt distribution routine determines the entry point for an interrupt request. Next, a
specific interrupt service routine is called, and then the interrupted task/program/interrupt is resumed or a
new task/interrupt is rescheduled to be executed before exiting from the ISR. Although the interrupt handling
in hybrid systems looks like that in general-purpose OS, it has to be changed a lot with the structure shown in
Fig. 1, in which real-time and non- real-time interrupts are passed through the same interrupt request entry.
First, in the interrupt distribution code, in order to satisfy the predictability of the real-time subsystem, we
need to separate real-time and non-real-time interrupts since they will be processed differently. Second, we
have to solve the interrupt disabling problem when dealing with non-real-time interrupts.

Signaling &Interrupts in the Operating System

DYPCOE ,AMBI

The interrupt disabling problem is caused as follows: The time-sharing subsystem of a hybrid system is
usually treated as the task with the lowest priority. With the lowest priority, the time-sharing subsystem task
cannot block realtime interrupts nor can it prevent itself from being preempted. On the other hand, in a timesharing operating system, such as Linux, interrupt disabling is frequently used in interrupt handlers, critical
sections, and so on. And in most processors, interrupt disabling is achieved by masking the interrupt
disabling/enabling bit in the Program Status Word (PSW) register, and all interrupt requests will be disabled
if the bit is set. In hybrid systems, we cannot really set the interrupt disabling/enabling bit for interrupt
disabling from the time- sharing subsystem task.

Interrupt Latency:
An interrupt has the highest priority and can preempt any task. It is common to disable interrupt for safety in
Linux kernel process. If lower priority tasks disable interrupt there will be uncertain latency time for realtime tasks response, which is not allowed for real-time system. Therefore Interrupts should be properly
handled and tackled for the scheduling of the Tasks and Handling the Interrupts.

Signaling &Interrupts in the Operating System

DYPCOE ,AMBI

4.Conclusion:
A signal is an interrupt in the sense that it can change the flow of the program when a signal is delivered
to a process, the process will stop what its doing, either handle or ignore the signal, or in some cases
terminate, depending on the signal.
There are varieties of factors impacting a systems real-time. Among these factors, operating
system and its own factors play crucial roles, including process management, task scheduling, context
switching time, memory management mechanism, the time of interrupt handle, and so on.

Signaling &Interrupts in the Operating System

DYPCOE ,AMBI

5.References:
[1]Advanced Interrupt Mechanism for Hybrid Operating System,Prakash S. Prasad1, Professor
Dr.Akhilesh R. Upadhyay,Research Scholar, CSE Department, Bhagwant University, Ajmer,
Rajasthan.INDIA.
[2]Book:Operating Systems A Design oriented Approach,Charles Crowley.
[3]High-Speed I/O: The Operating System As A Signalling Mechanism,paper,Matthew Burnside Computer
Science Department Columbia University

[4]http://www.delorie.com/djgpp/doc/ug/interrupts/inthandlers1.html

Signaling &Interrupts in the Operating System

DYPCOE ,AMBI