Question

 

5. What is a trap? Give an example. How does it differ from an interrupt?

6. Why does the Linux kernel handle certain interrupts in two stages: top half and bottom

half?

7. What is a context switch? What is the role of the kernel in a context switch?

8. What is the maximum number of processes in the system at any time using the following

code segment?

extern char mypath[];

for ( int i = 0; i < 10; i++ )

{

pid_t pid, pid_out;

unsigned char status;

if ( pid = fork() )

pid_out = wait ( &status );

else

execl ( mypath, "child", "parameter", NULL );

}

Assume that child performs some simple computation and returns the result, that is captured

in status.

Answer 1

1.

A Trap can be identified as a transfer of control, which is initiated by the programmer. The term Trap is used interchangeably with the term Exception (which is an automatically occurring software interrupt). But some may argue that a trap is simply a special subroutine call. So they fall in to the category of software-invoked interrupts. For example, in 80×86 machines, a programmer can use the int instruction to initiate a trap. Because a trap is always unconditional the control will always be transferred to the subroutine associated with the trap. The exact instruction, which invokes the routine for handling the trap is easily identified because an explicit instruction is used to specify a trap.

What is the difference between Interrupt and Trap?

Interrupts are hardware interrupts, while traps are software-invoked interrupts. Occurrences of hardware interrupts usually disable other hardware interrupts, but this is not true for traps. If you need to disallow hardware interrupts until a trap is served, you need to explicitly clear the interrupt flag. And usually the interrupt flag on the computer affects (hardware) interrupts as opposed to traps. This means that clearing this flag will not prevent traps. Unlike traps, interrupts should preserve the previous state of the CPU.

2.

Limitations On interrupt handler:-

1) It runs asynchronously by interrupting the other code.

2)All interrupt on the current processor disabled.

3)Interrupts are often time critical as they deal with hardware.

4) We cannot block interrupt handler as they run in interrupt context.

Because of all these limitation if our interrupt handling will last for long then our system performance will be less as we won’t able to serve any other request during interrupt handling. So it’s better to shorten the interrupt handling and perform less critical work later.

Interrupt handling is divided into two parts

1) Top Halves:- It is executed as immediate response to interrupt.

2)Bottom Halves:- It is executed some time later when CPU get free time.

Top Halves:- Top halves executes as soon as CPU receives the interrupt . Following work are generally performed in top halves

1) Acknowledgement of receiving the interrupt

2) copy if some data is received

3) if the work is sensitive needs to perform in top halves.

4)If the work is related to hardware needs to perform in top halves.

5)If the work needs to be ensure that another interrupt does not interrupt it , should be perform in interrupt handler.

Everything else is performed in bottom halves.

Bottom Halves:- Job of bottom halves is to perform the left out work that was not performed by the interrupt handler or top halves. After bottom halves complete their work, It schedule bottom halves for the later time in future whenever our system will be ideal With the time various techniques of bottom halves evolved . Following are types of bottom halves.

1) Original “bottom Half”

2)Task Queues

3) Softirq

4)Tasklets

5)workqueus

3.

Context Switching involves storing the context or state of a process so that it can be reloaded when required and execution can be resumed from the same point as earlier. This is a feature of a multitasking operating system and allows a single CPU to be shared by multiple processes.

role of kernel:

A context switch occurs when the kernel transfers control of the CPU from an executing process to another that is ready to run. The kernel first saves the context of the process. The context is the set of CPU register values and other data that describes the process' state. The kernel then loads the context of the new process which then starts to execute.

When the process that was taken off the CPU next runs, it resumes from the point at which it was taken off the CPU. This is possible because the saved context includes the instruction pointer. This indicates the point in the executable code that the CPU had reached when the context switch occurred.