Diskussion:Interrupt

Lizenzhinweis

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Diesen Hinweis bitte nicht entfernen oder archivieren und immer an erster Stelle auf dieser Diskussionsseite belassen.

Die Artikel Interrupt und Unterbrechungsanforderung haben sich thematisch überschnitten. Daher wurden aus dem Artikel Unterbrechungsanforderung einige Textpassagen übernommen und in Interrupt eingefügt.

• hier findet sich der Artikel Unterbrechungsanforderung zum Zeitpunkt der Übernahme
• hier findet sich die zusammengefasste Versionsgeschichte des Artikels Unterbrechungsanforderung.

Damit werden die Lizenzbestimmungen der GNU-Lizenz für freie Dokumentation (GNU FDL) und der CC-BY-SA 3.0 gewahrt.
Darian (Diskussion) 01:05, 30. Aug. 2016 (CEST)

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Struktur des Artikels

Ohne auf den Inhalt einzugehen mus ich sagen, dass die Struktur sehr unübersichtlich ist. Als ich die Seite gesehen habe hatte ich gleich keine Lust mehr weiterzulesen, weil mir nur ein riesen Text entgegengeworfen wurde. Vielleicht wäre eine sinnvollere Einteilung des Inhalts machbar. --77.2.209.57 13:18, 11. Jan. 2008 (CET)

Umm, neue Punkte bitte immer unten anhängen und nicht oben reinklemmen. - Das Problem hat auch damit zu tun, dass es einen Parallelartikel gibt (siehe Box am Anfang), der zwar übersichtlicher gegliedert ist, aber weniger ausführlich ist. D. h. irgendjemand wird sich irgendwann mal aufraffen, aus diesen beiden Artikeln einen schönen, runden zu machen und dabei alle diese Probleme mit abzuarbeiten. Aber das ist so viel Aufwand, da sind alle wohl bisher davor zurückgeschreckt und haben erstmal gar nichts gemacht. Seufz, ich ja auch nicht. --PeterFrankfurt 22:31, 11. Jan. 2008 (CET)

Sollte nach der Zusammenführung jetzt besser sein - Feedback ist erwünscht :-) Gruß, Darian (Diskussion) 01:06, 30. Aug. 2016 (CEST)

Funktion des Interrupts

Kommentar zum neuen Textteil: 'Eine weitere Funktion des Interrupts ist es, dass der Prozessor nach dem er eine Anfrage an eine Hardwarekomponente gesehndet hat nicht auf die Antwort warten muss, sondern in der Zwischenzeit andere Aufgaben erledigen kann.'

Das ist keine weitere Funktion, sondern die Kernfunktion des Interrupts. Der Prozessor kann auch keine Anfrage an eine Hardwarekomponente senden, sondern nur Daten einlesen oder ausgeben. Entsprechend wird von der Hardware nur ein Interrupt ausgelöst, wenn die nächste Operation auf dem Interface (Hardware) möglich ist - also bei Buffer leer (Ausgabe) oder Buffer voll (Eingabe). Ich würde den Satz nicht so stehen lassen. Dennoch wird ein wichtiger Punkt angesprochen. Wie wird der Interruptmechanismus - logisch gesehen - benutzt ? Wie ist er in das Gesamtsystem eingebunden. Allerdings wird es hier gleich sehr umfangreich, weil dann eigentlich der Punkt aus dem Text 'Warten auf die Fertigmeldung' der Hardware angesprochen werden muss. Damit käme eigentlich das ganze Semaphorensystem des Betriebssystems ins Spiel....20.Okt 2007 (RDIE)

Programmausführung im Interrupt ?

Kommentar zum Textteil 'Insbesondere bei hardwarenahen ereignisgesteuerten Anwendungen, wie sie z. B. in eingebetteten Systemen üblich sind, wird u. U. praktisch die gesamte Programmausführung des Systems in die Interrupt-Routinen (bzw. in von diesen angestoßene Tasks) verlegt.' Von der Softwarearchitektur ist es auf jeden Fall nicht sinnvoll gesammte Programmausführungen in die ISR zu legen. Das blockiert das System unnötig. Wenn man im ISR Kontext abarbeiten muss, verwendet man einen FORK Mechanismus, der z.B. über Queuing nach der Erstbearbeitung der Datenregister die Bearbeitung des Restes vor dem letzten 'Return from Tnterrupt' unter 'enable IRQ' wieder aufnimmt. Dann sind alle IRQs bearbeitet, aber noch nicht in den Mainstream zurückgekehrt. Selbstvertändlich muss das Queueing auch das Reentern dieses Teils der Abarbeitung verhindern, was relativ einfach möglich ist. Der theoretische Unterbau dazu ist etwas schwierig, die Realisierung jedoch aus eigener Erfahrung letztendlich mit wenigen instruktionen zu erledigen. Große Betriebssysteme haben ähnliche Mechanismen integriert. 15.Okt 2007 (RDIE)

All dies ist natürlich extrem vom jeweiligen Prozessor und dem (falls überhaupt vorhandenen) Betriebssystem abhängig. Die Bandbreite gerade bei Mikrocontrollern (4 bis 64 Bit breit, 256 Byte bis 16 MB RAM oder noch mehr) ist halt immens. Hat der Prozessor selbst überhaupt mehr als einen Interrupt? Zusätzlich kann man auch noch HW- und SW-Interrupts (Traps) unterscheiden. Ich kann mir nach meiner Erfahrung mit Mikrocontrollern durchaus Fälle vorstellen, in denen das OS aus einer winzigen Hauptschleife besteht, in der vielleicht irgendein Timer (Watchdog) gepflegt wird, und die eigentliche Arbeit erfolgt dann ausschließlich eventgesteuert nach Interrupt(s). Das ist bestimmt nicht die Regel, aber ich würde es nicht für ungewöhnlich halten. --PeterFrankfurt 01:10, 16. Okt. 2007 (CEST)

Ja, etwas abhängig vom Prozessortyp ist es schon. Donnoch sollte hier das 'saubere' Prinzip beschrieben werden und nicht exotische Sonderfälle. SW-Interrupts spielen hierbei keine Rolle, weil diese nicht durch externe Ereignisse ausgelöst werden können, sondern funktionell wie eine Subroutine anzusehen sind, auch wenn diese den gleichen Aufruf und Rücksprungmechanismus wie Interrupts benutzen (es sind keine!). Sobald ein Microcontroller einen Interrupteingang hat, könnte man darüber auch mit zusätzlicher Hardware Interruptvektoren einlesen und damit mehrere Quellen unterscheiden, auch wenn der Prozessor das nicht von Hause aus unterstützt.

Programmbearbeitungen unter Interruptkontext sind auf jeden Fall unsinnig, weil damit auch die Erkennung weiterer eigener Interrupts blockiert wird. Das Design des Kontrollflusses ist dann schlicht falsch. Im einfachsten Fall kann ein Singletasksystem eine Warteschleife laufen und den Datenbuffer (z.B.Ringbuffer) der Interruptroutine abfragen. Vorteil: die Bearbeitung erfolgt im Mainstream und kann dann auch andere Devices wie z.B. die Harddisk oder anderen I/O benutzen (auch Interruptgesteuert). Das geht sonst wegen Synchronisationsproblemen nicht! 20:40 16.Okt 2007 (RDIE)

Da denkst Du zu allgemein/kompliziert. Gerade im Mikrocontrollerbereich hat man es manchmal mit allereinfachsten Aufgabenstellungen zu tun. Heutzutage steckt in manchen Autos doch fast schon hinter jeder LED ein eigener Mikrocontroller. Die haben dann nur einen einzigen Interrupt und scheren sich nicht um hohe Theorie, bei der einfachen Struktur ist einfacher dann auch sicherer, da lässt man sogar aus Sicherheitsgründen jeden Overhead an OS weg. Da läuft die pure Anwendung und sonst fast nichts. --PeterFrankfurt 00:56, 17. Okt. 2007 (CEST)

Sorry, es handelt sich ja hier auch um einen allgemeinen Artikel, der die korrekte Lösung beschreiben soll und nicht unsinnige Sonderfälle pragmatischer Programmierer. Einen Interrupt, der nie zurückkehrt (RTI), braucht man nicht. Das kann man dann durch Polling genausogut erledigen. Das ist im Microcontrollerbereich bei geschickter Auslegung auch noch schneller. Ein Singletasksystem braucht übrigens auch kein OS zu sein, sondern dazu reicht eine Programmschleife. Es spricht ja auch in der Theorie nichts dagegen die LED in der ISR einzuschalten - aber danach ? Rücksprung... 17.Okt 2007 (RDIE)

Natürlich Rücksprung, aber oft in eine weitgehend leere Idle-Schleife. Und zum allgemeinen Artikel: Gerade darum darf man doch nicht alles auf ein einzelnes Konstruktionsprinzip einengen. Und wenn ich mir die Stückzahlen ansehe, die bei solchen Mikrocontrollern in Autos oder noch einfacheren Haushaltsgeräten anfallen, dann sind das womöglich keineswegs Sonderfälle, sondern die große Mehrheit... Wie gesagt, es gibt beides, man darf nur nichts davon als "unsinnig" unberechtigterweise ausschließen. --PeterFrankfurt 02:03, 18. Okt. 2007 (CEST)

Dann ist die Welt ja wieder in Ordnung. Der Interrupt des Microcontrollers springt auch wieder zurück und der Mainstreamcode besteht aus nur einer Schleife. Ich kann darin nur die Bestätigung des Interrupt-Softwaremodells sehen. Welches andere Konstruktionsprinzip gibt es denn noch ? 18.Okt 2007 (RDIE)

Der "Mainstreamcode" besteht nicht lediglich bloß aus einer Schleife, sondern idealerweise auch aus einer Schlaffunktion, die den Mikrocontroller schlafen legt, bis ein Interrupt ihn wieder aus dem Schlaf holt. Denn das spart Energie und ist besser als nur eine Schleife. --84.158.122.178 23:27, 6. Jan. 2022 (CET)

256 IRQs

Hier steht, es gibt insgesamt 256 Interrupts... Sind diese Interrupts 256 fest vorgeschriebene, "eingebrannte" Routinen, oder kann man seine eigenen Interrupts schreiben? Danke, --Abdull 22:25, 19. Apr 2005 (CEST)

Man kann seine eigenen Interrupts schreiben! Aber das Betriebssystem legt eine Schale drumrum (Stichwort protected mode). --HartmutS 00:57, 12. Feb 2006 (CET)

Nicht, wenn man in DOS Arbeitet (stichwort Real Mode). Allerdings gibt es sehr wohl interrupts, die für bestimmte Aufgaben reserviert sind, z.B. die Interrupts, welche den IRQs entsprechen oder Int 19h. Btw, Interrupts sind nicht das selbe wie IRQs, es gibt 256 Interrupts (00h-FFh), aber nur 16 IRQs (0-15, man könnte aber auch statt dessen 0h-Fh schreiben. Diese IRQs entsprechen den Interrupts 69h-77h). --MrBurns 23:23, 16. Okt. 2007 (CEST)

Der Einwand 256 Interrupts... ist richtig. Genaugenommen muss es heißen '256 verschiedene Interruptvektoren'. Die Vektoren sind übrigens nicht die indirekten Einsprungadressen. Der Vektor wird im REAL Mode mit 4 multipliziert, damit für jeden Vektor 32 Bit Sprungadressen untergebracht werden können. Im Protected Mode mit 8, weil ein Descriptoreintrag 8 Bytes lang ist. Der Vektor wird im Interruptzyklus als Zahl über den Datenbus entgegengenommen und im Falle von PCs vom Interruptcontroller geliefert. Dieser ermöglicht dann die 15 IRQs als externe Signale (IRQ 2 wird für die Kaskadierung benötigt). Die Vektoren 0-31 sind INTEL-reserved und teilweise mit Prozessor-TRAPS und Exeptions belegt. Alle Vektoren können über Softwareinterruptaufrufe (INT n) benutzt werden, z.B. zu Testzwecken. DOS hat einen Teil dieser Aufrufe als Betriebssystemeinsprünge benutzt. 17.Okt 2007 (RDIE)

Dass die ersten 31 Interrupts alle reserved (das bedeutet im Prinzip unbenutzt) sind halte ich für ein Gerücht. Z.B. erfüllen die Interrupts 19h (=25) und 13h (=19) wichtige Funktionen. Für letzeren gibst sogar einen Artikel bei der englischen Wikipedia. Es gibt irgendwo eine Seite, wo alle mlöglichen interrupt-Aufrufe aufgelistet sind (also nicht nur die Vektoren), aber ich hab die URL vergessen. --MrBurns 02:52, 22. Jan. 2010 (CET)

PS: Ich hab die Seite gefunden: [1]. Es handelt sich um Ralf Brown's Interrupt List. --MrBurns 03:43, 22. Jan. 2010 (CET)

latein ?

Warum wird hier, daß das Wort aus dem Lateinischen kommt. Das deutsche Fachwort Interrupt kommt doch aus dem Englischen.

Aber es ist richtig und informativ, dass auch im Latein von Interrupt geredet wird! --HartmutS 00:57, 12. Feb 2006 (CET)

Interrupt kommt aber sicher vom englischen, weil to interrupt heißt auf englsich unterbrechen und wie wohl jedem bekannt ist kommt die x86-Architektur genauso wie so ziemlich jede andere Computerarchitektur aus Amerika. --MrBurns 23:26, 16. Okt. 2007 (CEST)

Hier könnte einiges mehr stehen, in bezug auf andere Prozessoren als die X86-Architektur. Interrupts sind insbesondere im Bereich der embedded- oder Automatisierungsgeräte interessant. Bezug auf Realtime-Betriebssysteme usw. Der Artikel ist noch ausbaufähig. --HartmutS 00:57, 12. Feb 2006 (CET)

Interrupt Controller

Der Interrupt Controller löst die Interrupts nicht aus. Er kümmert sich lediglich darum, dass Interrupts mit verschiedenen Prioritäten korrekt (d.h. in der richtigen Reihenfolge) abgearbeitet werden.

Das tut er, indem er im Interruptzyklus die entsprechenden Vektoren auf den Datenbus legt. Damit der Interruptzyklus ausgelöst wird, muss der Controller (INTEL Systeme) selbstverständlich das Interruptsignal am CPU Eingang setzen, den Interrupt also auslösen. Allerdings hat er natürlich seinerseits vorher entsprechende Fertigsignale von den angeschlossenen Geräten bekommen, die ihn dazu veranlassen. (24.10.2007 RDIE)

Diesem Einwand kann ich nur zustimmen. Im Artikel entsteht der Eindruck, dass jedes interruptfähige Gerät über einen Interruptcontroller verfügen muss. Dieser existiert jedoch i.d.R. nur einmal im System und arbeitet Interrupts ab. -- Johann Uhrmann 11:58, 6. Jan. 2009 (CET)

Maskierte Interrupts?

Was bedeutet es, wenn ein Interrupt "maskiert" ist? -- 84.141.243.127 23:23, 2. Okt 2006 (CEST)

Ach, hab's gerade selber herausgefunden. Wenn man nur bestimmte Interrupts zulassen will, muss man eine Maske aus einzelnen Bits erstellen, die angeben, ob die verschiedenen Interrupts gesperrt sind, oder nicht. Nicht maskierbare Interrupts lassen sich nicht softwareseitig sperren. Das könnte dem Artikel eventuell noch hinzugefügt werden. -- 84.141.243.127 02:36, 3. Okt 2006 (CEST)

Interrupt und BIOS

Insbesondere früher, als USB und so noch nicht so verbreitet war, hörte man den Begriff „Interrupt“ im Zusammenhang mit dem Einbau von ISA- oder PCI-Erweiterungen in Rechner. Dabei hieß es oft (so oder so ähnlich), dass eine Hardware-Karte soundsoviel Interrupts belegt bzw. das durch Umjumpern ein Interrupt freigegeben werden kann. Diese Interrupt haben verschiedene Nummern.

Ich habe nie verstanden, was es mit diesen Interrupts auf sich hat. Gibt es ein System zwischen Prozessor und den Slots, das eventuelle IRQs der Kartenhardware an den Prozessor weiterreicht? Wie ist dieses System standardisiert? Warum kann eine Hardware auch benutzt werden, wenn auf den Interrupt verzichtet wird? Was bedeutet der in diesem Zusammenhang auftretende Begriff vom Teilen der Interrupts?

Werden die IRQs direkt an den Prozessor weitergereicht?

Oder ist das ganze ein System von Softwareinterrupts (im Sinne von Systemaufrufen über einen IRQ-Mechanismus bzw. SW-Traps), über die die Treibersoftware mit der Hardware zusammenarbeitet?

(Was) hat es mit Interruptnummern zu tun, die man manchmal in BIOS-Einstellungen sieht („Festplatte schreiben über Interrupt 0xXY“, oder so ähnlich).

Insgesamt habe ich den Eindruck, dass im Bereich der BIOS-Terminologie das Wort „Interrupt“ bzw. „Interrupt Request“ (IRQ) in einem leicht anderen, wenn auch nicht komplett anderen, Zusammenhang als dem hier im Artikel genannten (der mir durchaus geläufig ist) gebraucht wird.

-- Pemu 18:04, 31. Jan. 2007 (CET)

Der Interruptvektor und die IRQ Nummer sind von einander unabhängige Zahlen. Das Betriebssystem trägt in den Interruptcontroller eine Vektornummer für den IRQ 0 des Controllers ein, die restlichen ergeben sich dann aus der Summe IQR0-Vektor+IQR. Ein Interruptcontroller verwaltet 8 Interruptanforderungseingänge. IRQ8-15 laufen über IRQ2. IRQ2 ist damit der Sammelinterrupt für IRQ8-15. (Master-Slave-Verschaltung). .. sprach Mr. Unsigniert

Gibt es ein System zwischen Prozessor und den Slots, das eventuelle IRQs der Kartenhardware an den Prozessor weiterreicht? Dieses System heißt PC-Interruptcontroller. Warum kann eine Hardware auch benutzt werden, wenn auf den Interrupt verzichtet wird? Dies ist in den meisten Fällen nicht sinnvoll möglich. Manche Geräte können auch per Polling betrieben werden, z.B. der Druckerport. Manche Geräte benutzen Interrupts nur für Spezialzwecke, wie z.B. manche Grafikkarten. Was bedeutet der in diesem Zusammenhang auftretende Begriff vom Teilen der Interrupts? Dies bedeutet, daß verschiedene Geräte ihre Interrupts über dieselbe Signalleitung anmelden. Da die ISA-Schrotti-Technik dafür elektrisch nicht ausgelegt war, funktionierte die Angelegenheit nicht. Daher gab es mehrere Leitungen, von denen jede Karte genau eine erhalten mußte, und ein lustiges Konfigurationspuzzle. Oder die IRQ-Leitung wurde trotzdem gesharet, dann war aber gleichzeitiger Betrieb unmöglich (waren nicht COM1 und COM3 standardmäßig auf demselben Interrupt? Urgh). Die Nummern (IRQ0 bis IRQ7, bei ISA-16 bis IRQ15) sind die Signalnummern am PIC/an den PICs (Programmable Interrupt Controller). Sollte das nicht alles unter ISA und PIC stehen? (Was) hat es mit Interruptnummern zu tun, die man manchmal in BIOS-Einstellungen sieht („Festplatte schreiben über Interrupt 0xXY“, oder so ähnlich). 0x13? 0x13 ist der BIOS-Software-Interrupt zum Lesen und Schreiben von Sektoren. IDE-Controller haben natürlich auch einen Interrupt im obigen Sinne, normalerweise IRQ14 und IRQ15. --88.74.189.122 21:29, 28. Dez. 2009 (CET)

Ausführlichkeit der beschreibung

Die Ausführlichkeit der Beschreibung ist doch etwas mager. Bitte bei der weiteren Ergänzung an der Englischen Version orientieren, die ist wirlich super: http://en.wikipedia.org/wiki/Interrupt

Z.B. habe ich vermisst dass nichts über level triggered oder edge triggered drinsteht.

Edge- und leveltriggered sind Spezialitäten des (UR-) Interruptcontrollers, die wohl aus Kompatibiltätsgründen geblieben sind. Edge detektiert die Änderungen am Eingang. Das sieht zwar einfach aus, hat aber Probleme, weil der Interrupt auch gelöscht werden muss. Wenn in die kleine Zeitlücke zwischen Erkennung und Löschung ein neuer Interrupt fällt, wird dieser mit gelöscht. Bei 'level' kann das nicht passieren, weil er danach immer noch ansteht. Bei Level ist das Problem, wenn die Quelle des Interrupt nicht bekannt ist und nicht abgeschaltet werden kann... Besonders schwierig wird es, wenn - wie heute üblich - mehrere Devices auf einem Interrupteingang arbeiten. Spezielle Softwarekonzepte sind möglich, um diese Probleme abzufangen. Deshalb haben Betriebssystemhersteller diesen Mechanismus im System integriert und erlauben Treibern teilweise nur noch über Schnittstellen zuzugreifen. 20:40 16.Okt 2007 (RDIE)

Fuer x86-PCs kann ich nur diese einzigartige Quelle empfehlen : http://www.cs.cmu.edu/~ralf/files.html - das Ding ist fuer hardware- und/oder systemnahes Programmieren Gold wert, was fuer CP/M und z80-Asm der Rodnay Zaks ist, ist Ralf Braun fuer IMB-PCs in allen Varianten. Sollte man das hier vielleicht verlinken, auch wenn die Begriffserklaerung Interrupt ja eigentlich systemunabhaengig ist? -- 194.126.228.2 17:34, 22. Mär. 2013 (CET)

Überarbeiten

Der Abschnitt Maskierbarer Interrupt sollte nochmal durchgegangen werden. 1. Sollte erkärt werden, sofern es kein Fehler ist, warum der Pin "meistens mit NMI bezeichnet" ist. 2. ist diese Beschreibung IMHO viel zu x86-spezifisch. -- Pemu (Diskussion) 00:11, 1. Jul. 2020 (CEST)

Der ganze Abschnitt ist Müll, da falsch bzw. völlig am Thema vorbei. Eigentlich sollte da erst einmal stehen, was ein maskierbarer Interrupt ist. Ich kenne übrigens die Antwort, aber ich werde den Artikel nicht verbessern. Stattdessen setze ich meinen Counter weiter hoch. --84.158.117.10 19:28, 28. Apr. 2023 (CEST)

Scheduling & Multitasking

Ich möchte diese Änderungen von ​Hasimaus kritisieren. Dabei bin ich sogar soweit gegangen, die (manuelle) Sichtung zurückzunehmen.

• Die Änderung von "Programm" auf "Prozess" ist viel zu einschränkend. Ein Programm muss keinesfalls ein Prozess sein, damit es durch einen IRQ unterbrochen werden kann. Im Gegenteil: Ich würde eigentlich statt "Programm" sogar eher "Maschinencode" schreiben. (Uneigentlich aber finde ich, dass der Text dadurch unnötigerweise unverständlicher würde.)
• "um einem anderen den Vorgang einzuräumen": Hier wird eher das beschrieben, was eine Prozess-Scheduler macht. Dass er dazu mit Interrupts arbeitet, steht auf einem anderen Blatt, aber es ist nicht der wesentliche Kern von Interrupts.
• "Betriebssysteme, die mit Interrupts arbeiten, werden aufgrund dieser Fähigkeit "prä-emptiv" genannt." Das ist falsch. Das OS meines C-64 arbeitet mit Interrupts. Es aber daher als "präemptiv" zu bezeichnen, geht sicherlich (nicht gerade nur um Haaresbreite) an der Bedeutung von präemptiv vorbei.
• "Hardware-Interrupts […] sind prinzipiell als konkrete Ereignisse nicht reproduzierbar." Warum? Vor allem: Warum "prinzipiell"? Sowas wie "Hardware-Interrupts […] sind im Allgemeinen als konkrete Ereignisse nicht ohne Weiteres reproduzierbar" fände ich richtiger – aber (dito bei "Software-Interrupts sind reproduzierbar"): Was soll diese Info dem Leser hier bringen?
• "Software-Interrupts entstehen, wenn ein Prozess (bzw. ein Programm) sich selbst unterbricht, um eine Unterbrechungsroutine des Betriebssystems zu starten, die eine elementare Funktion, wie etwa Ein- oder Ausgabe, durchführt."
  • sich selbst unterbrechen – krude Bezeichnung für das, was bei einem Unterprogrammaufruf passiert.
  • "eine Unterbrechungsroutine des Betriebssystems": Darunter würde ich eine Interrupt-Service-Routine (für einen HW-Int.) verstehen. Technisch gesehen ist es natürlich eine Unterbrechungsroutine, aber: Ich finde (habe jetzt leider keinen Beleg zur Hand), dass Software-Interrupt ein unglücklicher Name für einen Mechanismus ist, der von den internen Vorgängen her eine Ähnlichkeit mit Hardware-Interrupts hat. Dass die Prozessor-Architekten daher das Ganze "Software-Interrupt" nennen, finde ich nachvollziehbar. De-facto ist es aber aus der Sicht von höheren Ebenen her eine Art, einen Unterprogrammaufruf (bzw. üblicherweise: einen Systemaufruf) durchzuführen.

Der Name ist nun aber da und daher sollte man das auch hier behandeln – natürlich so, dass man die Gründe für den Namen Software-Interrupt nachvollziehen kann.

-- Pemu (Diskussion) 01:41, 1. Nov. 2020 (CET)

Hallo, zunächst hat du bezüglich präemptiv natürlich recht. Für präemptives Multitasking werden Interrupts benötigt, aber nur weil ein Betriebssystem mit Interrupts arbeitet ist es noch lange nicht präemptiv.

Zur Bezeichnung Programm, Prozess oder Maschinencode, so beschreiben Programm und Maschinencode eine Folge von Anweisungen (und z.B. feste Daten). Es wird jedoch nicht die Folge von Anweisungen unterbrochen, sondern eine Instanz der Anweisungen (mit eigenem Stack etc). Ein Prozess (Informatik) ist genau so eine Instanz eines Programms.

Bezüglich "um einem anderen den Vorgang einzuräumen": Der andere Vorgang wäre hier z.B. der Prozess-Scheduler, es könnte aber auch IO-Verarbeitung sein. Nicht gemeint ist ein anderer userspace Prozess.--BlauerBaum (Diskussion) 12:48, 1. Nov. 2020 (CET)

Zu dem "Prozess": Ein Prozess ist ja eine vergleichsweise High-Level-Datenstruktur. Aber selbst wenn der Prozessor (bspw. durch einen Bug) auf (zufällig ausführbaren, also nicht Illegal-Instruction-Exceptions auslösenden) Datenmüll gelangt, ändert das nichts an den Mechanismen der Interruptausführung.

Und die kümmert sich nicht um Prozesse: Es wird natürlich eine Folge von Anweisungen unterbrochen (sofern nicht, etwa als kritischer Bereich, davor geschützt). Oder was meinstest Du mit "Es wird jedoch nicht die Folge von Anweisungen unterbrochen", ​BlauerBaum?

-- Pemu (Diskussion) 00:42, 3. Nov. 2020 (CET)

Also ich beziehe mich auf diese Gesamtänderung: [2]. Wenn der Interrupt abgearbeitet wird, so wird an eine vorgegebene stelle gesprungen (in der Regel in den Code des Kernel) und von dort aus arbeitet die CPU weiter. Das ist dann aber kein Prozess, sondern ein Vorgang. Die Änderung von Programm auf Prozess ist denke ich korrekt, da ja nicht das Programm (z.B. /usr/bin/ls), sondern ein Prozess (z.B. ein Prozess mit PID 100 welcher das Programm /usr/bin/ls ausführt) unterbrochen wird.--BlauerBaum (Diskussion) 11:34, 3. Nov. 2020 (CET)

Verstehe – und sehe die Schwäche des alten Texts. Daher kam auch meine Idee mit "Maschinencode". Ich verstehe hier Programm einfach als Folge von Anweisungen (eben den Maschinencode). "Programm" im Sinne von Anwendung (hm – damit ls darunter fällt, muss man das Wort auch etwas großzügig auslegen) ist sicherlich ein Holzweg. -- Pemu (Diskussion) 00:04, 4. Nov. 2020 (CET)

Gerade ist mir aufgefallen, dass da ein Beleg steht – vorher wie nachher, obgleich so mirnichtsdirnichts der Text geändert wurde. Bei Einfügung sah das so aus. Diese Formulierung ("kurzfristige Unterbrechung der normalen Programmausführung") umschifft die von mir gesehenen Probleme, so dass ich sie gleich einfach mal einfügen werde. Und noch ein @ an den damaligen Mitautoren ​MartinThoma. -- Pemu (Diskussion) 00:18, 4. Nov. 2020 (CET)

Die Sache mit den SW-Interrupts habe ich, wie ich finde, verbessert.

Falls es nicht falsch dargestellt ist, würde ich folgende Begründung für die Benutzung von SW-Interrupts ggü. Jump to Subroutine bei Systemaufrufen einbauen:

"So implementieren einzelne Betriebssysteme Systemaufrufe. Im Gegensatz zu Unterprogrammaufrufen erfolgt dabei eine für den Systemaufruf ggf. notwendige Ausweitung der Rechte im Kontext des Programms, ohne dass das Programm dadurch eigenen Code unter erweiterten Rechten ausführen kann."

Meinungen? -- Pemu (Diskussion) 00:57, 4. Nov. 2020 (CET)

Ich denke so ist es recht gut. "normale Programmausführung" beschreibt das gemeinte recht gut, insbesondere nicht nur für moderne Betriebssysteme sondern auch für Mikrocontroller und ähnliches.--BlauerBaum (Diskussion) 19:53, 4. Nov. 2020 (CET)

Gleichzeitiges Anlegen einer Interruptnummer durch zwei verschiedene Geräte

Im Artikel heißt es:
"Erscheint an diesem meistens mit NMI bezeichnete Pin ein Signal ([Vcc]) während Interrupts aktuell nicht maskiert sind (bei x86 ist dann das Interrupt-Flag (IF) gesetzt), so maskiert die CPU alle maskierbaren Interrupts und liest die Nummer des angeforderten Interrupts vom Systembus (Intel64-Hardware unterscheidet 256 Interrupt-Nummern). Dort muss der Anforderer die Nummer vor der Anforderung anlegen."
Falls ich mich nicht irre, sollte man vielleicht im Artikel erwähnen, dass es nicht möglich ist, dass zwei Geräte zur gleichen Zeit ihre gewünschte Interrruptnummer im Systembus ablegen können, denn sonst könnte Gerät B die angelegte Interruptnummer von Gerät B überschreiben, bevor Gerät B der CPU Bescheid sagt.
Wenn ich mich nicht irre, dann darf nur ein Gerät den Systembus zu selben Zeit nutzen, womit eine Synchronisierung und atomare Operation sichergestellt wäre und das Problem somit nicht auftreten kann. Falls das nicht der Fall sein sollte, dann sollte man im Artikel erklären, wie dieses Problem behandelt wird. --84.158.122.178 21:39, 6. Jan. 2022 (CET)

Erfolgt an einem x86 am NMI (Non-maskable interrupt) ein Signal so wird der INT 2 ausgelöst. Für die nicht maskierbaren Interrupts gibt es die Leitung INTR (Interrupt Request). An diesem hängt beim IBM PC ein Intel 8259. später hat man eine Kaskade an eine Leitung gebaut. Theoretisch kann man mit 9 8259 Chips 64 Hardwareinterrupts sich selbst verdrahten. --79.206.196.40 13:56, 20. Aug. 2023 (CEST)