Wie werden Threads in verschiedenen Betriebssystemen implementiert?

Ich habe Linux Kernel Development von Robert Love gelesen , wo ich darauf gestoßen bin

Linux verfolgt einen interessanten Ansatz zur Thread-Unterstützung: Es wird nicht zwischen Threads und normalen Prozessen unterschieden. Für den Kernel sind alle Prozesse gleich - einige teilen sich zufällig Ressourcen.

Ich weiß nicht viel über Betriebssysteme (ich möchte mehr wissen) und Kernel und daher warf das obige Zitat eine Frage zu Thread-Implementierungen in verschiedenen Betriebssystemen (zumindest den populären wie Windows, Linux und Unix) auf.

Kann jemand bitte die verschiedenen Techniken zur Bereitstellung von Thread-Unterstützung in einem Betriebssystem erklären? (und optional kontrastieren sie)

operating-systems process-scheduling threads

— Ankit
quelle

Vielleicht möchten Sie sich die Antwort auf diese Frage zum Stackoverflow ansehen .

— Pedro

Diese Frage scheint speziell Linux zu betreffen. Als solches ist es hier offtopic und sollte unter Unix & Linux sein . Wenn es sich um eine allgemeine Frage zum Betriebssystem handeln soll, bearbeiten Sie diese bitte, um dies zu verdeutlichen.

— Raphael

@ Pedro Danke, aber es ist nicht das, worüber ich verwirrt war. Diese Frage (was ich fühle) spricht mehr über Leistungs- und Sperrprobleme und so weiter. Ich bin daran interessiert, wie Threads tatsächlich implementiert werden und welche Möglichkeiten es gibt

— Ankit

@ Raphael Danke. Ich hätte es an diesen Ort gebracht (nur wenn ich davon gewusst hätte). Also, mein schlechtes, ich habe beim Stackexchange nicht nach Linux-Community gesucht. Können Sie es bitte migrieren?

— Ankit

@Raphael, es geht darum, die Konsequenzen verschiedener Ansätze für eine Betriebssystemfrage so zu verstehen, wie ich sie verstehe. (Übrigens denke ich nicht, dass Linux-spezifisch eine Frage hier nicht zum Thema macht.)

— Kaveh

Threads und Prozesse sind Ausführungskontexte. Sie unterscheiden sich meist nur durch die Menge des gemeinsam genutzten Status (Speicher, Signalhandler, Dateideskriptoren, ...) mit den anderen Ausführungskontexten (Prozesse teilen sich wenig mit anderen Prozessen; Threads teilen sich viel mit den anderen Threads im selben Prozess).

Die meisten Betriebssysteme halten die beiden Dinge getrennt und kennen daher verschiedene Arten von Ausführungskontexten.

Der Linux-Kernel hingegen hat nur eine Art von Ausführungskontext, der in der Lage ist, Dinge mit anderen zu teilen oder nicht. Wenn Sie einen Prozess möchten, richten Sie ihn so ein, dass er wenig gemeinsam nutzt. Wenn Sie Threads möchten, richten Sie sie so ein, dass sie gemeinsam nutzen, was sie benötigen. Sie können die Dinge so einrichten, dass sie sich für die Prozess- / Thread-Terminologie ungeeignet verhalten.

Die POSIX-API, die üblicherweise beim Programmieren für Linux verwendet wird, kennt nur Prozesse und Threads, und daher kümmern sich die meisten Programme nicht wirklich darum, was ein Implementierungsdetail für sie ist, da die Verantwortlichkeiten zwischen Kernel und Benutzerbereich aufgeteilt werden. Ältere Implementierungen von Threads haben einige Implementierungsdetails verloren (ps zeigt Threads, Thread-ID und Prozess-ID, die sich vermischen, ...) und lieferten in einigen Fällen keine exakte POSIX-Semantik (Signalübertragung war problematisch IIRC).

— Ein Programmierer
quelle

Ich denke, Sie vermissen etwas von der Komplexität des Linux-Schedulers. Es weiß, ob Threads zum selben Prozess gehören. Es gibt auch Userland-Threads. Darüber hinaus scheint dies eher eine SO-Antwort auf die konkrete Implementierung zu sein als eine CS-Antwort, die die Konzepte erklärt.

— Gilles 'SO - hör auf böse zu sein'