We help IT Professionals succeed at work.

We've partnered with Certified Experts, Carl Webster and Richard Faulkner, to bring you two Citrix podcasts. Learn about 2020 trends and get answers to your biggest Citrix questions!Listen Now

x

understanding interrupt vector, interrupt handler, and interrupts

Medium Priority
351 Views
Last Modified: 2013-11-14
can anyone please explain to me what is the correlation between these three and how they work with each other?
Comment
Watch Question

Consultant
Commented:
In a nutshell:

Interrupts are signals delivered by hardware to notify the processor of some actions that needs to be taken.. It's used to allow the processor to continue doing other functions while waiting for hardware instead of sitting in a polling loop.

An interrupt vector is a location in memory associated with a specific device that contains the address of code that is to be executed when an interrupt is delivered.

The code to be executed is called the interrup handler.

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts

Author

Commented:
>>It's used to allow the processor to continue doing other functions while waiting for hardware instead of >>sitting in a polling loop.

Can you elaborate on this part? I am not clear what you mean by waiting for hardware
Hugh FraserConsultant

Commented:
Sure. Modern operating systems support multiple processes (programs, services,...) running simultaneously. When one of these processes makes a request that involves a piece of hardware, such as reading a block from a file on disk, there will be a delay waiting for the hardware to complete the request. Rather than waiting for the request to complete, the operating system marks the requesting process as blocked waiting for I/O to complete, and allows other processes to continue running, waiting for the disk controller to send an interrupt when the request is completed. The interrupt vector points to interrupt handler in the OS that completed the read request. At this point, the process scheduling logic in the OS usually kicks in, and the requesting process is typically made the running process again. This scheduling also happens when the hardware clock interrupt comes in (handled just like any interrupt)l, giving the OS a chance to share the CPU across all runnable processes at regular intervals in a multitasking environment.

There are other models for handling hardware requests. Older OS's like Microsft DOS (and if you remember CP/M) do not support multitasking; when a program makes a hardware request, the computer waits until it finishes. That doesn't translate very well to multitasking, since an I/O request from one process would stall all processes while the OS polls the hardware waiting for the request to complete.
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.