Diskussion:Thread (Informatik)

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)

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)