Differences between version 7 and predecessor to the previous major change of InterruptHandler.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 7 | Last edited on Monday, October 18, 2004 9:49:03 am | by JohnMcPherson | Revert |
| Older page: | version 4 | Last edited on Monday, October 18, 2004 3:18:36 am | by AristotlePagaltzis | Revert |
@@ -1,7 +1,10 @@
-A section of code run
whenever an interrupt
occurs. These may be at
the application level or at the OperatingSystem's level
. They
are notoriously hard to write because they occur asynchronously with the rest of the application or OperatingSystem
. Hardware interrupts can
also happen __very__ frequently, so their handlers are commonly written in AssemblyLanguage
.
+A section of code invoked by the hardware
whenever an [IRQ]
occurs. It is generally part of
the [Kernel] and usually contained in a device driver
. Because they occur asynchronously, invoked by hardware rather than through normal control flow, InterruptHandler~s
are notoriously hard to write (see RaceCondition)
. They are
also commonly written in AssemblyLanguage because [IRQ]s tend to
happen __very__ frequently.
-Generally,
the term "interrupt" is used for hardware-generated requests
, while "signal" is used for software/OperatingSystem-generated requests
.
+One specific InterruptHandler is of paramount importance in modern OperatingSystem~s:
the timer [IRQ] invokes a handler which drives the scheduler that distributes [CPU] time among tasks. Without this [IRQ] and its handler
, preemptive multitasking would not be possible
.
-See also:
-*
[IRQ
]
-*
[Signal]
+Note that this is different from a
[Signal
] handler, which is called by the [Kernel] through normal control flow means. Note that software can trigger interrupts, and InterruptHandler~s sometimes send
[Signal]s. The concepts remain distinct, though, despite having many things in common. In general an interupt ([IRQ] on x86) is to the kernel as a signal is to an application.
+
+----
+On linux, try running
+ procinfo -n 1
+to see counts of the number of interrupts that your kernel receives, and other things such as the number of context switches. the "-n __1__" means update the display every second.
