From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing (Rated Start-class, Low-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Low  This article has been rated as Low-importance on the project's importance scale.

Relating Interrupt Articles[edit]

There are a number of interrupt articles that seem to have no direction and a large amount of redundant information. I'm trying to organize them as I track them down.

I figure the layout should be as given below. There should be a seperate page for each Main. Each page should have redundent content eliminated, instead links should be placed to the appropriate main page. Of course, each Main page should be expanded apon. This includes a good introduction, history, features, programming information, references, etc.

Feel free to add additional links to this collection.

Catagory: Category: Interrupts

Specific Hardware:[edit]

General Hardware:[edit]

General Information[edit]




From article: "an interrupt is an asynchronous signal from hardware or software indicating the need for attention". The article later goes on to explain synchronous interrupts caused by software. I am not an expert on this but this appears to be an error. -- Bubbachuck 05:07, 28 October 2006 (UTC)

"Synchronous interrupts" aren't really interrupts. 13:48, 21 November 2006 (UTC)

Ashu on wiki 01:20, 12 December 2006 (UTC) An interrupt is understood by the processor only when it is checked for. So, if a processor checks for interrupts only after the execute cycle of an instruction, even an asynchronous interrupt cannot be understood at any other time. Software interrupts are more predicatble in the sense that they can be part of dry run of a program. On the other hand, interrupts caused by other hardware is completely unpredictable for the program.

Whatever the source (software or hardware), an interrupt is always handled by the processor synchronously: before executing the next instruction pointed to by program counter (PC), if an interrupt has been signaled, then at the next clock cycle, the processor saves the current context and jumps to a special routine (generally in ROM) that manages any kind of interrupts (which generally consumes some clock cycles before the real processing occurs).
Instructions are always executed on clock cycles (even for interruption processing). So asynchronous is not really the appropriate term; we should prefer software-triggered or hardware-triggered, but the consequent behavior is the same.
Note also that due to this extra-processing, latency between the event and start of useful interrupt processing is never null (but is often negligible) and depends on the processor family. Teuxe (talk) 15:10, 18 September 2012 (UTC)

how come this article does not contain a paragraph about 'IRR'[edit]

IRR redirects here. but i can't find no explanation. --

You probably meant Interrupt Request Register? This is an implementation-specific register that may not be general enough to be explained in this article. Presently IRR points to a disambiguation page with no reference to this Interrupt Request Register.
IRR could be introduced as an example of register, if a general algorithm for interrupt processing is described in this article. Teuxe (talk) 15:19, 18 September 2012 (UTC)
I added this definition to IRR, but redirecting to programmable interrupt controller which is more appropriate. Teuxe (talk) 15:32, 18 September 2012 (UTC)


What happens to the interrupt if the computer has more than one processor? What determines which processor will handle the interrupt? (talk) 19:37, 24 December 2009 (UTC)

Each interrupt line is always routed to a single processor. You may see different interrupt lines be mapped to different processors (for various reasons), but never will two processors be interrupted by the same hardware line. Teuxe (talk) 15:23, 18 September 2012 (UTC)

Interrupt routine example[edit]

I propose for deletion the interrupt routine example (for PIC MCU) placed on the article. This example is messy, contains unrelated functionality, looks pretty odd and occupies about one third of content. I think that interrupt handler routines (and related functionality) are very platform dependent (and can be very easily found in reference documentation), so in this article we must concentrate on common aspects without examples. If nobody against - I will delete it in a week time. Pmod (talk) 20:04, 2 April 2010 (UTC)

Totally Agreed. (talk) 11:12, 6 August 2010 (UTC)

Sharing interrupt lines[edit]

As currently described the article leaves an impression that there are severe problems in sharing interrupt lines. In present day architectures the problems have been well solved by interrupt controllers, which can quickly identify and prioritize the interrupt sources and which can be used by software interrupt servers to implement prioritized interrupt handling of any desired complexity. The plain wired-or architecture, which is behind the claims in the architecture, is quite obsolete except in simplest systems. (This is not to say that wired-or itself is obsolete, only in this context.) Even with properly implemented wired-or architecture the problem of multiple interrupt sources of different priorities can be solved by having masking at the generating end and by using software interrupt request queuing. The article should be changed and expanded to reflect the current state of art.Lauri.pirttiaho (talk) 15:08, 29 January 2011 (UTC)

Look out for possible copyright violations in this article[edit]

This article has been found to be edited by students of the Wikipedia:India Education Program project as part of their (still ongoing) course-work. Unfortunately, many of the edits in this program so far have been identified as plain copy-jobs from books and online resources and therefore had to be reverted. See the India Education Program talk page for details. In order to maintain the WP standards and policies, let's all have a careful eye on this and other related articles to ensure that no material violating copyrights remains in here. --Matthiaspaul (talk) 15:20, 30 October 2011 (UTC)

Suggest merge[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
The result of this discussion was to rename the source article. — Dsimic (talk | contribs) 04:09, 13 November 2014 (UTC)

Once Interrupt request is made generic and not a specific list of IBM PC hardware data, it would seem to be redundant with this article and could usefully be merged here. --Wtshymanski (talk) 16:29, 4 November 2014 (UTC)

  • Support: Makes sense to me. — Dsimic (talk | contribs) 06:41, 5 November 2014 (UTC)
  • Support: But I would suggest a different method. Restore the PC-specific material to Interrupt request, move the generic stuff from there to here, and rename Interrupt request to something PC-specific. Jeh (talk) 09:59, 5 November 2014 (UTC)
Hm, as there isn't that much content in Interrupt request in the first place, how about creating new section Interrupt § Platform-specific details (or similar) instead and moving there what would be left in Interrupt request? Just so we don't end up with a really short article that's hardly going to grow bigger? At the same time, I'm really unable to come with a good PC-specific name to which Interrupt request could be renamed. — Dsimic (talk | contribs) 01:47, 6 November 2014 (UTC)
When I said "restore the PC-specific material", I was referring to going back to this version. This approach would better preserve the edit history.
As for the name, a poor name will do for starters; it can always be moved to a better one. Jeh (talk) 04:08, 6 November 2014 (UTC)
Thank you for the clarification. It all makes sense, and the only thing that still confuses me a bit is what would remain in the Interrupt request article? PC-specific stuff, like IRQ assignments from the revision linked above? — Dsimic (talk | contribs) 06:25, 6 November 2014 (UTC)
You mean in the ~"Interrupts on PC architecture" article ;) Yes, basically everything Wtshymanski removed with the edit just after that version. Jeh (talk) 08:40, 6 November 2014 (UTC)
Right, and that might be the new article title. :) Totally agreed, it's much better to keep platform-specific information separate from general descriptions. — Dsimic (talk | contribs) 09:33, 6 November 2014 (UTC)
──────────────────────────────────────────────────────────────────────────────────────────────────── How about I undo this edit [1] and then move Interrupt request to Interrupt request (PC architecture) till someone comes up with a better title for it? Even better than a merge. --Wtshymanski (talk) 19:51, 6 November 2014 (UTC)
I'd say that would be good, as this version of the Interrupt request article is pretty well rounded up, and there isn't much what could be merged into the Interrupt article. Of course, we need to hear from Jeh as well. :) — Dsimic (talk | contribs) 20:14, 6 November 2014 (UTC)
Done. --Wtshymanski (talk) 21:12, 12 November 2014 (UTC)
Sorry, I missed the TP updates. But that was what I proposed already so I can't imagine why I would have objected. Jeh (talk) 21:20, 12 November 2014 (UTC)

The above discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Exit from interrupt service routine[edit]

I just reverted an edit that says that after an ISR the processor resumes normal activity " where it left off." I changed similar text a while ago. I'd like to see a consensus on this. I think this may be true of Linux, but my understanding is that in many OSs the ISR exits to the dispatcher to run the highest priority ready task, which might not be the interrupted task. Peter Flass (talk) 12:09, 22 December 2014 (UTC)

Hello! It's much better to be as less specific as possible on this; returning back to "where it left off" isn't the case even for the Linux kernel, here's a quote from the Linux Device Drivers, third edition, chapter 10. Interrupt Handling, page 269:
Then it's just a matter of cleaning up, running software interrupts, and getting back to regular work. The "regular work" may well have changed as a result of an interrupt (the handler could wake_up a process, for example), so the last thing that happens on return from an interrupt is a possible rescheduling of the processor.
I've also added this into the article's lead section as a reference. — Dsimic (talk | contribs) 18:42, 25 December 2014 (UTC)


It would be interesting to have a "history" section that says when/where interrupts first appeared. Some other versions of this article have one, though without source citations: the Dutch version explicitly says that the Electrologica X1 was the first (that would make the answer 1958, the year that machine first shipped) and the German one says that interrupts appeared "in the 1960, for example in the Electrologica X1" [sic]. Dijkstra's review paper (Dijkstra, Edsger W. EWD-1303. E.W. Dijkstra Archive. Center for American History, University of Texas at Austin.  (original; transcription)) shows that he started working with interrupts in 1957 in the X1 design, but that does not say definitively that this was the first design with interrupts. !!!!