<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.
