First of all, I must say that I have a computer science background, and I don't have much knowledge about hardware. I would like to ask this question because in software, what I often see is a loop, e.g: while loop, for...loop...

In my understanding, polling is like you check for an event occur every certain amount of time (might require the use of clock?)

Interrupt is like we don't care if it "loops" or not, when the event comes, it will "signal"...

What about in hardware? What is actually equivalent to a "while loop" or "for loop" in hardware? I assume it is a mix of polling and interrupts...but I wonder which one is really first? Isn't it it that when we check for something, we must poll it first? (maybe I'm a bit biased on polling here).

  • \$\begingroup\$ What do you mean by "first"? \$\endgroup\$ – pjc50 May 4 '16 at 16:06

Something to know is that interrupts require special hardware to work, and work at a layer 'outside' what you can manage purely with a programming language like C. Typically different compilers and different chips expose interrupt controls in different ways. Some have magical function names, or magical preprocessor macros, that signal the compiler to use the special instructions and memory layouts that are needed to manage the interrupts.

In the case of polling, the software running has some loops, checks some value, then branches when the state of interest has been reached. This is the normal programming you are familiar with.

With an interrupt, the chip has hardware to halt execution of the software, and jump to a special location for the interrupt handler. The interrupt handler often needs to save the state of the halted software, so that after the handler does its job, it can return to the software and pick up where it left off.

Neither method is "first", and while the interrupt style of programming can make some applications considerably faster, virtually any application can be written to use either method. Different applications are better suited to one or the other.

| improve this answer | |
  • \$\begingroup\$ In a daily used PC, is there any hardware part which uses polling when checking events? So far, I know that keyboard controllers use interrupts, mouses do too... \$\endgroup\$ – tlc May 4 '16 at 17:25
  • \$\begingroup\$ ctyme.com/rbrown.htm \$\endgroup\$ – whatsisname May 4 '16 at 17:32
  • \$\begingroup\$ the site only lists a bunch of interrupts, not polling! I want to know more about some specific polling devices in a PC. Could you just name for me one? I'm just curious... \$\endgroup\$ – tlc May 4 '16 at 17:40
  • 1
    \$\begingroup\$ @root Polling happens, but it is not popular in high speed modern computers, because it uses the bus inefficiently when there's very little data. However, you do see polling in master/slave situations. For example, with USB, the computer polls the peripherals because the peripherals are forbidden to act until spoken to. \$\endgroup\$ – Cort Ammon May 4 '16 at 20:26
  • 2
    \$\begingroup\$ @root This is a place in computer architecture where the lines between hardware, firmware, and software can get a bit blurry. There's "software" all over in the computer, not just in the parts you might normally think of. Some even do things which "traditional" software on a CPU couldn't actually do. For example, USB can do isochronous data transfer in real time. This, being USB, calls for polling. However, the CPU could never provide sufficient timing guarantees. In fact, the USB subsystem is doing the polling in this case. \$\endgroup\$ – Cort Ammon May 5 '16 at 21:16

Polling in hardware is quite analogous to a loop in software. Many simple devices use this method. You may have a thermostat on your wall that simply goes around and around in a loop thousands of times each second asking the same question: "Is it cold enough to turn on the heater?"

And a hardware interrupt is directly connected with a software interrupt. Typically when we employ a hardware interrupt scheme, it directly triggers a software interrupt handling routine in the software of the controller.

Interrupts are more appropriate for things with unpredictable durations. The temperature of your room is a pretty slow changing thing, so it doesn't matter whether you ask NOW or in 10 seconds whether it is cold enough to turn on the heater. But if you are sensing something transient, like an animal passing through an optical beam or a human pressing a button, it may be here and gone before you get around to polling it again. For that reason, we use hardware latch and an interrupt to notify the controller that something happened, perhaps while you were doing something else or even sleeping.

| improve this answer | |

There is no one answer other than "it depends".

First off, what is the hardware equivalent of polling? It is the clock, logic is generally evaluated every clock cycle, so the interrupt line will be examined by the logic every cycle. That doesnt mean that interrupt signal is generated by the perpheral one one cycle and is evaluated the next cycle. "It depends" on the design, it may be a few or many or dozens of cycles.

As you know being in software, first the processor either has to wait to finish the current instruction, or aborts the current instruction, then you have to fetch the vector table, maybe there is a mmu table you have to read through in order to find that, maybe not. Maybe you had to switch from user to superviser mode along the way, it depends on your code and design. Also you are flushing the pipe, finding the isr, fetching those, filling the pipe. Then software needs to save state, so you are pushing registers and flags to the stack, this could take an eternity, with the layers of memory you may have, or wait states on the speed of the ram, etc.

Then depending on the design of your system, you may have to wander through the peripherals or at least ask the interrupt controller who caused the interrupt. then go to the peripheral and ask it why. Eventually figuring that out and now

You can service the interrupt.

Then you may have to re-arm the interrupt, or clear it at the peripheral and maybe other places in between. Then restore the state of the machine, reading from ram which may or may not be cached or may be in slow memory, may be wandering through an mmu again.

And finally return from the interrupt.

Polling, now polling is not necessarily every some fixed unit of time, it is wherever in the code you choose to poll, you might have every other line of code check, you might have one time through your main loop check, and the time through the main loop may vary depending on what you are doing in that loop and what tangents it can take.

But to compare, or beat interrupt performance, one could craft an example that does nothing but poll in a tight loop, polling the peripheral status directly, if a cache the code is in cache fetching quickly, depending on the design of the core, and what you have enabled you may have branch prediction on and since this is not a conditional loop, it should always predict right and save a few cycles flushing the pipe to go through the loop again. when you do see the status change you branch out of the loop and start servicing it immediately. you may still have the mmu hit, cache and other but you dont need to save the state of the machine, you dont need to talk to an interrupt controller nor ask the peripheral what happened, you already know, you basically branch directly into the

service the event.

and then you can branch back into your main loop.

So it is quite simple to craft an experiment were polling outperforms interrupts by a large margin. As well as where interrupts outperform polling. As mentioned you could have a large main loop, but poll a particular peripheral every other line or something, although wasteful still get good response time. probably better to use an interrupt.

it is all about doing your system engineering, understanding and timing the worst case execution paths. many a realtime system has been made with polling only and no interrupts. likewise many a system has been made that is strictly interrupts.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.