Ein Thread ist "leicht", da der größte Teil des Overheads bereits durch die Erstellung seines Prozesses erreicht wurde.Warum werden Threads Lightweight-Prozesse genannt?
Ich fand dies in einem der Tutorials.
Kann jemand ausarbeiten, was es genau bedeutet?
Die Behauptung, dass Threads "leicht" sind, ist - je nach Plattform - nicht unbedingt zuverlässig.
Ein Betriebssystem-Thread muss die Ausführung von systemeigenem Code unterstützen, z. geschrieben in C. Also muss es einen Stapel von anständiger Größe bereitstellen, normalerweise in Megabytes gemessen. Wenn Sie also 1000 Threads gestartet haben (vielleicht in dem Versuch, 1000 gleichzeitige Verbindungen zu Ihrem Server zu unterstützen), würden Sie in Ihrem Prozess einen Speicherbedarf von 1 GB haben, bevor Sie überhaupt mit der eigentlichen Arbeit beginnen.
Dies ist ein echtes Problem bei hochskalierbaren Servern, sodass sie Threads nicht so verwenden, als wären sie überhaupt leicht. Sie behandeln sie als schwergewichtige Ressourcen. Sie können stattdessen eine begrenzte Anzahl von Threads in einem Pool erstellen und Arbeitselemente aus einer Warteschlange übernehmen.
Da dies bedeutet, dass die Threads langlebig und klein sind, könnte es besser sein, stattdessen Prozesse zu verwenden. Auf diese Weise erhalten Sie Adressraumisolierung und es gibt nicht wirklich ein Problem mit Ressourcenmangel.
Zusammenfassend: Seien Sie vorsichtig mit "Marketing" -Ansprüchen, die im Namen von Threads gemacht werden. Parallelverarbeitung ist großartig (zunehmend wird es notwendig sein), aber Threads sind nur eine Möglichkeit, dies zu erreichen.
+1 Spot on - hätte ich es besser nicht selbst sagen können – zebrabox
Ich liebe die Zusammenfassung. Ich bevorzuge es, mehrere single-threaded-Prozesse zu verwenden, und ich hasse es, wenn Multi-Thread-Fan-Boys mir vorwerfen, die einfache Multi-Core-Parallelität nicht zu nutzen, weil sie nicht die Vorstellung von mehreren Prozessen haben. –
Danke. Es gibt viele Gründe, warum Prozess manchmal besser als Threads sein kann. Eine, die mich überrascht hat, war, dass Sie einen kostenlosen Leistungsschub bekommen könnten! Der Grund ist, dass separate Prozesse separate C-Speicher-Heaps haben. In einer thread-sicheren Standard-Bibliothek müssen alle "malloc" -/"free" -Rufe synchronisiert werden, was je nach Speicherverbrauch eine Menge Sperren bedeuten kann. Ich habe eine App gesehen, die Threads bei 4 Kernen benutzt, aber wenn sie auf separate Prozesse umgestellt wird, würde sie auf 8 skalieren (und wahrscheinlich mehr, hatte nicht mehr Kerne zum Testen). Je weniger Speicher Sie teilen, desto weniger müssen Sie synchronisieren. –
Die Prozesserstellung ist "teuer", da sie einen komplett neuen virtuellen Speicherplatz für den Prozess mit eigenem Adressraum einrichten muss. "teuer" bedeutet viel CPU-Zeit.
Threads müssen dies nicht tun, nur ein paar Zeiger ändern, also ist es viel "billiger" als einen Prozess zu erstellen. Der Grund dafür, dass Threads dies nicht benötigen, ist, dass sie im Adressraum und im virtuellen Speicher des übergeordneten Prozesses ausgeführt werden.
Jeder Prozess muss mindestens einen Thread haben. Wenn Sie also darüber nachdenken, bedeutet das Erstellen eines Prozesses, dass Sie den Prozess erstellen und einen Thread erstellen. Offensichtlich dauert das Erstellen eines Threads weniger Zeit und Arbeit am Computer.
Darüber hinaus sind Threads "leichtgewichtig", da Threads interagieren können, ohne dass die Kommunikation zwischen Prozessen erforderlich ist. Das Wechseln zwischen Threads ist "billiger" als das Umschalten zwischen Prozessen (wieder nur einige Zeiger bewegen). Und die Kommunikation zwischen Prozessen erfordert eine teurere Kommunikation als Threads.
Threads innerhalb eines Prozesses teilen sich den gleichen virtuellen Speicherbereich, aber jeder hat einen separaten Stack und möglicherweise "Thread-lokalen Speicher", falls implementiert. Sie sind leichtgewichtig, weil ein Kontextwechsel ist einfach ein Fall des Umschaltens des Stack-Pointer und Programm-Zähler und die Wiederherstellung anderer Register, während ein Prozess Kontextwechsel umfasst auch die MMU-Kontext wechseln.
Darüber hinaus ist die Kommunikation zwischen Threads innerhalb eines Prozesses leichtgewichtig, weil sie einen Adressraum teilen.
Es ist nicht leicht, wenn Sie ein Mehrkernsystem haben, das Daten zwischen den L1-Caches für mehrere Threads synchronisieren muss - in der Tat ist das alles andere als leicht – zebrabox
@zebrabox: Zweifellos wahr. Wie immer werden solche Begriffe im Laufe der Zeit irrelevant. Die meisten meiner Arbeiten sind auf Single-Core-Embedded-Systemen mit RTOS-Kerneln, so dass solche Komplexitäten selten aufgetreten sind - alles ist ein roter Faden - selbst wenn sie von einer MMU geschützt sind (im Widerspruch zu dem, was ich vorher gesagt habe!). – Clifford
Ja ich weiß wo du herkommst. Es ist natürlich viel weniger ein Problem auf einem einzelnen Kern-Maschine - vor allem, wenn Sie Zugriff auf ein paar Hardware-Threads haben :) – zebrabox
Prozess:
thread:
Verfahren enthält einen oder mehrere Threads in ihm und ein Faden kann ein Prozess tun nichts tun kann. Auch Threads innerhalb eines Prozesses teilen sich den gleichen Adressraum, da die Kommunikationskosten zwischen den Threads niedrig sind, da sie den gleichen Codeabschnitt, den gleichen Datenabschnitt und dieselben Betriebssystemressourcen verwenden, sodass alle diese Features einen "leichten Prozess" darstellen.
Halten Binging für "Prozess Erstellung" und Ihr Betriebssystem und Sie werden sehen, wie viel Overhead gibt es in einen Prozess zu erstellen. –
@No Rückerstattungen Keine Rückgaben: Und Sie werden feststellen, dass es zwischen den Betriebssystemen erheblich unterscheidet. –
@No Refunds No Returns - Was ist das Übersprechen der Cache-Synchronisation zwischen Threads auf einem Multi-Core-Rechner oder der Overhead des Kontextwechsels und des Speicherns des Stack-Status und des Register-Sets? – zebrabox