THEORIE: Wie kann ein inaktiver Prozess agieren?

Hallo Experten :wink:
Ich hab ne etwas abgedrehte Frage glaub ich. Wir sind in der theoretischen Informatik!
Also, ein Prozess (Task, in dem Falle ja egal) bekommt ja vom Kernel (Betriebssystem) „Zeitscheiben“ in denen er rechnen darf. Wenn dabei etwas gravierend schief geht „wirft“ er einen Interrupt (oder eine Exception, was ja in diesem Zusammenhang unerheblich ist). In dem Falle schreibt er eine Fehlermeldung in einen speziellen Speicherbereich, richtig? Diese wird dann von der entsprechenden Serviceroutibe des OS bearbeitet. Dazu „lĂ€sst das OS alles stehen und liegen“ und kĂŒmmert sich darum. Soweit ist mir das glaub ich klar (verbessert mich, wenn ich hier Blödsinn schreibe)

Theoretisch tut der Prozess das auch wenn ein Fehler auftritt, der Prozess aber gerade keine Zeitscheibe hat.(Asynchrone Interrupts/Exceptions).
Jetzt meine Frage: Wie? Ist der Prozess, wenn er gerade nicht rechnen darf nicht „handlungsunfĂ€hig“?

Vielen Dank schonmal im vorraus fĂŒr hilfreiche Antworten :smile:

Liebe GrĂŒĂŸe aus Frankfurt
Seelchen

Tut mir leid, aber da habe ich keine Antwort drauf.

LG
kaski

Guten Rutsch

Kernel (Betriebssystem) „Zeitscheiben“ in denen er rechnen
darf.

Bis dahin klingt das schonmal vernĂŒnftig.

Wenn dabei etwas gravierend schief geht „wirft“ er einen
Interrupt (oder eine Exception, was ja in diesem Zusammenhang
unerheblich ist). In dem Falle schreibt er eine Fehlermeldung
in einen speziellen Speicherbereich, richtig? Diese wird dann
von der entsprechenden Serviceroutibe des OS bearbeitet. Dazu
„lĂ€sst das OS alles stehen und liegen“ und kĂŒmmert sich darum.

Das macht ein Betriebssystem generell wenn ein Interrupt aufgerufen wird. Wobei Interrupt und Exception nicht exakt das selbe sind.

Soweit ist mir das glaub ich klar (verbessert mich, wenn ich
hier Blödsinn schreibe)

Theoretisch tut der Prozess das auch wenn ein Fehler auftritt,
der Prozess aber gerade keine Zeitscheibe hat.(Asynchrone
Interrupts/Exceptions).
Jetzt meine Frage: Wie? Ist der Prozess, wenn er gerade nicht
rechnen darf nicht „handlungsunfĂ€hig“?

Da scheint mir ein Fehler drin zu sein. Asynchrone Interrupts können nur von externen IO Quellen ausgelöst werden. Ein Prozess der gerade nicht rechnet kann natĂŒrlich keinen Fehler haben. Der wartet bestenfalls darauf bald einen zu machen.

Trotzdem danke :smile:

hoffe, du bist schon gut gerutscht :smile:

[Bei dieser Antwort wurde das Vollzitat nachtrÀglich automatisiert entfernt]

Hallo Björn,
danke fĂŒr die schnelle Antwort und ein frohes neues erstmal :smile:

Wobei Interrupt und Exception nicht exakt das
selbe sind.

Technisch gesehen doch schon, oder irre ich mich?
Eine Exception ist ja (soweit ich das verstanden habe) ein „spezieller“ Interrupt
oder nich?

Da scheint mir ein Fehler drin zu sein. Asynchrone Interrupts
können nur von externen IO Quellen ausgelöst werden. Ein
Prozess der gerade nicht rechnet kann natĂŒrlich keinen Fehler
haben. Der wartet bestenfalls darauf bald einen zu machen.

Also, wenn ein Prozess, der grade nicht rechnen darf von einem „IO-GerĂ€t“ einen Fehler bekommt (z.b. beim brennen geht was in die Hose) wartet er mit dem „schreiben“ des Interrupt (in diesem Falle meistens der Exception :wink: ) bis er wieder „darf“?

Folglich gibt das Device eine Art „vor-interrupt“ an der Prozess weiter, der der dann baldmöglichst bearbeitet?
Oder merkt der Prozess das erst, wenn beim nÀchten schreib/lese-Zugriff was nicht passt?

Liebe GrĂŒĂŸe
Seelchen

Hallo Björn,
danke fĂŒr die schnelle Antwort und ein frohes neues erstmal :smile:

Ebenso

Wobei Interrupt und Exception nicht exakt das
selbe sind.

Technisch gesehen doch schon, oder irre ich mich?
Eine Exception ist ja (soweit ich das verstanden habe) ein
„spezieller“ Interrupt
oder nich?

Du schreibst es ja selber. Es ist eine spezielle Form von Interrupt. Das heisst es gibt auch Interrupts die keine Exception darstellen.

Da scheint mir ein Fehler drin zu sein. Asynchrone Interrupts
können nur von externen IO Quellen ausgelöst werden. Ein
Prozess der gerade nicht rechnet kann natĂŒrlich keinen Fehler
haben. Der wartet bestenfalls darauf bald einen zu machen.

Also, wenn ein Prozess, der grade nicht rechnen darf von einem
„IO-GerĂ€t“ einen Fehler bekommt (z.b. beim brennen geht was in
die Hose) wartet er mit dem „schreiben“ des Interrupt (in
diesem Falle meistens der Exception :wink: ) bis er wieder „darf“?

Nein. Der Interrupt wird in diesem Fall nicht von einem im Kernel laufenden Prozess ausgelöst sondern von einem externen GerĂ€t. Die CPU entscheidet dann was mit diesem Interrupt zu tun ist und ĂŒbergibt ihn dann möglicherweise an einen Prozess.
Beispiel: Du hast da eine Tastatur angeschlossen. Da gibt es 2 Möglichkeiten die Abzufragen. Entweder ich frag regelmĂ€ssig bei der Tastatur nach ob eine Eingabe vorliegt oder ich erlaube der Tastatur einen HW Interrupt zu machen und entscheide sobald jemand auf der Tastatur eine Taste drĂŒckt was ich mit dem einkommen Interrupt zu tun habe.

Folglich gibt das Device eine Art „vor-interrupt“ an der
Prozess weiter, der der dann baldmöglichst bearbeitet?
Oder merkt der Prozess das erst, wenn beim nÀchten
schreib/lese-Zugriff was nicht passt?

Ich hab ja oben ein Beispiel. Du scheinst Interrupt immer nur als ein von einem Prozess ausgelösten Fehler zu verstehen. Noch ein Beispiel:
Ein Braten ist im Ofen wÀhrend im Wohnzimmer eine nette Runde zusammen sitzt und sich angeregt unterhÀlt. Jetzt gibt es 2 Möglichkeiten:

  • Die Hausfrau guckt minĂŒtlich nach dem Braten und guckt ob er fertig ist. DafĂŒr muss jedesmal ein Guck-nach-dem-Braten-Prozess angeworfen werden.
  • Der Ofen meldet sich durch piepsen wenn der Braten fertig ist. Das lösst einen Interrupt aus, das Programm fröhliche Unterhaltung wird unterbrochen, die Meldung Ofen piepst wird an die Hausfrau weitergegeben und sie setzt dadurch den Prozess Guck-nach-dem-Braten in Gang.

Du musst dich von dem Fehler Gedanken etwas lösen. HÀufig sind ausgelöste HW-Interrupts eher was gutes und erwartetes als ein Fehler.

Hallo, ja es ist so, keine Rechenmöglichkeit = keine HandlungsfĂ€higkeit. Ausser ein andere Process hat die Kontrolle ĂŒber diesen. Bei den RealTime Systemen ist dies ein wenig anders.
Gruss