Diskussion:Thread (Informatik)

alte Disku-Beiträge

"Neuere Versionen" von Linux gibt es inzwischen glaube ich auch seit 1996...Bin mir aber nicht sicher...

Ich schlage vor, hier zumindest die Übersetzung der englischen Definition einfliessen zu lassen und die Behauptung zu streichen, Prozesse könnten nicht untereinander kommunizieren. --141.39.2.1 Benutzerkennung nachgetragen --Hades 23:06, 17. Sep 2005 (CEST)

Die Seite ist absoluter Müll! --217.229.132.118 Benutzerkennung nachgetragen --Hades 23:06, 17. Sep 2005 (CEST)

Warum verbesserst du sie dann nicht? Dein "Kommentar" ist ohne weitere konstruktive Kritik nutzlos. Aber die Tatsache, dass du hier nur nörgelst, zeigt, dass du ein charakterliches oder geistiges Problem hast und an ernsthafter Diskussion nicht interessiert bist. Insofern haben wir hier wohl nichts von dir zu erwarten. Troll! --subsonic68 15:27, 13. Mär 2005 (CET)

Was ist hier los? Ich habe keine Stelle gefunden, die besagt, Prozesse könnten nicht untereinander kommunizieren. Drin steht ist eine Kommunikation zwischen diesen Threads von vorneherein möglich , was genau stimmt. Bei Interprozesskommunikation findet man dann genügend Hinweise. Auf der Interprozesskommunikation-Seite wird die Interprozesskommunikation aber nun wieder auch auf zum Informationsaustausch von nebenläufigen Prozessen oder Threads verwiesen, das oder Threads ist dort nun wieder zuviel! Die Trennung von Thread und Prozess sollte sprachlich sauber gemacht werden, diese Seite trägt meines Erachtens dazu bei und ist grundsätzlich gut und richtig.

Die Einleitung stammt nicht von mir, ich erkenne sie aber mit meinem Fachwissen als richtig.

Ich habe die Java-Erklärungen hinzugefügt, einfach aus dem Grunde, weil Java als allgemein presente Programmiersprache eine gute Threadunterstützung bietet und man daran lernen kann (nur die Grundprinzipien sind erläutert, keine Programmieranleitung, denke ich.). Daran kann man nörgeln, wenn man anderer Meinung ist, aber bitte auf der Diskussionsseite.

Threads unter UML ist auch von mir, ich habe das deshalb ausgewälzt, weil die Threadproblematik in UML sonst unklar bleibt. Möglicherweise kann das zuviel sein, was da steht, Kritik ist freilich erlaubt.

Im Kapitel Threads unter Unix und Windows möchte ich, sobald Zeit ist, ganz kurz die wichtigesten Funktionsaufrufe zur Erzeugung von Threads benennen, einfach als Guide zum finden, wenn man sowas programmieren muss. Auch das fork() von Unix als Prozessgabelung gehört dort kurz erwähnt, als Abgrenzung. Ich denke, das kann man schreiben. Kann auch jemand Anderes schreiben, habe dazu leider keine Zeit. (Nebenbemerkung: Auf der Diskussionsseite kann man ja schnell was runterschreiben, geht genau so schnell wie reden, nicht aber auf der Artikelseite.)

Den Tip, die englische Seite anzuschauen, nehme ich an, habe selbst nicht daran gedacht, Danke.

Also konkret: Was ist hier gut, was ist hier schlecht? mitFreundlicheGrüßen -- HartmutS 10:03, 22. Sep 2005 (CEST)

Kurzer Zusatz: Die englische Seite ist vollkommen unabhängig und beleuchtet ganz andere Seiten. Sie ist umfangreicher, wirkt technischer, das sie wirklich viel besser ist, diese Meinung ist mir aber nicht gekommen. Ich werde mir noch etwas mehr Zeit nehmen müssen. -- HartmutS 10:10, 22. Sep 2005 (CEST)

>diese muss eine Methode run() enthalten und vom Interface java.lang.Runnable abgeleitet sein.

Meine Java-Kenntnisse sind begrenzt, wäre es nicht trotzdem besser, hier zu schreiben: " .. muss die run()-Methode der Superklasse Thread überschreiben oder das Interface java.lang.Runnable implementieren" ? --illik 16:15, 26. Dez 2005 (CET) Stimmt, Deine Java-Kenntnisse sind nicht so begrenzt. 'implementieren' ist besser als 'abgeleitet sein'. Leider muss ich oft auch C++ programmieren, und da redet man nicht von implementieren, weil C++ nicht diese sinnvolle Unterscheidung von

class X extends BaseY implements InterfaceZ, InterfaceSonstwie

kennt sondern nur die Vererbung ohne spezifisch zwischen Interfaces und Basisklassen zu unterscheiden. Bei C++ redet man daher eher von ableiten. Bezüglich Deinem ersten Satzteil musste ich in der Java-Klassendokumentation nachschauen. Stimmt auch. Man kann auch die Klasse Thread als Superclass nehmen und erweitern. Dann muss(!) man das run() überschreiben. Das ist eine 2. Variante, auf die ich noch gar nicht gekommen bin. Ich finde die allerdings auch nicht so gut, weil dann keine andere Superclass mehr möglich ist (java kennt nur Einfachvererbung). Für spezielle Dinge ("brauche nie eine Superclass") mag das besser sein, denn Vorteil ist, dass man nur eine Instanz hat, sonst die Thread-Instanz und die Klasse, die Runnable implementiert. Das sind allerdings Feinheiten, die das Thema hier sprengen. Da die Java-Anmerkungen nur Anmerkungen sein sollen, und nicht eine Lektion möglicher java-Programmierungen, würde ich gern nur die eine Variante nur sehen wollen:

• diese muss eine Methode run() enthalten und das Interface java.lang.Runnable implementieren.

Denn die zweite mögliche Methode im Nebensatz steht im Widerspruch zu Thread kennt eine beliebige Anwenderklasse. D.h. auch diesen Textteil müsste man dann umbauen und letztlich beide Varianten erwähnen. Oder man schreibt:

• Eine Instanz von Thread kennt eine beliebige Anwenderklasse, diese muss eine Methode run() enthalten und das Interface java.lang.Runnable implementieren; oder die class Thread wird als Superclass einer Anwenderklasse benutzt, dann muss die Methode run() überschrieben werden.

Dann hätte man beides gleichberechtigt. --HartmutS 08:22, 1. Dez 2005 (CET)

Was ist ein Thread

Die Begriffserklärung ist mir, nachdem ich selbst beigetragen habe, zusehr lastig im Sinne von Thread in einem Betriebssystem oder unter Windows, demzufolge falsch meine eigene Darstellung Threads in UML. Wenn man zum reinen Begriff zurückkehrt, dann ist ein Thread in der Software genau das gleiche wie ein Thread im Usenet, nämlich ein Ablauffaden einer Bearbeitung. Aus Sicht des Betriebssystems ist ein Thread das, was beschrieben ist im ersten Kapitel. Aus Sicht von UML sollte man das selbige wie folgt sehen: Hat man mehrere Klassen mit Statecharts (in Rhapsody 'sequential'), dann wird auf einen Betriebssystem-Thread mehrere Ablauffäden (Thread) der Anwendersoftware zugeordnet, nämlich pro Statechart einer. Das Rhapsody-Framework bildet dies ab, indem es in einem Betriebssystem-Thread sequentiell die unabhängigen Statechart-Softwareaktivitäten aufruft. Das ist in etwa gleichartiger Weise wie eine Java-VM mehrere java-Threads in einem Betriebssystem-Thread abarbeiten kann bzw, wie jedes Multitasksystem den einen Prozessor-Lauf in mehrere Betriebssystem-Threads umlegt. Unbeachtet ist hierbei die Möglichkeit des Timesharings, diese Spezialleistung vollbringt genau ein Multitasksystem, das gehört hier aber nicht hin (nur erwähnt und verlinkt). Das ganze kann Konsequenzen haben, wie man Statecharts sieht (organisiert), damit ist der Inhalt Threads in UML stark überarbeitungswürdig. Ich werde mir genaue Formulierungen noch überlegen. Was sagt die wikipedia-Allgemeinheit dazu?

Weitere Frage: Ich habe leider nur Gelegenheit, UML aus Sicht von Rhapsody zu kennen, da ich beruflich damit arbeite. Ich würde gern die Eclipse-Aktivitäten in Richtung UML kennen, bzw. wissen was IBM treibt und was mit Rational Rose Realtime ist. Dazu kommen noch einige viele andere UML-Tools. Dazu habe ich leider keine Zeit. Ich kann also nur von Rhapsody reden. Es wäre aber wünschenswert, wenn jemand die Aussagen mit Kenntnissen anderer Tools abgleicht und die Artikel weniger Rhapsody-lastig machen könnte (obwohl Rhapsody einen bedeutenden Marktanteil hat und ... keine Schleichwerbung!... nicht schlecht ist, aber Wikipedia soll unabhängig sein). --HartmutS 16:53, 1. Dez 2005 (CET)

Der Abschnitt "Threads in UML" wirft eigentlich mehr Fragen auf als er beantwortet. Wenn man nicht wenigstens ein paar Semester Informatik studiert hat, versteht man da, glaube ich, nur Bahnhof. Kaum einer der Fachbegriffe ist verlinkt. Ich will das aber nicht nachholen, da ich der Ansicht bin, dass der Text viel zu fachspezifisch geschrieben ist und letztlich zum eigentlichen Thema "Thread" wenig beiträgt. Es liest sich wie eine "Einführung in Software-Design mit Threads und UML".

Das gleiche gilt auch für "Threads in Java". Schon der erste Satz stimmt weder inhaltlich noch logisch: "Die Programmiersprache Java ist auf fast allen Plattformen lauffähig und kann als allgemein bekannt angesehen werden." Programmiersprachen laufen nicht und JVMs gibt es bei weitem nicht auf "fast allen Plattformen". "allgemein bekannt" ist Java bis auf den Namen sicher auch nicht, der Satz klingt passend für Lehrbuch nach einem Java-Kurs. Wie auch immer, der sich anschließende Text wirft mehr Fragen auf als dass er etwas erklärt und verlangt eine Menge Vorwissen z.B. zu OOP was hier nirgends erwähnt wird und für Threads auch in keiner Form notwendig ist. Dann wieder Fachbegriff über Fachbegriff und allesamt unverknüpft. Gegen ein Code-Beispiel in Java wäre nichts zu sagen, aber die Implementierung von Threads in Java anzureissen, sehe ich nicht als sinnvoll an.

Die Einleitung und die Verweise im Anhang sind einigermaßen in Ordnung. Vielleicht sollte man es dabei erstmal belassen oder Teile aus dem englischen Artikel übernehmen? Der englische Artikel ist allerdings auch überladen. --82.141.49.144 05:41, 4. Dez 2005 (CET)

ack, threads in java hat hier gar nichts zu suchen. hab's erstmal auskommentiert mangels brauchbarem artikel zum einbauen. -- ∂ 05:49, 4. Dez 2005 (CET)

Danke für die Rückmeldungen, kann man ja alles verbessern. Zu der brachialen Löschung sag ich mal gar nichts, ∂ , habe Deine Seite angeschaut. Ich bin zu folgender Ansicht gekommen:

• Das, was hier in der Einleitung als Thread beschrieben ist, ist genau genommen ein Thread aus Betriebssystemsicht.
• Ein Thread in der Software ist an sich das selbe wie ein Thread im usenet, nämlich ein geschlossener Ablauf. Das könnte in der Einleitung deutlich stehen.
• Das, was ich selbst als Thread unter UML geschrieben habe, ist wenig hilfreich, ich werde das anders darstellen in dem Sinne wie oben erläutert.
• Das Java-Beispiel sollte wieder rein, weil es gut die Verwendung von Threads darstellt, überarbeitet.
• Demzufolge ist eine Überarbeitung nicht schlecht, wobei Gutes stehenbleiben soll. Ich lass mir mal noch ein paar Tage Bedenkzeit, vielleicht ist Jemand schneller und besser, sonst werde ich die Überarbeitung vornehmen. --HartmutS 17:24, 12. Dez 2005 (CET)

Nachdem ein Unbekannter den Artikel auf Überarbeitungswürdig gesetzt hat, was durchaus sinnvoll ist, er aber nichts in die Diskussion geschrieben hat, und ein anderer die Überschrift Threads unter UNIX und Windows mit dem Hinweis, dass hier noch etwas fehlt, gelöscht hat (damit die Überarbeitungshinweise oder -wünsche), habe ich wie schon lange vorgehabt den Part Thread in Windows geschrieben. Ich denke, man kann auf ca. 1 Bildschirmseite durchaus konkret vorstellen, wie das geht, um einen Leser den Angelpunkt für weiteres Arbeiten in die Hand zu geben. Eine ausführliche Darstellung aller Thread-mäßigen Windows-API-Schnittstellen wäre hier unpassend, dazu gibts Originialliteratur. Das Beispiel entstammt der Praxis und ist etwas Java-like-lastig in der Wahl von Begriffen, das darf aber durchaus sein, denke ich, aber es ist reines C++.

Ich fände es gut, wenn jemand einen adäquaten Part Thread unter Unix schreibt. Man sollte darauf hinweisen, dass mit fork() Prozesse relativ einfach gestartet werden können, aber das damit nicht auf einen gemeinsamen Speicher gearbeitet werden kann, stattdessen xyz benutzen. Was xyz ist, weiß ich nicht, da ich leider keinen engen Kontakt zu UNIX/Linux habe (mit xyz meine ich die Linux-Thread-Befehle). --HartmutS 18:37, 8. Apr 2006 (CEST)

Hmm, wenn ich mir das anschaue, was Du geschrieben hast, dann benutzt Windows genauso wie Unix Posix Threads. Das heisst die Unterschiede sind allenfalls im Detail. Ist aber schon ein weilchen her, dass ich mit Posix Threads gearbeitet hab. fork() erzeugt uebrigens einen Prozess und keinen Thread.

Vielleicht noch eine kleine Kritik: Dein Absatz ist ein wenig Handbuch lastig. Vielleich kann man das ja bei Gelgenheit in einen Enyclopaedischen Artikel umschreiben.

Gruss sparti 20:06, 8. Apr 2006 (CEST)

Also, die Unterschiede sind im Detail. In folgender Seite wird UNIX-Threads erklärt: galileocomputing.de/openbook/unix_guru. fork() ist die traditionelle (klassiche) Art, Parallelität zu erzeugen aber erzeugt zwei getrennte Prozesse. Bezüglich Handbuchlastigkeit, stimmt eigentlich, ich habe zuviel geschrieben. Die Idee, das Java-Programmiermodell auch unter Windows (und Linux) als quasi-Grundlage zu nehmen und diverse empfohlene aber propritäte Dinge sein zu lassen, verfolge ich schon länger. Aber das gehört nicht in den Artikel sondern vielleicht ins DseWiki DseWiki. Ich verschiebe das demnächst und mache die Windows-Thread-Erklärung kürzer, OK? --HartmutS 20:59, 20. Apr 2006 (CEST)

Die genaue Abgrenzung, was einen Thread von einem Prozess abgrenzt ist noch nicht ganz gelungen. Insbesondere die Gemeinsamkeiten zwischen Threads sind stark vom UNIX fork() abgeleitet. Allgemeiner vielleicht: Threads teilen sich innerhalb eines Prozesses den Speicher und andere, betriebssytemabhängige Ressourcen wie Dateien und Netzwerkverbindungen. Quark 00:34, 3. Jan. 2007 (CET)

Hört sich gut an, hab's eingebaut. -- Kalkofe3 14:19, 8. Jan. 2007 (CET)

Als weiteres Thema fehlt vielleicht noch die Threadaffinität gewisser Betriebsmittel. Stichwort unter Windows dabei: Window Handle, Thread Local Storage (TLS). Quark 00:34, 3. Jan. 2007 (CET)

Hört sich interessant an, aber ich weiß nicht, was damit gemeint ist. Schreib's doch rein! -- Kalkofe3 14:19, 8. Jan. 2007 (CET)

Habs mal ergänzt. In der englischen Wikipedia ist auch ein Artikel zum TLS, der ist aber hier nich übersetzt. Quark 01:29, 12. Feb. 2007 (CET)

Begriffsabgrenzung Prozess / Kernel Thread / User Thread / Fiber

Der Begriff Thread sollte sauberer gegenüber anderen Arten der Parallelverarbeitung in Programmen abgegrenzt werden. Was dieser Artikel eigentlich erläutert ist ein Kernel Thread, also Scheduling durch den Betriebssystemkern mit mehreren Befehlszeigern und einem gemeinsamen Speicherbereich für die Threads eines Prozesses. Die zum Vergleich herangezogene Fiber ist eigentlich ein User Thread. Der Begriff Fiber ist erst mit Windows 98 entstanden und bezeichnet das ca. 10 Jahre ältere Konzept des in den Userspace verlagerten Schedulings. Den Begriff "Thread" würde ich persönlich jetzt als Überbegriff für "Kernel Thread" und "User Thread" sehen, denke aber, daß das allgemeine Verständnis "Thread" mit "Kernel Thread" gleichsetzt. Irgendwie wird das im ersten Abschnitt nicht so richtig klar. Wenn niemand etwas dagegen hat, würde ich den Artikel insoweit ändern, daß der Fokus deutlicher auf "Kernel Thread" liegt und den Begriff "Fiber" durch "User Thread" ersetzen. -- Kalkofe3 16:13, 20. Nov. 2006 (CET)

Ich habe nun die Änderung bzgl. Fiber/User Thread durchgeführt und außerdem die Struktur des Artikels geändert. Ich halte es für sinnvoller, wenn zuerst erklärt wird, was ein Thread ist, bevor das Thema gegenüber anderen Begriffen abgegrenzt wird. Außerdem habe ich einige Textstellen in andere Abschnitte verschoben, da sie für mich dort sinnvoller sind. Es fehlen nun noch Details zu den Implementierungen von Threads unter Unix/Linux. -- Kalkofe3 15:38, 20. Dez. 2006 (CET)

Ich finde die Abgrenzung Kernel/User eher verwirrend. Zumindest aus Sicht der Anwendungsentwicklung unter Windows sind sowohl Thread als auch Fiber vom API bereitgestellt und der Unterschied zwischen Kernel Mode Scheduler und User Mode Scheduler wird hier gar nicht erläutert. Eventuell ist aber auch User einfach der falsche Begriff (User=Anwender? Applikation?). Wie wäre es mit der Abgrenzung als Hardware (im Prozessor implementiert) und Software (Emulierter Thread ohne echte Parallelverarbeitung). Quark 00:21, 3. Jan. 2007 (CET)

Diese Abgrenzung wäre falsch, da es sich ja bei allen diesen Begriffen um software-seitige handelt. Wie die Parallelisierung in der Hardware realisiert ist (und ob sie es überhaupt ist) ist dafür irrelevant. Was deutlich werden soll, ist daß beim Kernel Thread das Betriebssystem das Scheduling übernimmt (also auch nicht die Hardware) und beim User Thread (unter Windows Fiber) diese Funktionalität von einer Bibliothek bereit gestellt wird, die Teil des Anwendungsprogramms ist. Diese Unterscheidung muß für den Programmierer der Anwendung nicht relevant sein und mögen für ihn im Detail liegen. Es sind aber zwei verschiedene Implementierungen des Thread-Konzeptes. Ob jetzt die englischen Begriffe Kernel und User dafür am angebrachtesten sind - darüber kann man streiten. Da im Informatik- bzw. Programmierer-Umfeld oft die ursprünlich englischen Begriffe auch im Deutschen verwendet werden, würde ich persönlich bei diesen Begriffen bleiben. Es steht Dir aber natürlich frei, entsprechende Begriffsklärungen in den Artikel einzufügen. :-) -- Kalkofe3 14:00, 8. Jan. 2007 (CET)

Bin leider nicht so in der theoretischen Threadliteratur sattelfest, finde die Begriffe einfach etwas unpassend/irreführend. Vielleicht muss einfach nur besser herausgearbeitet werden, dass der Unterschied in der Zuständigkeit des Scheduling liegt (User vs. OS). Auch habe Ich mir nochmal den zugehörigen Artikel User Thread angesehen, und dort festgestellt, dass dieser in der Abgrenzung nicht ganz korrekt ist. Unter Windows besteht keine Affinität zwischen User Thread und Kernel Thread (Siehe API Doku zu SwitchToFiber), die Unterschiede zwischen Solaris und NT sind also eher in der unterschiedlichen Benamung zu suchen. Quark 01:28, 11. Jan. 2007 (CET)

Für mich ist das so wie es geschrieben ist klar verständlich, aber ich hab's ja auch (z.T.) geschrieben. ;-) Kannst Du denn nicht zum Scheduling noch etwas schreiben? Zum zweiten Punkt siehe Diskussion:User Thread. -- Kalkofe3 09:46, 15. Jan. 2007 (CET)

Meinst Du mit den Details zu den Implementierungen weitere Codebeispiele? Die könnte man bei LinuxThreads, GNU Portable Threads oder Native POSIX Thread Library unterbringen. Da passen sie thematisch auch besser und wir vergrößern den Artikel nicht unnötig. Die Unterscheidung zwischen Kernel- und User-Threads finde ich so gelungen. Im allgemeinen Sprachgebrauch ist mit einem Thread praktisch immer ein Kernel Thread gemeint, einfach weil es keinen guten Grund gibt sich mit User-Threads abzuplagen. Zumindest nicht im Desktop Bereich. Bei Klein- und Kleinstcomputern (Handhelds, Handys, Waschmaschinen) mag das anders sein, aber die meisten Programmierer programmieren größere Systeme. Was übrigens noch garnicht erwähnt wurde ist, dass zwei Kernel-Threads auch gleichzeitig auf zwei verschiedenen Prozessoren laufen können. --Regani 12:33, 15. Jan. 2007 (CET)

Nicht unbedingt Codebeispiele. Der Unterabschnitt ist ja mit Linux/Unix betitelt und das umfaßt ja jede Menge Betriebssysteme. Denke schon, daß man da zu unterschiedlichen Konzepten noch was schreiben könnte. Zumindest die von Dir genannten Artikel sollten (auch) dort verlinkt oder zumindest genannt sein. -- Kalkofe3 09:18, 16. Jan. 2007 (CET)

Die Unterscheidung User und Kernel Thread finde ich nicht passend. Ein Thread ist zunächst ein Thread, Unter verschiedenen Systemen (auch embedded) gibt es verschiedene Implementierungen der Threadorganisation. Man darf nicht Spezifikas von Windows-Versionen in allgemeine Darstellungen zu stark hineinmischen! Die Erwähnung, dass Threadorganisation im User- oder Kernelbereich stattfinden kann, ist aber ein guter Gedanke. Aber die Auftrennung in zwei Artikel in der Wikipedia erscheint mir für diese Sache weit überzogen. Die Darstellung dieses Problemes als eigener Hauptabschnitt unter Thread sollte ausreichend sein. Ich würde also gern im Sinne der besseren Überschaubarkeit den Artikel User Thread wieder abschaffen. --HartmutS 20:41, 1. Apr. 2007 (CEST)

Man könnte den Artikel zu User Threads als zusätzliches Kapitel in den Artikel zu Threads einfließen lassen. Ersatzlos abschaffen möchte ich ihn nicht, dazu sind Threads und User Threads zu unterschiedlich. Aus Sicht des Programmiers mögen sie halbwegs ähnlich sein, die technische Umsetzung die dahinter steht unterscheidet sich aber grundlegend und führt auch zu einigen völlig anderen Eigenschaften. SMS/MMS und E-Mail sind aus Nutzersicht auch recht ähnlich: Übermittlung von Textnachrichten, eventuell mit Bildern vom PC oder Handy aus. Trotzdem würde man das nicht zusammen mischen. An welcher Stelle siehst du denn die übermäßige Konzentration auf Windows-Spezifika? Die sollte nämlich nicht drin sein, oder wenn schon dann flankiert von Linux/Solaris/BSD/... Spezifika damit man einen Vergleich hat. --Regani 22:15, 1. Apr. 2007 (CEST)

Mit der Aussage Man darf nicht Spezifikas von Windows-Versionen in allgemeine Darstellungen zu stark hineinmischen! habe ich mich im Wesentlichen auf den Satz oben Der Begriff Fiber ist erst mit Windows 98 entstanden und bezeichnet das ca. 10 Jahre ältere Konzept ... bezogen. Es ist häufig zu beobachten, dass Microsoft als Maß der Dinge gesehen wird. Ich glaube nicht, dass Fiber tatsächlich erst mit Windows98 entstanden ist. Der Begriff ist nur ein Wortspiel, thread bezeichnet eher Faden, Garn, Strang wogegen fiber die Faser im Faden oder Garn ist, also etwas kleineres, ein Bestandteil. Fiber meint dementsprechend die Organisation eines inneren Ablauf innerhalb eines Threads für unterschiedliche Aufgaben. Einen solchen Ablauf kann man eher im Userspace programmieren, weil keine Systemzugriffe notwendig sind. aber die Grenze zwischen User und System ist stark abhängig von den Anwendungsfällen. Definiert man alles als Kernel, was von einem Windows-OS geliefert wird, den Rest als User, dann ist das eine sehr klar ziehbare Abgrenzung, aber eben nur für diese Sicht. Ein Framework eines UML-Entwicklungswerkzeuges (ich kenne relativ gut Rhapsody von Telelogic) benutzt Fibers in Statecharts. Der Framework-Anteil kann vom UML-Nutzer als Kernel bezeichnet werden, sein User-Space sind die UML-Modelle. Im embedded-Bereich sind die Grenzen ebenfalls je nach Sicht zu definieren. Fibers im Thread-Konzept haben einen großen Vorteil: Da alle Fibers eines Threads gegeneinander garantiert nicht unterbrechbar sind, gibt es in diesem Bereich keine Mutex-Probleme. Daher kann ein UML-Werkzeug auch leichtfertig und richtig argumentieren: Bei Statecharts einer gemeinsamen aktiven Klasse (=ein Thread) sind keine Zusatzaufwendungen bezüglich Datenkonsistenz notwendig. Den Aspekt Fiber - kein Mutex sollte hier im Thread-Artikel erwähnt werden. Bezüglich dieser Dinge ist die starke Unterscheidung User/Kernel Thread aus Sicht eines Theoriegebäudes der Informatik eher irreführend. - Möglicherweise ist die Unterscheidung aus PC-Anwendersicht sinnvoll. Dann sollte aber dieser Artikel Thread nicht in die Ecke Kernel-Thread geschoben werden sondern Thread-Belange vollständig und ausführlich erläutern, der Artikel User Thread sollte eher den PC-Anwenderaspekt erläutern und auf diesen Artikel für weitere Ausführungen verweisen. Fiber mit User-Thread gleichzusetzen ist jedenfalls falsch (siehe Redirect Fiber auf User Thread), richtig ist das User-Threads oft als Fibers realisierbar sind.

Als kleinen Beitrag möchte ich demnächst den Artikel Fiber wieder eigenständig leben lassen, mit einer kurzen erklärung, und einem Verweis sowohl auf diesen Artiel als auch auf User Thread. Damit findet ein Wiki-Leser, der Über Fiber stolpert, eine kurze klare Erklärung, mit den notwendigen weiterführenden Links. - Es ist noch viel zu tun, Zeit müsste man haben. mfG --HartmutS 10:32, 15. Apr. 2007 (CEST)

C10K-Problem

Wofür zur Hölle ist dieser Link? Selbst ich versteh kaum worums da geht, außerdem sind wir in der deutschen WP... FK @ 070401

Nuja, ich zum Beispiel verstehe worum es geht. Die Seite ist so vom ersten Drüberschauen eine sehr interessante Sammlung zum Thema "wie implemetiere ich Threads/Asynchronität unter Linux". Zu dem Thema wird sich auch kaum eine vergleichbare Seite auf Deutsch finden. Falls sich doch eine findet, dann immer her damit. Bis dahin aber bleibt der Link. --Regani 21:51, 1. Apr. 2007 (CEST)

Interrupts in Bezug auf Thread darstellen?

Es fehlt noch Einiges in diesem Artikel: Parallelverarbeitung mit mehreren Prozessoren wurde schon angesprochen. Interrrupts sind auch ein Thema mit starken Referenzen zu Thread, insbesondere für die embedded-Sicht. Diese beiden Thematiken als Hauptabschnitt dieses Artikels sollten zu einer umfassenderen Darstellung zum Thema Thread beitragen. Den Teil über Interrupts könnte ich demnächst schreibe, so Zeit für Wikipedia ist. --HartmutS 20:43, 1. Apr. 2007 (CEST) Eine Stunde später: Natürlich steht schon alles in Wikipedia, wenn man lange genug surft, aber die Zusammenhänge sind schlecht dargestellt. Multitasking liest sich ganz gut, der Unterschied zu Multithreading ist aber künstlich, meine ich. Beide Artikel könnten zusammengefasst werden, mit etwas Historie der Softwareentwicklung. Dieser Artikel könnte parallel zu diesem Artikel stehen, weil er den Aspekt der Realisierung der Threadparallelarbeit mit einem Prozessor betrachtet, dieser Artikel aber Thread an sich. Aber beide Artikel sollten gut verlinkt sein. Der Artikel Interrupt hat auf jeden Fall seine eigene Berechtigung unabhängig von Thread. Das was ich oben meinte ist der Zusammenhang von Interrupt und Thread, der hier dargestellt werden sollte. Aber Unterbrechungsroutine als eigener Artikel neben Interrupt erscheint mir dann wieder falsch. Es gibt keine Unterbrechungsroutinen unabhängig von Interrupts und umgekehrt. Natürlich fällt hier wieder auf, dass es eine Gruppe gibt, die alles deutsch bezeichnen möchte, die anderen halten sich aber nicht daran oder finden es nicht gut. Ich möchte mich diesbezüglich klar einigen meiner Vorgänger in der Meinung anschließen, dass die englischen Begriffe zumindestens in der Informatik-Gemeinde etwas geläufiger sind. Es gäbe noch viel zu tun in Wikipedia. --HartmutS 21:55, 1. Apr. 2007 (CEST)

Beispiele

Wieso wird im vorletzten (alles außer UT) nur von UTs auf verschiedenen Systemen gesprochen. Das ergibt doch kein Sinn. Vor allem sind es die „großen“ „seit 1995” erschienenen OSe.

Etwas Geschichte

Die praktische Informatik ist ja ein Gebiet in dem alles was mehr als 10 Jahre her ist als "antik" bezeichnet wird. Trotzdem würde mich mal interessieren wann Threads das erste mal benutzt wurden bzw erstmals als "Threads" bezeichnet wurden. Ich hab mal etwas geschaut und hier das par Statement aus Algol 68 dokumentiert gefunden, was sich verdammt stark nach Threads (bzw. User Threads) anhört. Vorgeschlagen hatte das Dijkstra schon 1965, siehe [1]. Ob das schon 1968 wirklich als Thread implementiert wurde steht da natürlich nicht, der draft report listet in Kapitel 3.0.6 zumindest ein PARALLEL Symbol, das man wohl auch als PAR abkürzen konnte. Es gibt aber noch diese rechteckigen Dinger aus der Zeit vor dem Web, nur sind meine nicht ausreichen alt. Kann mir da jemand helfen? --Regani 19:16, 3. Jul. 2008 (CEST)

Literatur

Mich wundert, dass das Buch "Parallele Programmierung spielend gelernt mit dem Java-Hamster-Modell - Programmierung mit Java-Threads" (Vieweg+Teubner-Verlag) wieder aus der Literatur entfernt wurde. Es ist ein Buch, dass sehr ausführlich auf viele wichtige Aspekte der parallelen Programmierung insbesondere mit Threads eingeht. Damit die praktische Programmierung mit Threads nicht trocken und öde mit Hilfe von System.out.println visualisiert wird, nutzt dieses Buch das so genannte Hamster-Modell. Hamster sind realisiert als Threads, die sich gegenseitig beim Lösen von Aufgaben in einem virtuellen Territorium unterstützen müssen. Ich finde das Buch noch besser gelungener als bspw. das in der Literaturliste aufgelistete Buch von Oechsle!

Der Artikel...

Der Artikel ist total doof! Viel zu speziell, dazu noch zusammenhanglos. Wenn man denn will, kann man nach wenigen allgemeinen Worten (mehr hat der Begriff Thread m.E. kaum verdient) einige Anwendungsbeispiele des Begriffes geben. Es sollte aber klar sein, daß "Thread" kein normierter Bestandteil eines normierten Betriebssystemkonzeptes ist. Vieles in dem Artikel finde ich gut, insgesamt aber ist er schwammig, speziell und für Außenseiter quasi unbenutzbar. Und "atomisch" bedeutet nicht "schrecklich schnell" - wer das schreibt, hat das Spezielle daran nicht begriffen - sondern "unteilbar". Wie lange eine atomische Operation dauert, ist prinzipiell egal, solange sie unteilbar bleibt. Daß atomische Operationen im Anwendungsfall möglichst kurz dauern, steht auf einem anderen Blatt.

--Hachti 01:21, 17. Jul. 2008 (CEST)

Wenn du ein neues Diskussionsthema aufmachen willst klicke einfach oben auf das "+" neben "Seite bearbeiten". Dann landet es auch an der richtigen Stelle und nicht ganz oben. Dass atomar != kurz ist habe ich jetzt im Artikel so geändert, wie es wohl ursprünglich gemeint war. Bei allen anderen Fällen von Schwammigkeit ist jeder eingeladen zu präzisieren, deshalb ist es ja ein Wiki. Verbesserungspotenzial ist definitiv vorhanden. --Regani 17:12, 17. Jul. 2008 (CEST)

Windows Codebeispiel

Habe das mal korrigiert, so dass es zumindest korrekt alle Ressourcen freigibt. Meiner Meinung nach gehört das aber gar nicht in den Artikel. Insbesonder die Verflechtung der C API mit der C++-Klasse ist sehr fragwürdig, da viele C++ Bibliotheken (MFC [2]) eigene Threading Konzepte verfolgen, und selbst der Aufruf aus dem "normalen" C-API des Visual Studio einen Wrapper erfordert [3]. Würde den Bereich also auf das Windows API reduziert ähnlich zum Java/.NET formulieren und die Codebeispiele rausnehmen Quark 00:33, 7. Okt. 2008 (CEST)

Da stimme ich Dir zu. Hatte auch die ganze Zeit schon überlegt, was man mit den Code-Beispielen machen könnte. Eine Alternative wäre es die anderen Teile auch um Code-Beispiele zur erweitern, wo man in allen dreien das gleiche macht. Nur ist die Frage, gehört so etwas wirklich in eine Enzyklopädie? Wobei es hunderte von Tutorials zu dem Thema gibt. --Stephan.rehfeld 16:41, 19. Aug. 2011 (CEST)

Threads aus Sicht des Betriebssystems - Wortbedeutung im letzten Absatz

Im ersten Satz des letzten Absatzes des Abschnitts "Threads aus Sicht des Betriebssystems" werden die möglichen Zustände eines Threads mit "inaktiv", "aktiv (engl. running)", "bereit (engl. ready)" und "blockiert (engl. waiting)" bezeichnet.

Falls es sich bei den im zweiten Satz mit "rechnend", "rechenbereit" und "blockiert" bezeichneten Zuständen um eine Teilmenge der im ersten Satz genannten handelt, wäre die Information schneller erfassbar, wenn die Zustände auch exakt so wie im ersten Satz bezeichnet werden würden - also "aktiv" statt "rechnend", "bereit" statt "rechenbereit". 84.189.202.21 08:10, 6. Aug. 2015 (CEST)

Kritik am Abschnitt Threaddarstellung in UML

Nach mehrmaligem Durchlesen halte ich den Abschnitt für ein Essay, anregend zwar, aber vom Stil her etwas für Experten, was Wikipedia nicht sein sollte.

• Threads sind ein Element von Laufzeitumgebungen oder in der Programmierung, UML ist ein Werkzeug des Designs, das verbindet sich enzyklopädisch nicht so gut. Mit UML soll natürlich Parallelität spezifiziert werden können, doch wie daraus Threads oder Kubernetes-Pods oder gar eigenständige Calls zu einem Server in Programmiersprache X werden, muss im UML-Design nicht direkt vorkommen, auch wenn es dazu Design-Festlegungen gibt.
• Das im zweiten Absatz erwähnte Tool Rhapsody erinnert mich an Werkzeuge zur automatischen Codegenerierung, früher wurde mal von Modellgetriebener Architektur gesprochen. Wenn das überhaupt jemand kapiert, dann nicht in 5 Sätzen, also ist das hier kontraproduktiv und auch nur eine von mehreren Möglichkeiten, UML anzuwenden.
• Der letzte Teilabschnitt (über ein Programmier-Modell) enthält kein UML-Diagramm, da fehlt mir ein anschauliches Beispiel. Mir scheint es hier allerdings eher um Design Patterns wie z.B. Command oder Template Method zu gehen, als um UML-Diagramme.

Daher würde ich diesen Abschnitt zurückbauen und könnte mir das wie folgt vorstellen

• In den jeweiligen Artikeln über UML-Diagramme (z. B. Zustand, Aktivität, Sequenz) wird erläutert, wie sie Anforderungen über parallele Abläufe veranschaulichen können.
• Im UML-Artikel gibt es einen Abschnitt Parallelität in UML, der die für Parallelität geeigneten Diagramme anspricht.
• In Artikeln wie diesem hier oder wie parallele Programmierung wird Parallelität in UML nur kurz verlinkt.

--T. Wirbitzki (Diskussion) 01:16, 21. Jul. 2023 (CEST)