pretecs Weblog

08.07.2004

Morgen gehts zum Zelten…

Filed under: pretecs blog — pretec @ 22:47

Die mündliche Prüfung heute war ein voller Erfolg. Rund 20 Minuten im Schnelldurchlauf Objektorientierte Programmierung und Threads erklärt. Der Dozent war sehr zufrieden :-). Ich zitiere aus seiner E-Mail:

Ihr Prüfungsauftritt war astrein und obendrein unterhaltsam!
Sie wissen es inzwischen wohl schon über die Relaisstation Walhalla, sollen
aber auch von mir direkt noch einmal erfahren, dass Sie mir eine Freude mit
der Vorstellung gemacht haben!
Note natürlich 1 - Wie kam eigentlich diese Vornote 2 zustande?
( temporär geschlampt ?!? )

Das Walhalla ist übrigens eine Kneipe in direkter Nachbarschaft der Technikerschule. Natürlich sind wir dort wiedermal versackt ;-).

Morgen wollen wir zelten fahren, man beachte mal das Wetter auf dem Weatherpixi….

Tolles Wetter zum Zelten

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…

03.07.2004

Kranke Traurige Welt III

Filed under: Sick Sad World — pretec @ 21:59

Hip Hop macht doof.
http://absynth.de/serendipity/uploads/metal.jpg

Ekliges Wetter heute

Filed under: pretecs blog — pretec @ 15:37

Heute regnets den ganzen Tag andauernd. Zwar scheint zwischendurch auch immer mal wieder die Sonne, aber zum Radfahren oder ähnlichen Outdoor-Aktivitäten ist das Wetter zu wankelmütig.

Also sitz ich vor der Kiste und zerbrösele das LCDGraph-Plugin vom VDR-Projekt. Ich hab mir vor Jahren mal äußerst günstig ein paar Hitachi LMG7400 Graphik LCDs geschossen, leider hab ich dafür nie einen verwertbaren Treiber gefunden. Heute ist mir mal aufgefallen, dass es ein Plugin für den VDR gibt, das genau mein LCD unterstützt. Also zerbröseln, rausfinden, wie das Ding funktioniert und selber was schreiben.

Gestern morgen war grosses Fressen (auch Mövenpick Morgenland genannt) bei Mövenpick im Europacenter. Wie immer ist mir hinterher wieder barbarisch schlecht gewesen :-).

Seit Mittwoch abend weiss ich, dass ich in der “OOP”-Prüfung vor einer Woche eine 1.3 gemacht habe. Das bringt die Chance mit, in einer mündlichen Prüfung die Endnote nach oben zu korrigieren. Wer lässt sich schon eine weitere Eins auf dem Zeugniss entgehen ;-). Nur das Thema steht noch nicht so richtig fest, entweder “Threads - Aufzucht und Pflege” oder “Ereignissgesteuerte Programme” ( oder irgendwas ganz ekliges, was ich aber nicht hoffe …).

« Previous Page

Powered by WordPress