wozo threads
-
kann mir jemand mal ein beispiel nennen wo die nutzung von threads sinnvoll ist, also auch etwas bringt
-
Bei nem Pentium 4 mit 3,06 GHz und Hyperthreading.
...oder bei einem Multiprozessorsystem....oder bei einem Programm, bei dem du etwas im Hintergrund machen möchtest, im Vordergrund aber immernoch arbeiten willst.
-
Ich denke, du bist eher auf einen Vergleich Prozess vs. Thread aus?
-Also Threads nutzen die gleichen globalen Variablen, deswegen kann es praktisch sein, wenn du viel IPC benutzt Threads zu benutzen (aber schön den Zugriff auf die Variablen absichern ;))
-Threads können leicht schneller erzeugt werden, weswegen gerade auf Systeme, die schlecht Prozesse erzeugen können Threads bevorzugt werden (Windows als Beispiel)
der Nachteil ist, dass ein Thread, der hängt/abstürzt dein ganzes Programm beeinflussen kann!
-
Ich denke, Schachprogramme und andere rechenintensive Software arbeiten mit MT.
z.B.:"... enthält Shredder 6 neben der deutlich spielstärkeren Shredder6-Engine für Single-Prozessoren auch gleich die für Multiprozessoren optimierte DeepShredder6 Engine."siehe z.B. auch hier: http://www.adp-gmbh.ch/tsu/WP/07_ndi_h01.html
-
Die können genau so gut auch Prozesser verwenden, das besagt ja nicht, dass sie Thread nehmen
-
Original erstellt von kingruedi:
der Nachteil ist, dass ein Thread, der hängt/abstürzt dein ganzes Programm beeinflussen kann!Nicht wirklich ein Nachteil - wäre die Funktion im Hauptprogramm abgestürzt, wäre das Programm auch "beeinflusst". Abstürze sind immer ein großes Problem, unabhängig von den Threads.
Als Nachteil würde ich eher die Möglichkeit von Deadlocks nennen.
Größter Vorteil ist eigentlich die Strukturierungsmöglichkeit - parallele Vorgänge lassen sich in parallele logische Module in eigenem Thread aufteilen, das erhöht die Übersichtlichkeit von Programmen enorm. Gerade in Kombination mit Klassen sehr schön, wenn man verschiedene Worker-Klassen in eigenem Thread laufen läßt. Daß das Programm auf einem Doppelprozessorsystem dadurch schneller läuft ist nur ein Bonbon aber im Regelfalle wohl kaum das Primärziel (außer vielleicht bei einer rechenintensiven Anwendung, dort wird man Threads aber nach ganz anderen Gesichtspunkten aufteilen).
-
naja es ist aber eine Sicherheit, dass ein Prozess nicht den ganzen Server krascht. In dem Bereich finde ist auch noch sehr wichtig, dass Thread Programmierer sehr penibel bei der Speicherverwaltung sein müssen (was man natürlich eh sein sollte ;)), da sich die Fehler fortpflanzen und man nach n Aufrufen von Threads, die b bytes nicht richtig freigeben n*b unfreigegeben bytes hat, was natürlich nach einer Uptime u dafür sorgt, dass das Systemcrasht. Bei Prozessen ist das ein geringeres Problem. Also muss man bei Threads sehr penibel beim programmieren sein!
Aber ein weiterer Vorteil von Threads, sind die billigen Erzeugungs Kosten, so kann ein Thinkpad 600X mit 320MB RAM mehr als 10000 Threads pro Sekunde erzeugen, schafft aber nur knapp 325 Threads mit Linux.
-
Original erstellt von kingruedi:
In dem Bereich finde ist auch noch sehr wichtig, dass Thread Programmierer sehr penibel bei der Speicherverwaltung sein müssen (was man natürlich eh sein sollte ;)), da sich die Fehler fortpflanzen und man nach n Aufrufen von Threads, die b bytes nicht richtig freigeben n*b unfreigegeben bytes hat, was natürlich nach einer Uptime u dafür sorgt, dass das Systemcrasht.Kann ich nicht nachvollziehen.
Wenn ich n Aufrufe von Threads habe, so hatte ich im Programmablauf n Funktionen angestossen.
Wenn n Funktionen b Bytes Speicher verlieren, so verliere ich dort ebenfalls n * b Bytes Speicher und das System hängt irgendwann.
Ob ich nun die Funktion in einem Threadkontext aufrufe oder ganz normal über eine Message-Queue oder eine Schleife, in beiden Fällen habe ich n Aufrufe und n*b Bytes Verlust.
Ein Thread benötigt zwar gegenüber einer Funktion mehr Speicher zur Ausführung, dies wird aber vom OS erledigt, daher brauche ich nach wie vor nur auf die saubere Ausführung der Funktion zu achten. Ich sehe auch hier wieder genau wie beim Absturz kein erhöhtes Risiko für Threads.
Zum Thema Prozesse: Prozesse und Threads sind nicht austauschbar. Ein Prozeß läuft in einem eigenen Speicherbereich, er kann daher nicht mehr auf die Datenbasis des Starters zugreifen, zumindest nicht auf einem schnellen Weg über direkten Speicherzugriff. Jeder Zugriff muß dann über gemappte Files, gemappten Speicher, Pipes, Sockets oder COM, CORBA & Co implementiert werden, was bei der Aufgabe eine Datei im Hintergrund zu speichern während der Benutzer bereits wieder arbeiten kann völliger Overkill wäre.
-
Wenn ich n Aufrufe von Threads habe, so hatte ich im Programmablauf n Funktionen angestossen.
Ich meinte das im Bezug auf Threads vs. Prozesse. Weil wenn ein Prozess aufhört, dann gibt der Kernel ja idr. den kompletten Speicher frei, den der Prozess reserviert hatte, bei Threads ist das nicht so.
Ein Prozeß läuft in einem eigenen Speicherbereich, er kann daher nicht mehr auf die Datenbasis des Starters zugreifen, zumindest nicht auf einem schnellen Weg über direkten Speicherzugriff. Jeder Zugriff muß dann über gemappte Files, gemappten Speicher, Pipes, Sockets oder COM, CORBA & Co implementiert werden, was bei der Aufgabe eine Datei im Hintergrund zu speichern während der Benutzer bereits wieder arbeiten kann völliger Overkill wäre.
Jup, aber ein Prozess kann doch auf die Variablen des startenden Prozesses zugreifen, nur beim schreiben schreibt er auf eine eigene Kopie (Copy on Write) oder bei alten Kernels wir der komplette Speicherbereich sofort kopiert, also die auf die Werte kann er auf jeden Fall zugreifen, wenn man sehr intensiv IP braucht, dann sind wie gesagt Threads definitiv besser, aber zum Beispiel bei einem Server, wo jeder Prozess einen Client behandelt, kann ein Prozess ganz vorteil haft sein.
-
Auf Variablen kann er zugreifen, nicht aber auf Objekte. Das limitiert die Anwendungsfälle doch schon mal erheblich.
Schon klar, ein Prozeß ist letztlich ein neues Programm, darauf läuft es raus.
Aber ich behaupte mal frech, daß 90% der parallelisierbaren Vorgänge in einer Anwendung kein neues Programm benötigen, sondern Zugriff auf die Datenbasis besitzen müssen.
So ganz triviale Dinge... ein Thread bearbeitet die serielle Schnittstelle, ein Thread kümmert sich um die GUI, ein Thread übernimmt die interne Kommunikation zwischen den Treibern und der Datenbasis, usw.
-
ja, da muss ich dir recht geben. Ich will ja gar nicht sagen, dass Threads sinnlos sind, nur, dass Prozesse auch ein Recht auf Existenz haben.