Siehe: Den Linux-Kernel verstehen , 3. Auflage von Daniel P. Bovet, Marco Cesati
- Herausgeber: O'Reilly
- Veröffentlichungsdatum: November 2005
- ISBN: 0-596-00565-2
- Seiten: 942
In ihrer Einführung sagten Daniel P. Bovet und Marco Cesati:
Technisch gesehen ist Linux ein echter Unix-Kernel, obwohl es kein vollständiges Unix-Betriebssystem ist, da es nicht alle Anwendungen wie Dateisystemdienstprogramme, Windows-Systeme und grafische Desktops, Systemadministratorbefehle, Texteditoren, Compiler usw. enthält auf. Was Sie in diesem Buch lesen und im Linux-Kernel sehen, kann Ihnen daher helfen, auch die anderen Unix-Varianten zu verstehen.
In den nächsten Abschnitten werde ich versuchen, Ihre Sichtweisen auf der Grundlage meines Verständnisses auf die Tatsachen zu beziehen, die in "Den Linux-Kernel verstehen" dargestellt werden und weitgehend denen in Unix ähneln.
Was ist ein Prozess? :
Prozesse sind wie Menschen, sie werden erzeugt, sie haben ein mehr oder weniger bedeutendes Leben, sie erzeugen wahlweise einen oder mehrere untergeordnete Prozesse und sie sterben schließlich. Ein Prozess besteht aus fünf grundlegenden Teilen: Code ("Text"), Daten (VM), Stapel, Datei-E / A und Signaltabellen
Der Zweck eines Prozesses im Kernel besteht darin, als Entität zu fungieren, der Systemressourcen (CPU-Zeit, Speicher usw.) zugewiesen werden. Wenn ein Prozess erstellt wird, ist er fast identisch mit seinem übergeordneten Prozess. Es empfängt eine (logische) Kopie des Adressraums des übergeordneten Elements und führt den gleichen Code wie das übergeordnete Element aus, beginnend mit der nächsten Anweisung nach dem Prozesserstellungssystemaufruf. Eltern und Kinder können zwar die Seiten gemeinsam nutzen, die den Programmcode (Text) enthalten, sie haben jedoch separate Kopien der Daten (Stapel und Haufen), sodass Änderungen, die das Kind an einem Speicherort vornimmt, für die Eltern unsichtbar sind (und umgekehrt). .
Wie funktionieren Prozesse?
Ein ausführendes Programm benötigt mehr als nur den Binärcode, der dem Computer mitteilt, was zu tun ist. Das Programm benötigt zum Ausführen Speicher und verschiedene Betriebssystemressourcen. Ein "Prozess" ist das, was wir ein Programm nennen, das zusammen mit allen Ressourcen, die es zum Betrieb benötigt, in den Speicher geladen wurde. Ein Thread ist die Ausführungseinheit innerhalb eines Prozesses. Ein Prozess kann von nur einem Thread bis zu mehreren Threads reichen. Wenn ein Prozess gestartet wird, werden ihm Speicher und Ressourcen zugewiesen. Jeder Thread im Prozess teilt diesen Speicher und diese Ressourcen. In Single-Thread-Prozessen enthält der Prozess einen Thread. Der Prozess und der Thread sind ein und derselbe, und es passiert nur eins. In Multithread-Prozessen enthält der Prozess mehr als einen Thread, und der Prozess führt eine Reihe von Dingen gleichzeitig aus.
Die Mechanik eines Multi-Processing-Systems umfasst leichte und schwere Prozesse:
In einem Schwergewichtsprozess laufen mehrere Prozesse gleichzeitig ab. Jeder parallele Schwergewichtsprozess verfügt über einen eigenen Speicheradressraum. Die Kommunikation zwischen Prozessen ist langsam, da Prozesse unterschiedliche Speicheradressen haben. Ein Kontextwechsel zwischen Prozessen ist teurer. Prozesse teilen den Speicher nicht mit anderen Prozessen. Die Kommunikation zwischen diesen Prozessen würde zusätzliche Kommunikationsmechanismen wie Sockets oder Pipes beinhalten.
In einem leichten Prozess auch Threads genannt. Threads werden verwendet, um die Arbeitslast zu teilen und zu teilen. Threads verwenden den Speicher des Prozesses, zu dem sie gehören. Die Kommunikation zwischen Threads kann schneller sein als die Kommunikation zwischen Prozessen, da Threads desselben Prozesses gemeinsam mit dem Prozess, zu dem sie gehören, Speicher nutzen. Dadurch ist die Kommunikation zwischen den Threads sehr einfach und effizient. Das Wechseln des Kontexts zwischen Threads desselben Prozesses ist kostengünstiger. Threads teilen den Speicher mit anderen Threads desselben Prozesses
Es gibt zwei Arten von Threads: Threads auf Benutzerebene und Threads auf Kernelebene. Threads auf Benutzerebene meiden den Kernel und verwalten die Arbeit selbstständig. Threads auf Benutzerebene haben das Problem, dass ein einzelner Thread die Zeitscheibe monopolisieren kann, wodurch die anderen Threads innerhalb der Task ausgehungert werden. Threads auf Benutzerebene werden normalerweise über dem Kernel im Benutzerbereich unterstützt und ohne Kernelunterstützung verwaltet. Der Kernel weiß nichts über Threads auf Benutzerebene und verwaltet sie so, als wären sie Single-Thread-Prozesse. Daher sind Threads auf Benutzerebene sehr schnell und arbeiten 100-mal schneller als Kernel-Threads.
Threads auf Kernel-Ebene werden häufig mit mehreren Tasks im Kernel implementiert. In diesem Fall plant der Kernel jeden Thread innerhalb der Zeitscheibe jedes Prozesses. In diesem Fall ist es weniger wahrscheinlich, dass eine Task die Zeitscheibe von den anderen Threads innerhalb der Task blockiert, da der Takt die Schaltzeiten bestimmt. Threads auf Kernel-Ebene werden direkt vom Betriebssystem unterstützt und verwaltet. Die Beziehung zwischen Threads auf Benutzerebene und Threads auf Kernelebene ist nicht vollständig unabhängig. Tatsächlich besteht eine Wechselwirkung zwischen diesen beiden Ebenen. Im Allgemeinen können Threads auf Benutzerebene mit einem von vier Modellen implementiert werden: Many-to-One-, One-to-One-, Many-to-Many- und Two-Level-Modelle. Alle diese Modelle ordnen Threads auf Benutzerebene Threads auf Kernelebene zu und bewirken eine unterschiedlich starke Interaktion zwischen beiden Ebenen.
Themen vs. Prozesse
- Das Programm startet als Textdatei mit Programmcode.
- Das Programm wird kompiliert oder in binäre Form interpretiert.
- Das Programm wird in den Speicher geladen,
- Das Programm wird zu einem oder mehreren laufenden Prozessen.
- Prozesse sind in der Regel unabhängig voneinander,
- Während Threads als Teilmenge eines Prozesses existieren.
- Threads können einfacher miteinander kommunizieren als Prozesse.
- Threads sind jedoch anfälliger für Probleme, die von anderen Threads im selben Prozess verursacht werden
Verweise:
Grundlegendes zum Linux-Kernel, 3. Ausgabe
Mehr 1 2 3 4 5
...............................................
Vereinfachen wir nun alle diese Begriffe ( dieser Absatz ist aus meiner Sicht ). Kernel ist eine Schnittstelle zwischen Software und Hardware. Mit anderen Worten, der Kernel verhält sich wie ein Gehirn. Es manipuliert eine Beziehung zwischen dem genetischen Material (dh Codes und seiner abgeleiteten Software) und den Körpersystemen (dh Hardware oder Muskeln).
Dieses Gehirn (dh der Kernel) sendet Signale an Prozesse, die entsprechend handeln. Einige dieser Prozesse ähneln Muskeln (dh Fäden). Jeder Muskel hat seine eigene Funktion und Aufgabe, aber alle arbeiten zusammen, um die Arbeitsbelastung zu beenden. Die Kommunikation zwischen diesen Fäden (dh Muskeln) ist sehr effizient und einfach, so dass sie ihre Arbeit reibungslos, schnell und effektiv erledigen. Einige der Fäden (dh Muskeln) unterliegen der Kontrolle des Benutzers (wie die Muskeln in unseren Händen und Beinen). Andere sind unter der Kontrolle des Gehirns (wie die Muskeln in unserem Magen, Auge, Herz, die wir nicht kontrollieren).
User-Space-Threads umgehen den Kernel und verwalten die Tasks selbst. Oft wird dies als "kooperatives Multitasking" bezeichnet, und in der Tat ist es wie unsere oberen und unteren Extremitäten, es steht unter unserer eigenen Kontrolle und es funktioniert alles zusammen, um Arbeit zu erreichen (dh Übungen oder ...) und benötigt keine direkten Befehle von das Gehirn. Auf der anderen Seite werden Kernel-Space-Threads vollständig vom Kernel und seinem Scheduler gesteuert.
...............................................
In einer Antwort auf Ihre Fragen:
Wird ein Prozess immer basierend auf einem oder mehreren Lightweight-Prozessen implementiert? Abbildung 3.4 scheint ja zu sagen. Warum werden in Abbildung 3.5 (a) Prozesse direkt auf CPUs angezeigt?
Ja, es gibt Lightweight-Prozesse, sogenannte Threads, und Heavyweight-Prozesse.
Ein Heavyweight-Prozess (Sie können ihn als Signal-Thread-Prozess bezeichnen) erfordert, dass der Prozessor selbst mehr Arbeit leistet, um seine Ausführung zu veranlassen. Aus diesem Grund zeigt Abbildung 3.5 (a) Prozesse direkt auf CPUs.
Wird ein Lightweight-Prozess immer basierend auf einem Kernel-Thread implementiert? Abbildung 3.4 scheint ja zu sagen. Warum werden in Abbildung 3.5 (b) Prozesse mit geringem Gewicht direkt über den Prozessen angezeigt?
Nein, Lightweight-Prozesse werden in zwei Kategorien unterteilt: Prozesse auf Benutzerebene und Kernel-Ebene, wie oben erwähnt. Der Prozess auf Benutzerebene stützt sich auf eine eigene Bibliothek, um seine Aufgaben zu verarbeiten. Der Kernel selbst plant den Prozess auf Kernel-Ebene. Threads auf Benutzerebene können mit einem von vier Modellen implementiert werden: Viele-zu-Eins, Eins-zu-Eins, Viele-zu-Viele und Zwei-Ebenen. Alle diese Modelle ordnen Threads auf Benutzerebene Threads auf Kernelebene zu.
Können Kernel-Threads als einzige Entitäten geplant werden?
Nein, Kernel-Level-Threads werden vom Kernel selbst erstellt. Sie unterscheiden sich von Threads auf Benutzerebene darin, dass die Threads auf Kernelebene keinen begrenzten Adressraum haben. Sie leben ausschließlich im Kernel-Raum und wechseln nie in den Bereich des User-Lands. Sie sind jedoch genau wie normale Prozesse vollständig planbar und nicht planbar (Hinweis: Es ist möglich, fast alle Interrupts für wichtige Kernelaktionen zu deaktivieren). Der Zweck von Kernel-eigenen Threads besteht hauptsächlich darin, Wartungsarbeiten am System durchzuführen. Nur der Kernel kann einen Kernel-Thread starten oder stoppen. Auf der anderen Seite kann sich ein Prozess auf Benutzerebene basierend auf seiner eigenen Bibliothek selbst planen und gleichzeitig vom Kernel basierend auf den zwei Ebenen und vielen zu vielen Modellen (oben erwähnt) geplant werden.
Werden Lightweight-Prozesse nur indirekt über das Planen der zugrunde liegenden Kernel-Threads geplant?
Die Kernel-Threads werden vom Kernel-Scheduler selbst gesteuert. Das Unterstützen von Threads auf Benutzerebene bedeutet, dass eine Bibliothek auf Benutzerebene mit der Anwendung verknüpft ist und diese Bibliothek (nicht die CPU) die gesamte Verwaltung in der Laufzeitunterstützung für Threads bereitstellt. Es werden Datenstrukturen unterstützt, die zum Implementieren der Thread-Abstraktion erforderlich sind, und es werden alle Planungssynchronisations- und anderen Mechanismen bereitgestellt, die zum Treffen der Ressourcenverwaltungsentscheidung für diese Threads erforderlich sind. Jetzt können einige der Thread-Prozesse auf Benutzerebene auf die zugrunde liegenden Kernel-Level-Threads abgebildet werden. Dies umfasst eine Eins-zu-Eins-, eine Eins-zu-Viele- und eine Viele-zu-Viele-Zuordnung.
Werden Prozesse nur indirekt über die Planung der zugrunde liegenden Lightweight-Prozesse geplant?
Es kommt darauf an, ob es sich um ein schweres oder leichtes Verfahren handelt. Schwer sind Prozesse, die vom Kernel selbst geplant werden. Der Light-Prozess kann sowohl auf Kernel- als auch auf Benutzerebene verwaltet werden.
