Threads



  • Hallo,

    es gibt den Prozess scheduler.
    Gibt es auch einen Thread scheduler?



  • Gibt es auch einen blurry333-Locker?



  • Ja. Im Kernel, komplett abgeschottet von praktisch allem, was Hände und Füsse hat.



  • blurry333 schrieb:

    Hallo,

    es gibt den Prozess scheduler.
    Gibt es auch einen Thread scheduler?

    Das kommt darauf an, wenn dein Betriebssystem sowohl (Kernel-Threads) als auch Prozesse anbietet dann kann es schon sein, dass es zwei Scheduler integriert hat. Einmal für Prozesse und einmal für Threads. Wahrscheinlicher ist aber, dass solch ein System einfach nur Threads scheduled.

    Linux zum Beispiel hat etwas das sie Tasks nennen (je nachdem wie eine neue Task erzeugt wird ist sie Thread, Prozess, oder etwas in der Mitte) und scheduled ausschließlich diese.

    Dann gibt es je nach System nicht nur einen Scheduler, sondern mehrere, Linux hat aktuell drei (wenn mein Wissen nicht überholt ist) einen Echtzeitscheduler (alle Echtzeitthreads haben immer Vorrang), einen normalen Scheduler (das an was du denkst) und einen Batch-Scheduler für Aufgaben die wenig wichtig sind und im Hintergrund so vor sich hin dümpeln.

    Aber egal wie und was ein System hat, die Idee und Algorithmen dahinter sind immer gleich/ähnlich und man entscheidet sich dann für den einen oder anderen Algorithmus je nach gewünschten Anforderungen. Und typischerweise findest du in einem normalen Betriebssystem keinen Algorithmus der in einem normale Betriebssysteme Lehrbuch vorgestellt wird. Die realen sind meist deutlich komplexer mit mehr heuristiken und Sonderfällen um vor Missbrauch zu schützen, etc.



  • Im Prinzip ist die Trennung künstlich, Prozesse und Threads sind für einen Scheduler das gleiche.

    Was ein Unterschied ist, dass mehrere Threads eines Programmes den selben Speicherbereich benutzen. Dies wird im Scheduler beachtet, weil das Optimierungspotential bietet. Zum Beispiel ist es sinnvoll, dass Threads eines Programmes auf der selben CPU laufen, weil dann nicht der Speicher-Cache neu gefüllt werden muss.



  • earli schrieb:

    Im Prinzip ist die Trennung künstlich, Prozesse und Threads sind für einen Scheduler das gleiche.

    Was ein Unterschied ist, dass mehrere Threads eines Programmes den selben Speicherbereich benutzen. Dies wird im Scheduler beachtet, weil das Optimierungspotential bietet. Zum Beispiel ist es sinnvoll, dass Threads eines Programmes auf der selben CPU laufen, weil dann nicht der Speicher-Cache neu gefüllt werden muss.

    Nicht zwingend, das kann auch genau die falsche Entscheidung sein. Die Threads könnten keine gemeinsamen Daten verwenden, sondern über Nachrichten-Austausch kommunizieren und verschiedene Code-Teile ausführen. Da würden sie sogar von getrennten Caches profitieren, statt sich gegenseitig die Cache-Zeilen zu verdrängen.



  • fuer den scheduler sind es immer threads, aber sie werden durchaus oefter in groups gesteckt (haengt aber vom jeweiligen kernel ab). wenn du z.b. ein video schauen willst und dazu den kernel mit 10 threads compilieren moechtest, willst du sicher nicht, dass dein video ruckelt oder die UI deines desktops nicht mehr bedienbar ist.
    deswegen ist eine moegliche strategie, dass z.b. deine konsole eine thread group definiert, alles was du daraus startest, wird vom scheduler in einem gemeinsammen budget versehen, wenn du dann ein movie schaust, bekommen beide groups (console und video player) je 50% cpu zeit, in der consolen group bekommen dann die 10 compilier threads ihre 5% der cpu.
    andereseits willst du sich nicht, dass auf deinem server irgend eine gui rechenzeit verschwendet, dort bekommt dann jeder thread das gleiche budget.

    auf win7 werden die threads eines prozesses moeglichst ebenmaessig auf cores verteilt, auf win8 auf bulldozern werden die threads eines processes moeglichst auf den selben core ausgefuehrt.

    von daher wissen die scheduler einiges mehr als nur threads.



  • rapso schrieb:

    fuer den scheduler sind es immer threads, aber sie werden durchaus oefter in groups gesteckt (haengt aber vom jeweiligen kernel ab). wenn du z.b. ein video schauen willst und dazu den kernel mit 10 threads compilieren moechtest, willst du sicher nicht, dass dein video ruckelt oder die UI deines desktops nicht mehr bedienbar ist.
    deswegen ist eine moegliche strategie, dass z.b. deine konsole eine thread group definiert, alles was du daraus startest, wird vom scheduler in einem gemeinsammen budget versehen, wenn du dann ein movie schaust, bekommen beide groups (console und video player) je 50% cpu zeit, in der consolen group bekommen dann die 10 compilier threads ihre 5% der cpu.
    andereseits willst du sich nicht, dass auf deinem server irgend eine gui rechenzeit verschwendet, dort bekommt dann jeder thread das gleiche budget.

    auf win7 werden die threads eines prozesses moeglichst ebenmaessig auf cores verteilt, auf win8 auf bulldozern werden die threads eines processes moeglichst auf den selben core ausgefuehrt.

    von daher wissen die scheduler einiges mehr als nur threads.

    Da sind Windows und Unix unterschiedlich.

    - Bei Windows (NT) gibt es erstmal nur Threads. Diese werden dann zu Prozessen zusammengefasst.
    - Bei Linux/Unix gibt es erstmal nur Prozesse. Doch dann gibt es Prozesse mit gemeinsamen Speicher und Code, die sich praktisch wie Threads verhalten.

    Die Datenstrukturen im System sind also grundverschieden aufgebaut. Praktisch kommt aber am Ende das selbe heraus, der Unterschiede sind rein historischer Natur.



  • earli schrieb:

    rapso schrieb:

    fuer den scheduler sind es immer threads, aber sie werden durchaus oefter in groups gesteckt (haengt aber vom jeweiligen kernel ab). wenn du z.b. ein video schauen willst und dazu den kernel mit 10 threads compilieren moechtest, willst du sicher nicht, dass dein video ruckelt oder die UI deines desktops nicht mehr bedienbar ist.
    deswegen ist eine moegliche strategie, dass z.b. deine konsole eine thread group definiert, alles was du daraus startest, wird vom scheduler in einem gemeinsammen budget versehen, wenn du dann ein movie schaust, bekommen beide groups (console und video player) je 50% cpu zeit, in der consolen group bekommen dann die 10 compilier threads ihre 5% der cpu.
    andereseits willst du sich nicht, dass auf deinem server irgend eine gui rechenzeit verschwendet, dort bekommt dann jeder thread das gleiche budget.

    auf win7 werden die threads eines prozesses moeglichst ebenmaessig auf cores verteilt, auf win8 auf bulldozern werden die threads eines processes moeglichst auf den selben core ausgefuehrt.

    von daher wissen die scheduler einiges mehr als nur threads.

    Da sind Windows und Unix unterschiedlich.

    - Bei Windows (NT) gibt es erstmal nur Threads. Diese werden dann zu Prozessen zusammengefasst.
    - Bei Linux/Unix gibt es erstmal nur Prozesse. Doch dann gibt es Prozesse mit gemeinsamen Speicher und Code, die sich praktisch wie Threads verhalten.

    Die Datenstrukturen im System sind also grundverschieden aufgebaut. Praktisch kommt aber am Ende das selbe heraus, der Unterschiede sind rein historischer Natur.

    Linux ist kein Unix und daher hat es keine Prozesse, sondern Tasks. Und die heißen aus gutem Grunde so, denn sie sind weder Prozess noch Thread, aber sie können sich bei entsprechender Konfiguration so verhalten als wären sie ein Prozess, oder ein Thread.

    Bei Linux weiß der Scheduler nichts von GUI Anwendungen und berechnet die Interaktivität nach einer Heuristik. Bei Windows dagegen weiß der Scheduler welche Prozesse gerade offene Fenster haben und welchem Prozess das Fenster im Vordergrund/mit Fokus gehört und bevorzugt das entsprechend.

    Windows hat zudem noch Fibers und tausend Dinge die ich nicht kenne, aber jeder der sich mal dieses "Inside the Windows Kernel" (oder so ähnlich) Buch angesehen hat, hat zumindest eine grobe Vorstellung wie komplex so ein System in der Realität ist.

    @raspo, war dein Gruppen-Szenario auf etwas konkretes bezogen? Kenne das von Linux, dort heißen diese Gruppen "cgroups" (control groups), aber soweit ich weiß hat das kein (anderes) Unix. Hat Windows so etwas auch?



  • Linuxxer schrieb:

    Bei Linux weiß der Scheduler nichts von GUI Anwendungen und berechnet die Interaktivität nach einer Heuristik. Bei Windows dagegen weiß der Scheduler welche Prozesse gerade offene Fenster haben und welchem Prozess das Fenster im Vordergrund/mit Fokus gehört und bevorzugt das entsprechend.

    Das stimmt, aber ist nicht ganz aktuell.

    Seit einer Weile jetzt hat Linux den Completely Fair Scheduler (CFS), dieser merkt sich bei jedem Prozess die Laufzeit. Es hat sich herausgestellt, dass die allerbeste Heurestik keine Heurestik ist.
    Auch Programme mit Fenstern reagieren so schneller als mit irgendwelchen Maßnahmen (damit ist auch die von die beschriebene Variante in Windows gemeint), die zu verstehen versuchen, was am besten ist.

    Mehr Infos:

    http://en.wikipedia.org/wiki/Completely_Fair_Scheduler

    http://www.ibm.com/developerworks/linux/library/l-completely-fair-scheduler/



  • Linuxxer schrieb:

    Linux ist kein Unix und daher hat es keine Prozesse, sondern Tasks. Und die heißen aus gutem Grunde so, denn sie sind weder Prozess noch Thread, aber sie können sich bei entsprechender Konfiguration so verhalten als wären sie ein Prozess, oder ein Thread.

    Thread, Task und Process haben je nach Betriebssystem verschiedene Bedeutungen. Es gibt IMHO keine allgemeingültige Definition, was was ist.



  • Linuxxer schrieb:

    Linux ist kein Unix und daher hat es keine Prozesse, sondern Tasks. Und die heißen aus gutem Grunde so, denn sie sind weder Prozess noch Thread, aber sie können sich bei entsprechender Konfiguration so verhalten als wären sie ein Prozess, oder ein Thread.

    wie du schon sagst, die dinge sind frei konfigurierbar bei linux, ich glaube default ist das verhalten mit den groups als hierarchystufe zu threads. irgendwo bei heise stand mal dass linus das verhalten bevorzugt, obwohl es da natuerlich streit gibt in den mailing lists.

    Bei Linux weiß der Scheduler nichts von GUI Anwendungen und berechnet die Interaktivität nach einer Heuristik. Bei Windows dagegen weiß der Scheduler welche Prozesse gerade offene Fenster haben und welchem Prozess das Fenster im Vordergrund/mit Fokus gehört und bevorzugt das entsprechend.

    ich glaube das wollte man mit den groups verbessern, wobei es an sich ja nur eine hard gecodete heuristic fuers scheduling ist.

    Windows hat zudem noch Fibers und tausend Dinge die ich nicht kenne, aber jeder der sich mal dieses "Inside the Windows Kernel" (oder so ähnlich) Buch angesehen hat, hat zumindest eine grobe Vorstellung wie komplex so ein System in der Realität ist.

    zu komplex eigentlich, ich nutze fiber unter linux und auf konsolen schon seit ewigkeiten (ist ja nicht mehr als ein user space thread), was es ein wenig paradox macht, dass windows das als kerenel feature hat und nicht als runtime. (ich hab es nicht ueberprueft, ich vertraue dir hier blind 😉 )

    @raspo, war dein Gruppen-Szenario auf etwas konkretes bezogen? Kenne das von Linux, dort heißen diese Gruppen "cgroups" (control groups), aber soweit ich weiß hat das kein (anderes) Unix. Hat Windows so etwas auch?

    ich bezog mich da auch auf linux, linux hat aber viele scheduler, afaik haben ibm,hp usw. sogar ziemlich auf die benchmarks getrimmte versionen.
    windows ist eher hardware ausgelegt, je nach cpu wird da anders verteilt. Penryn cpus haben zwei dual core dies pro cpu, da macht es sinn zusammenhaengende teile auf moeglichst dem selben die laufen zu lassen. Nahalem hat jeden zweiden 'core' nur ein thread, da macht es sinn wegen caches usw. erstmal die echten cores auszulasten. Bulldozer hat die beste performance wenn man die hyper threads auslastet, weil dann viel overclockt werden kann (4.3Ghz statt 3.6Ghz, afaik). und es gibt noch feinheiten bei mobile cpus, damit die im gut power sparen.



  • rapso schrieb:

    Windows hat zudem noch Fibers und tausend Dinge die ich nicht kenne, aber jeder der sich mal dieses "Inside the Windows Kernel" (oder so ähnlich) Buch angesehen hat, hat zumindest eine grobe Vorstellung wie komplex so ein System in der Realität ist.

    zu komplex eigentlich, ich nutze fiber unter linux und auf konsolen schon seit ewigkeiten (ist ja nicht mehr als ein user space thread), was es ein wenig paradox macht, dass windows das als kerenel feature hat und nicht als runtime. (ich hab es nicht ueberprueft, ich vertraue dir hier blind 😉 )

    Ich nicht.



  • volkard schrieb:

    rapso schrieb:

    Windows hat zudem noch Fibers und tausend Dinge die ich nicht kenne, aber jeder der sich mal dieses "Inside the Windows Kernel" (oder so ähnlich) Buch angesehen hat, hat zumindest eine grobe Vorstellung wie komplex so ein System in der Realität ist.

    zu komplex eigentlich, ich nutze fiber unter linux und auf konsolen schon seit ewigkeiten (ist ja nicht mehr als ein user space thread), was es ein wenig paradox macht, dass windows das als kerenel feature hat und nicht als runtime. (ich hab es nicht ueberprueft, ich vertraue dir hier blind 😉 )

    Ich nicht.

    Ich sag mal so viel: Windows macht es mal wieder kompliziert, aber schlecht.



  • earli schrieb:

    Linuxxer schrieb:

    Bei Linux weiß der Scheduler nichts von GUI Anwendungen und berechnet die Interaktivität nach einer Heuristik. Bei Windows dagegen weiß der Scheduler welche Prozesse gerade offene Fenster haben und welchem Prozess das Fenster im Vordergrund/mit Fokus gehört und bevorzugt das entsprechend.

    Das stimmt, aber ist nicht ganz aktuell.

    Seit einer Weile jetzt hat Linux den Completely Fair Scheduler (CFS), dieser merkt sich bei jedem Prozess die Laufzeit. Es hat sich herausgestellt, dass die allerbeste Heurestik keine Heurestik ist.
    Auch Programme mit Fenstern reagieren so schneller als mit irgendwelchen Maßnahmen (damit ist auch die von die beschriebene Variante in Windows gemeint), die zu verstehen versuchen, was am besten ist.

    Ich kenne den CFS und so neu ist er ja auch nicht mehr (seit 2.6.23 laut Wikipedia, wobei ich aus dem Kopf eher 2.6.24 oder 2.6.25 gesagt hätte) und wie Wikipedia sagt klassifiziert er interaktive Tasks auch aus dem Bauch heraus:

    [quote=wikipedia]
    This means that interactive tasks which spend most of their time waiting for user input or other events get a comparable share of CPU time when they need it.
    [/quote]
    Und ich glaube es war erst dieses Jahr, dass der 200-Zeilen Patch für furore sorgte. Denn bis dahin (und auf meinem Ubuntu 10.04 bis heute) kann man nichts tun, wenn z.B. der Indexer von locate gerade läuft, oder eine Andwendung wie Opera startet und für viel I/O sorgt, da diese dann unendliche Priorität über meinem Texteditor haben, obwohl dieser im Vordergrund ist.

    @Z, naja also ich würde sagen, dass so ziemlich jeder die gleiche Vorstellung darüber hat was ein Thread ist und was ein Prozess ist. Gibt immerhin tonnenweise Betriebssystem-Literatur die diese doch einheitlich definieren.

    @rapso, die Fibres sind wohl schon in einer Userspace-Bibliothek, sonst macht das "User-Level threads" auch wenig Sinn, aber Windows hat ja keine definierte Kernel-Schnittstelle, sondern die Win32-API als offizielle Schnittstelle zum System.



  • Linuxxer schrieb:

    Und ich glaube es war erst dieses Jahr, dass der 200-Zeilen Patch für furore sorgte. Denn bis dahin (und auf meinem Ubuntu 10.04 bis heute) kann man nichts tun, wenn z.B. der Indexer von locate gerade läuft, oder eine Andwendung wie Opera startet und für viel I/O sorgt, da diese dann unendliche Priorität über meinem Texteditor haben, obwohl dieser im Vordergrund ist.

    Das war bei mir nur kurzzeitig so, und das liegt vielleicht auch an deinem Dateisystem. Daran ist nämlich der IO-Scheduler schuld, mit dem CPU-Scheduler hat das nichts zu tun. Vor allem Firefox und Opera waren so Kandidaten, weil SQLite so oft sync() gemacht hat. Da sind die Programme selbst dran Schuld, wenn sie Festplattenzugriffe erzwingen.


Log in to reply