8

I studied interrupts vs cyclical polling and learnt the advantages of interrupts that don't have to wait for a poll. Polling seemed to me just like event-driven programming or at least similar to a listener and what the polling does is actually much like listening to input or output. Do you agree or did I misunderstand any crucial difference between polling (cyclical listening) and event-driven programming (also listening with so-called listeners)?

Niklas Rosencrantz
  • 25,640
  • 75
  • 229
  • 424

3 Answers3

15

Nope, quite the contrary interrupt driven programming is pretty much what event driven programming is at the hardware level. Both interrupt driven code and event driven code waits for event before running a code, while polling will attempt to query for event whether or not one actually exists.

However, it should be noted that interrupt- and event-driven programs are generally implemented in the lower level using a form of polling; there is no truly interrupt or event driven system that does not involve some sort of polling, although usually in hardware. In the case of interrupts, the CPU actually polls the interrupt line every clock cycle, and likewise with event driven programming because restarting a paused thread involves an interrupt being raised by the source of event (usually drivers).

You can say that interrupt- and event- driven programming is a disciplined way to poll that have lots of advantage compared to actually doing polling yourself.

Lie Ryan
  • 62,238
  • 13
  • 100
  • 144
  • Saying that lower-level implementations use polling is a misrepresentation. It really depends. Most hardware has real interrupts which will literally interrupt the CPU when it becomes active. The CPU then executes the routine specified in the interrupt vector table. No polling necessary. – josaphatv Oct 27 '13 at 05:39
  • 2
    @josaphatv: in the hardware level, real interrupts involves the CPU having a circuitry that samples whether the interrupt line is active at certain points in the clock cycle. This is a form of polling implemented in the hardware level. The CPU doesn't and cannot interrupt itself in the middle of processing an instruction, as that'd leave the CPU in an inconsistent state. – Lie Ryan Oct 27 '13 at 15:23
  • @LieRyan I understand what you mean. But is it possible to have a circuitry, where a signal let us say on Line 'L1' makes the CPU jump to an interrupt service routine. The CPU is not necessarily polling for this. The moment L1 is triggered, the CPU pointer jumps to a predefined location. It is just intelligent circuitry. Is this not possible? Because if the CPU is polling after every time slice, to check if the interrupt flag is set, it still wastes CPU cycles. By having a circuitry, where once the interrupt line L1 is triggered, the instruction itself changes to make CPU jump to an ISR. – GandalfDGrey Mar 02 '18 at 07:24
  • @LieRyan For instance you could have a De-Mux where there are 9 Lines. 8 are for normal operation, but when the 9th line is triggered (L1 in this case), a different instruction is selected and CPU executes that. that instruction happens to make the CPU jump to an ISR. I'm don't know if this is the case, but I'm just thinking if this is possible. – GandalfDGrey Mar 02 '18 at 07:28
  • @GandalfDGrey: you get it more or less correct. When polling is implemented at the hardware, it doesn't necessarily waste CPU cycle to check the interrupt line, as the check happens in parallel in the circuitry. However, a CPU can only change what it's doing inbetween clock cycles. Also when interrupt happens, the CPU has to load instructions from ISR, which usually means flushing instruction pipeline cache as well as saving registers and CPU caches, it's like a branch mispredict. There are also code sections that are marked non-interruptible, which means the interrupt has to be delayed. – Lie Ryan Mar 02 '18 at 22:24
2

Polling and interrupt handling are two ways to find out about events. Neither is in contradiction with event-driven programming, which is building your program around handling of incoming events.

Alexey Feldgendler
  • 1,792
  • 9
  • 17
0

Both the answers are correct and addresses the original question. I am attempting to add a few points/considerations on event-driven / polling as is generally utilized from a bit higher level, from application containers.

If we assume we have a table where states of some components are written and based on the state some action needs to be taken; this could very well be designed as Q based eventing system or thread based polling system.

In the polling system in face of system/container termination/shutdown, the polling thread will find the changes in the next cycle and act on it.

In case of an event based system, if the container terminates before the event could be processes, it would result in the loss of the event. However, having said that there are transactional queues which are available and the capability comes out of the box; implementation of transaction, in general is a non-trivial process.

Both the methods are very much viable and not superior/inferior to each other. However, there are considerations for each model.

Ironluca
  • 3,402
  • 4
  • 25
  • 32