Reputation: 1926
I was reading about how OS works with interrupts to communicate with hardware, just wondering, if there is any other architecture other than Interrupt driven? In Robert Love's book for Linux kernel, he says that most of the architecture that Linux handles are Interrupt driven, so what are the other ones? Can some one give examples? Thanks.
Upvotes: 3
Views: 2397
Reputation: 11
I equate polling architecture to a deterministic process orientation, and interrupt driven to a random process orientation. Neither one is better on their own merits, and both are needed in general. It depends on the external tasks and interfaces. Often systems will have to permit the interaction of many processes and it is beneficial to plan the architecture to partition randomness in the context of processes than may meet requirements while experiencing random service constraints from those that must be serviced on a regular basis with no randomness. Poor design has certain timing constraint oriented services being violated randomly leaving no software level resolution to functional dilemmas. Random processes are modeled with additional complexity using discrete-event simulation modeling, while deterministic process orientation can be analyzed much more simply with continuous functions.
Upvotes: 1
Reputation: 21
At a low level, polling is the main alternative. However, architecturally, main approaches are monolithic, where interrupts directly drive the device drivers and micro-kernel, where the device drivers may be separate processes that get informed by the kernel when hardware events happen. Interrupts sill happen but they are managed by a very small kernel. I suspect this is the difference your quote is referring to. Polling is not very common any more. One of the best known micro kernel based OS is Minix because it is used for teaching.
Upvotes: 2
Reputation: 209625
The short answer to your question is that there's only one other model and that's polling. In a polling model, the system repeatedly asks the hardware if anything has happened. The downside to this model is that the CPU is always busy asking and can only know about activity if it's asking for it. If it starts doing something else, it could miss an action (since it wasn't asking for activity at the time of the action).
The longer answer:
If you think about it, there can really only be two possible systems: polling (pull) and event-driven (push). In the former, you ask the hardware if anything's happened, and in the latter, the hardware tells you. Put another way: the agency in the former is with the CPU/OS, and in the latter, it's with the hardware. Since there are two parties, and each party can be doing one of two things, that means that we can only have two types of systems (push/interrupt and pull/polling), plus a hybrid (both interrupt-driven and polling based at different times or in different contexts).
One could imagine a variety of ways to implement any of the three systems, and one could count those as distinct models, even if, under the hood, they are really implementing one of the possible systems. I would imagine that's not really what you're looking for, though.
Upvotes: 3
Reputation: 62068
I'm guessing, its some hard real-time systems, where instead of using asynchronous interrupts, the system checks (polls) the state of I/O devices at well-defined times (could be periodic). If a device isn't ready or is in an unexpected state, the system reports a failure.
Upvotes: 1