pretecs Weblog

07.07.2004

Sachen, die man mal über Threads gehört haben soll :-)

Filed under: IRC-Quotes — pretec @ 19:09

<pretec> Kann man allgemein sagen, dass der Wechsel zwischen den Threads einer Multithreading-Applikation schneller geht, als der Context Switch zwischen Prozessen?

<Lalufu> pretec: das kommt sehr darauf an.
<Lalufu> Linux hat ziemlich schnelle Prozesswechsel.
<Lalufu> Windows ist da entschieden langsamer, darum stehen die so auf Threads.
<pretec> Ahh
<Lalufu> solaris ist wohl auch nicht gerade rasend schnell im context switchen.

<pretec> Lalufu: Unter windows benutzt man bestimmt primär Kernelthreads, oder?

<isotopp_> pretec: die aussage, was wie viel kostet ist sehr betriebssystem- und versionsabhängig.
<isotopp_> pretec: in linux, insbesondere in 2.6, sind die kosten für einen prozeß und einen threadwechsel nahezu gleich.

<isotopp_> pretec: und linux wechselt zwischen prozessen schneller als etwa ein win2000 zwischen threads.
<Lalufu> Bildet linux nicht eh’ threads auf prozesse ab?
<isotopp_> Lalufu: so ähnlich. linux hat clone() als verallgemeinerung von fork()

<isotopp_> Lalufu: und dann eine bibliothek, die clone() mit threadsemantik verwendet udn ein wenig management umgibt
<isotopp_> Lalufu: wahlweise pthreads als teil von glibc oder andere threading-bibliotheken. es gibt bestimmt 4 oder 5 davon
<isotopp_> pretec, Lalufu dabei gibt es verschiedene modelle - eine solche bibliothek kann einen bibliotheksthread auf einen kernelthread abbilden oder nicht.
<isotopp_> man ist da vollkommen frei.

<isotopp_> die redhat leute waren als erste mutig genug, alle userland-threads auf jeweils einen kernelthread zu mappen.
<Lalufu> NTPL?
<isotopp_> auch für eine million threads…
<Lalufu> Aeh, NPTL
<isotopp_> ja, ich glaube so hieß das.

<isotopp_> setzt dann aber dringend 2.6 mit o(1) scheduler voraus.
<Lalufu> RH hatte backports auf 2.4
<isotopp_> FÜr den Scheduler?
<Lalufu> Fuer NPTL, auf alle faelle.
<isotopp_> ohne O(1) ist das wie gesagt mittelsinnvoll :)
<Lalufu> Es gbit auch einen O(1) Backport.

<pretec> isotopp_: Wenn Thread/Prozesswechsel gleich schnell sind, kann man eine allgemeine Aussage machen, wann man Multithreaded werden soll und wann man einfach nochmal forkt?

<Lalufu> pretec: ist der Vorteil von Threads nicht, dass man geteilte Adressraeume hat?
<pretec> Lalufu: Ja auch. Aber ist das der einzige Grund dafür?
<pretec> Je mehr ich darüber lese, desto verwirrter werde ich :)
<pretec> Ich muss mein Programm auf eine Threadbibliothek aufsetzen, um es multithreaded zu machen. Wenn ich mein Programm einfach ein zweites Mal starte, muss ich mir darum keine Gedanken machen

<Lalufu> Dann musst Du Dich aber auch selbst um die Sachen kuemmern, die die Threadbibliothek fuer Dich macht.
<pretec> Lalufu: was wäre das? *Ich nix Ahnung*
<Lalufu> Andererseits brauchst Du keine Gedanken an Funktionen zu verschwenden, die nicht threadsafe sind. Und glibc hat davon einige :)
<pretec> slep() :-)
<pretec> sleep
<pretec> zB :-)
<Lalufu> gethostbyname, z.B.
<MaxiPalle> re
<pretec> Das war die einzige Funktion, die ich in meinm Thread verwenden wollte und die will grade nicht :)
<Lalufu> Und der ganze restliche Nameresolutionzoo,.

* pretec weiss immernoch keine gute Antwort auf die Frage: “Wann soll man Threads verwenden?”

<Isotopp> pretec: in linux macht es von der performance her kaum einen unterschied ob man threaded oder forkt.
<Isotopp> pretec: der unterschied ist also nur die kommunikationsstrategie der komponenten.
<Isotopp> pretec: in threaded programmen haben mehrere kontrollflüsse (programmzähler plus register plus stack) einen gemeinsamen adreßraum (code, daten, bss, heap)
<Isotopp> pretec: die kontrollflüsse müssen sich dann bewußt darum kümmern, daß sie sich nicht gegenseitig ressourcen (variablen, signale, filehandles usw) streitig machen.
<Isotopp> pretec: in prozessen ist der default andersrum: ein kontrollfluß pro umgebung. wenn kontrollflüsse (hier == prozesse) miteinander kommunizieren wollen, müssen sie sich aktiv drum kümmern.
<Isotopp> pretec: es bestehen möglichkeiten signale, filehandles oder speicher zwischen prozessen hin und her zu schießen, aber sie sind nicht so … bequem wie in threads.
<Isotopp> pretec: typisches beispiel für den multiprozeßansatz ist oracle.
<Isotopp> pretec: hier hast du fünf plus x prozesse, also getrennte entititäten, die zusammenarbeiten um den datenbankserver zu realisieren.
<Isotopp> pretec: kommuniziert wird über die sga, system global area, ein shared memory segment.
<Isotopp> pretec: auf dem der logwriter, die kundenprozesse und so weiter rumorgeln.
<Isotopp> pretec: typisches beispiel für einen multithreadansatz ist mysql, das selbiges mit threads erledigt.
<Isotopp> pretec: für threads sprechen (unter windows) die deutlich bessere performance. dieses argument hat sich in linux überholt.
<Isotopp> pretec: gegen treads sprechen (unter linux) die deutlich schlechteren debuggingmöglichkeiten und die deutlich schlechtere ausrichtung der toolchain auf threads.
<Isotopp> pretec: viele unix bibliotheken sind nicht threadsafe, gdb ist behindert und so weite.
<Isotopp> traditionell ist es so, daß windows-programme eher threads verwenden (müssen) und daher
<Isotopp> von vorneherein auch die debugger, bibliotheken et al auf threads ausgelegt sind,
<Isotopp> und daß in linux/unix threads “optional” sind, und mit dem linux-kernel auch nicht mehr notwendig sind.

<Isotopp> pretec: glibc zum beispiel hat erst mit der 2.3 so richtig tls bekommen, und was für einen aufwand zend/php 5 treiben müssen, um mt safe zu werden kann man auf der zend/php mailingliste nachlesen.
<Isotopp> tls = thread local storage.
<Isotopp> Das ist quasi das gegenteil zu shared memory.
<Isotopp> in threads ist ja alles memory per default shared, und tls ist quasi “unshared memory”.
<Isotopp> genauer ist tls eine serie von n zeigern, und ein thread kann sich dann speicher bestellen und den zeiger auf den speicher lokal in seinem tls ablegen.
<Isotopp> die hoffnung ist dann, daß kein anderer thread diesen speicher findet und aus versehen überschreibt.
<weigon_> ich mag threads nicht
<Isotopp> in linux/unix saugen sie eher und haben mehr nach- als vorteile.
<Isotopp> in windows sind sie essentiell und besser unterstützt.
<weigon_> in der java welt auch
<Isotopp> ja. und dort sind sie auch ein ständiger quell von performance- und stabilitätsproblemen.
<weigon_> so wie überall :)
<Isotopp> die meisten leute glauben, daß es leichter sei, für jeden request einen thread zu starten als eine eventschleife mit select() sinnvoll zu programmieren und selber zu schedulen.
<Isotopp> ist es auch, außer man hat last.
<pretec> Ohh, Informationsflut
<weigon_> zu dem thema gibt eine gute |bersicht auf http://www.kegel.com/c10k.html

<pretec> isotopp_: Gut. Ich nehme also mit: Threads sollten abhängig von der benutzten Plattform und vom benutzten Kommunikationsmodell der Applikation benutzt/nicht benutzt werden. Threads lassen sich unter Windows traditionell besser entwickel als mit GNU/Linux-Toolchains.
<Isotopp> pretec: ja.
<pretec> fein :-) Danke!
<Isotopp> pretec: wobei die kommunikationsmodelle nicht mächtiger sind als das jeweils andere.
<Isotopp> pretec: du kannst zumindest prinzipiell jedes problem wahlweise mit prozessen oder threads lösen.

Neue Kategorie und morgen mündliche Prüfung

Filed under: pretecs blog — pretec @ 19:04

Ich hab nun eine neue Kategorie eingerichtet “IRC-Quotes”. Das soll nicht die n-te bash.org Reinkarnation werden, sondern mein eigenes “IRC-Merkblatt”. Denn im #lug-kiel Channel werden des öfteren Mal Wissensmengen abgegeben, die niedergeschrieben werden sollten. :-)

Die gestrige Geburtstagsparty von meiner Oma war sehr erheiternd, nach 2 Cocktails hab ich grademal 43 Punkte in einem Bowling-Durchgang (heisst das Frame?) geschafft…

Powered by WordPress