☰

Interne Organisation (im Hinblick auf Familienbeziehungen) von Prozessen in Linux

tag-icon • tag-icon linux kernel process
Interne Organisation (im Hinblick auf Familienbeziehungen) von Prozessen in Linux

So wie ich es verstehe, werden Prozessdeskriptoren in einer doppelt verknüpften Listendatenstruktur gespeichert. Sie forkkönnen jedoch verwendet werden, um mehrere untergeordnete Prozesse für denselben Prozess zu erstellen. Das lässt mich also annehmen, dass es sich um eine Baumstruktur handelt, da mehrere Prozesse auf einen übergeordneten Prozess verweisen. Was ist richtig? Unterscheiden sich Prozessdeskriptoren von Prozessen?

Antwort1

fork()erstellt einen neuen Prozess, indem er den Prozessdeskriptor kopiert. Daher teilen sich die beiden Prozesse (zumindest anfangs) einige Daten, aber sobald ein Prozess startetÄndernDer Copy-on-Write-Mechanismus stellt sicher, dass die Änderung nur auf den Prozess beschränkt ist, der sie tatsächlich vorgenommen hat. Dies ist der Standardmechanismus für die Prozesserstellung unter UNIX.

Dies erzeugt natürlich eine ziemlich natürliche Eltern-Kind-Beziehung zwischen Prozessen, die jedoch unabhängig von der internen Darstellung im Kernel ist. Prozessdeskriptoren können als verknüpfte Liste, Baum, Hash-Tabelle oder jede andere (mehr oder weniger) geeignete Struktur implementiert werden. Alles, was man wirklich braucht, ist ein Ort im Kernel-Prozessdeskriptor, der auf den übergeordneten Prozess (und möglicherweise auch auf untergeordnete Prozesse) verweist. Ob er als Schlüsselteil der Struktur verwendet wird oder nicht, ist eine Designentscheidung. Eines der vielen Dinge, die bei einer solchen Entscheidung ins Spiel kommen, ist beispielsweise, was passiert, wenn der übergeordnete Prozess beendet wird – unter UNIX initübernimmt der Prozess verwaiste Prozesse (mit all ihren untergeordneten Prozessen).

Antwort2

Ihre Verwirrung rührt von einer Vermischung zweier Dinge her: (1) der Organisation der Prozessdeskriptoren und (2) der Eltern-/Kind-Beziehung.

Sie benötigen die Eltern-Kind-Beziehung nicht, um zu entscheiden, welcher Prozess als nächstes ausgeführt werden soll oder (im Allgemeinen) an welchen Prozess ein Signal gesendet werden soll. Daher hat Linux (das ich für die 3.11.5-Kernelquelle task_structgefunden habe ) Folgendes:linux/sched.h

struct task_struct __rcu *real_parent; /* real parent process */
struct task_struct __rcu *parent; /* recipient of SIGCHLD, wait4() reports */
/*
 * children/sibling forms the list of my natural children
 */

struct list_head children;  /* list of my children */
struct list_head sibling;   /* linkage in my parent's children list */

Sie haben Recht, es gibt eine Baumstruktur für die Kind-/Elternbeziehung, aber sie scheint in einer anderen Liste und einem Zeiger auf das übergeordnete Element verborgen zu sein.

Die berühmte doppelt verknüpfte Liste ist in der struct task_structStrukturdefinition von 3.11.5 nicht offensichtlich. Wenn ich den Code richtig lese, ist das unkommentierte Strukturelement struct list_head tasks;die „organisierende“ doppelt verknüpfte Liste, aber ich könnte mich irren.

verwandte Informationen