Before understanding “Interrupts”, let me explain you what is main program and service program.
Main program is the program that is CPU currently executing and the Service program is the program that I/O devices wants to be executed through CPU, causing an interrupt.
What is interrupt ?
Interrupt is a signal generated by peripherals or IO devices that are sent to CPU(microprocessor) informing that there is a program that needs to be executed first, keeping the main program in hold.
Consider a simple example. You are working on powerpoint. Your CPU is currently executing the program of powerpoint (main program). Now let us say your laptop's battery gets low. What will happen now? There will be a pop up notification on screen saying “your battery is running low". It seems too obvious to you but there is a program for it stored in main memory. When your laptop's battery got low,the PowerPoint program was put in hold and the battery popup (interrupt) was executed by the CPU. This is an example for Hardware Interrupt.
Software interrupt is caused by timer resets, timer interrupts, traps, request for input or output, and arithmetic overflow error.
In system programming, an interrupt is a signal to the processor emitted by hardware or software indicating an event that needs immediate attention. An interrupt alerts the processor to a high-priority condition requiring the interruption of the current code the processor is executing. The processor responds by suspending its current activities, saving its state, and executing a function called an interrupt handler (or an interrupt service routine, ISR) to deal with the event. This interruption is temporary, and, after the interrupt handler finishes, the processor resumes normal activities.
There are two types of interrupts:
- Hardware Interrupts: These are used by devices to communicate that they require attention from the operating system.Internally, hardware interrupts are implemented using electronic alerting signals that are sent to the processor
- Software Interrupts: These are caused either by an exceptional condition in the processor itself, or a special instruction in the instruction set which causes an interrupt when it is executed
 |
| Interrupt Handling |
Each interrupt has its own interrupt handler. The number of hardware interrupts is limited by the number of interrupt request (IRQ) lines to the processor, but there may be hundreds of different software interrupts. Interrupts are a commonly used technique for computer multitasking, especially in real-time computing. Such a system is said to be interrupt-driven.
Interrupt handler: an interrupt handler, also known as an interrupt service routine or ISR, is a special block of code associated with a specific interrupt condition. Interrupt handlers are initiated by hardware interrupts, software interrupt instructions, or software exceptions, and are used for implementing device drivers or transitions between protected modes of operation, such as system calls. An interrupt handler is a low-level counterpart of event handlers.
An Interrupt Service Routine is one that is registered to the hardware via the Operating system at initialization time in order to process interrupts from a particular device when it generates interrupts, and that happens at I/O termination.
Upon entry, the routine needs to determine the reason for the interrupt and the device status, so as to take appropriate action - enter error recovery if an error, hand control back to the initiating program to process data transferred (input) or initiate another transfer (output) and so on. This is done by setting flags in the operating system: ISRs only process the interrupt and exit as quickly as possible; the OS does task switching.
Can we use mutex in Interrupt context ?
Every running process has a context. When processes switch, you swap contexts (called as context switch). When a mutex in process P1 sleeps, the CPU may schedule another process P2 using context switch. When the mutex wakes up, the context of the sleeping process P1 is restored and execution continues.
When a device raises an interrupt, the process context is partially switched to service interrupts quickly and reset the interrupt pin on the device.
When a thread tries to acquire a mutex and if it does not succeed, either due to another thread having already acquired it or due to a context switch, the thread goes to sleep until been woken-up which is critical if used in an ISR. So, the CPU will not know how to save and restore this context correctly. Second, if there is a sleeping mutex, the interrupt may not be serviced as quickly. Interrupts need to be serviced quickly so hardware devices can resume (instead of waiting on the interrupt). Also, multiple devices may share the a single interrupt line and taking too long to service one interrupt may prevent another device from raising an interrupt. Hence, sleeping is disallowed in interrupt service routines in most operating systems.
Here, Spinlock comes as the rescue. When a thread fails to acquire a spin-lock, unlike mutex, it continuously tries to acquire it, until it finally succeeds, thus avoiding sleeping in an ISR. Using spin-locks in the "top-half" is a common practice followed in writing Linux Device Driver Interrupt handlers. Spin locks are better because they are optimized for the no-deadlock/no-waiting situations and can be taken and released very quickly. They are faster and involve less overhead than other synchronization primitives.
Reference : Quora & Stacckoverflow
Comments
Post a Comment