Hey,
mich interessiert, wie ein Betriebssystem eigentlich Multitasking
realisiert?
Auf unterster Ebene liegt ja das ganze OS in Assembler /
Maschinensprache vor. Aber wie bildet ein OS zB einen Thread in
Assembler ab? Wie arbeitet ein Scheduler auf diesem Level, immer hin und
her jumpen zwischen den Codeblöcken? Kann man das ganz anschaulich
erklären?
Und wenn es ein Multicore-Prozessor ist: wie funktioniert dann die
Verteilung auf die Prozessoren? Gibt es da spezielle Befehle?
Wäre auch über einen Tipp froh, wo solche Dinge ausführlich erklärt
werden.
Mir bringt es auch nichts, C-Code anzuschauen, da ich ja dann trotzdem
nicht weiß, was der Compiler daraus macht, oder?
auch ein BS ist nicht in assembler geschrieben. Es gibt nur ganz wenig
code der wirklich in ASM geschrieben werdem muss. Schau doch einfach mal
in die Quellen von Linux rein, eventuell erkennt man dort etwas.
Ja, aber der Compiler übersetzt es ja in Maschinencode. Und die einzige
Schnittstelle mit der CPU ist ja der Befehlssatz. Nur frage ich mich,
wie zB die Zuteilung auf mehrere Kerne funktioniert, da es ja
anscheinend keine Befehle für sowas gibt. Aber das OS kann das.
Aber das Buch werde ich mir mal zulegen.
Der Tipp mit Tanenbaum ist doch richtig. Du brauchst erstmal ein
grundlegends Verständniss, wie ein OS aufgebaut ist.
Denn du stellst die falschen Fragen.
>Vergiss den MultiKernprozessor zum Beginnen. Der kommt spaeter.
Hat er danach gefragt?
Ich glaube er sucht das "x86 instruction set".
Grundlegendes Multitasking ist hier mit C-Code in ein paar kB erklärt:
http://www.jamesmolloy.co.uk/tutorial_html/index.html
Manuel S. schrieb:> Mir bringt es auch nichts, C-Code anzuschauen, da ich ja dann trotzdem> nicht weiß, was der Compiler daraus macht, oder?
Was hat denn die Funktionsweise eines Schedulers damit zu tun, was der
Compiler aus dem C-Code macht?
Manuel S. schrieb:> Mir bringt es auch nichts, C-Code anzuschauen, da ich ja dann trotzdem> nicht weiß, was der Compiler daraus macht, oder?
Es gibt exakt eine Stelle, wo man mit C Code allein meistens nicht
weiter kommt, und dass ist die Mechanik der
Task/Thread/Prozess/Wiedimmerduesnennst-Umschaltung. Da sich das
passenderweise meistens mit Interrupts verbindet findet man dies oft im
erweiterten Prolog/Epilog-Code von Interrupt-Handlern solcher
Betriebssysteme.
Alles Übrige lässt sich bequem in C studieren. Wenn du aber trotzdem
Assembler bevorzugst, dann kannst du die Verfahren anhand des recht
kleinen RTOS-Kernels AvrX studieren - der ist 100% Assembler.
Ohnehin: Während komplette Betriebssysteme natürlich sehr viel mehr
machen, was die Prozessverwaltung angeht, kann man die grundlegenden
Mechanismen wohl einfacher anhand eines RTOS studieren, als an
vollständigen Betriebssystemen, bei denen man den Wald vor lauter Bäumen
nicht finden. Multicore-Verwaltung wird man darin nicht finden, aber dem
sollte man sich erst widmen, wenn man die RTOS-Mechanik verstanden hat,
Synchronierungsmechanismen inklusive.
Bevor Du Dir Assembly oder C Code anschaust, fang besser mal an, die
grundlegenden Konzepte zu verstehen. Da ist das Buch von Tanenbaum (oder
auch das von Silberschatz/Galvin) sehr hilfreich. Danach kannst Du Dir
die Umsetzung der Konzepte in C und die prozessorspezifischen Details in
Assembly anschauen. Gleich dort unten anzufangen ist so als ob Du
versucht ein Verständnis der Anatomie des Elefanten mithilfe eines
Elektronenmikroskops zu erlangen... ;-)
Murkser
Hmm, ich weiß überhaupt nicht wo ich anfangen soll. Ich bin ja "nur"
Mathe-Student mit NF Info, aber ich möchte dennoch mehr von Computern
verstehen als nur Algorithmen, Rechenmodelle und Komplexitätsanalyse
(mehr machen wir leider nicht im Studium). Und mit Wikipedia kommt man
auch nicht wirklich weiter, um es richtig zu verstehen.
Vielleicht sollte ich erstmal mit einem Buch über Rechnerarchitektur
anfangen, oder? Hat jemand eine Empfehlung?
Wenn du also bei Null anfängst, dann solltest du allen realen Code
komplett ignorieren und dich an die gängigen Lehrbücher halten. Dazu
sind die da. Der Tanenbaum wurde ja bereits genannt.
Bei Rechnerarchitektur wäre das beispielsweise: Hennessy/Patterson,
Computer Architecture: A Quantitative Approach.
Und da es für einen Überblick nicht darauf ankommt, den allerneuesten
Stand zu kennen, kannst du dich dabei ggf. auch geldsparend auf dem
Gebrauchtmarkt der vorherigen Ausgabe umsehen, denn in der jeweils
aktuellen Ausgabe reissen die ein ziemliches Loch in die Kasse.
Alternativ sollte sich sowas wohl auch in der Bibliothek finden.
Ich habe ein paar Monate mit FreeRTOS auf einem AVR32 gearbeitet. Da
habe ich einen Einblick in die Task-Verwaltung bekommen.
Vermutlich ist das anders als bei einem PC, aber ich bekam zumindestens
ein Grundverständnis.
Es war in C, aber Assembler bringt keine Vorteile. Wenn auf dem Stack
Rücksprungadressen verändert werden, dann ist es egal ob in C oder Asm.
Dabei fällt mir ein, daß es in der c't mal vor etlichen
Jahren eine Reihe mit mehreren Folgen gab über RTOS+Pearl
auf 68000.
Das war auch recht gut mit Grundlagen erklärt und Beispielen.
Leider halt nicht mehr ganz aktuelle HW.
Bei Bedarf könnte ich die Artikel rauskramen.
Jo wenn man Hennesy + Tanenbaum durchgearbeitet und verstanden hat
reicht das erstmal um jede Computerdiskussion zu gewinnen und als
Klugscheißer im Freundeskreis zu gelten :D Ne im Ernst das sind wohl die
Standardwerke wenn man Verständnis für den Bereich
Rechnerarchitektur/Betriebssysteme erlangen will.
>Hmm, ich weiß überhaupt nicht wo ich anfangen soll. Ich bin ja "nur">Mathe-Student mit NF Info, aber ich möchte dennoch mehr von Computern>verstehen als nur Algorithmen, Rechenmodelle und Komplexitätsanalyse>(mehr machen wir leider nicht im Studium). Und mit Wikipedia kommt man>auch nicht wirklich weiter, um es richtig zu verstehen.>Vielleicht sollte ich erstmal mit einem Buch über Rechnerarchitektur>anfangen, oder? Hat jemand eine Empfehlung?
Wenn du meinen Link nicht liest, kann dir keiner helfen, dort ist alles
wichtige zum grundlegendensten Multitasking erklärt.
Ich beschäftige mich seit über 5 Jahren mit direkter x86 ASM und C
Programmierung und auf der Seite hab ich in drei Tagen mehr gelernt, als
das halbe Jahr davor.
Noch was vergessen....
>Es gibt exakt eine Stelle, wo man mit C Code allein meistens nicht>weiter kommt, und dass ist die Mechanik der>Task/Thread/Prozess/Wiedimmerduesnennst-Umschaltung.
Nicht unbedingt.
Das ist vor von der einen Architektur zur Anderen verschieden. Auf x86
brauchst du z.B. auch assembler und die Descriptor Tables zu laden (idt,
gdt).
Im Code für paging findet man sehr oft Assemblercode, allerdings braucht
man das nicht unbedingt, jenachdem was man machen will (siehe zum
Beispiel http://www.jamesmolloy.co.uk/tutorial_html/6.-Paging.html ).
Das umschalten zwischen den Tasks ist tricky. Das größte Problem ist,
dass dafür sehr schnell (wäre von Vorteil) zwischen verschiedenen
Speicherbereichen hin und her gehüpft werden muss.
Das schlimmste daran ist, meiner Meinung nach, die Stack-Kacke.... Pro
Task einen, jedesmal save/restore, manipulieren dass abglegte Adressen
gefunden werden, ..., ...
Nils S. schrieb:> Das ist vor von der einen Architektur zur Anderen verschieden. Auf x86> brauchst du z.B. auch assembler und die Descriptor Tables zu laden (idt,> gdt).
x86 sind ein eigene Liga. Was diese Architektur alles an historischem
Ballast mit sich rumschleppt, dass will man nicht garnicht wirklich
wissen, jedenfalls nicht am Anfang.
> Das umschalten zwischen den Tasks ist tricky.
Bei simplen Architekturen wie ARMs nicht. Bei x86 schon eher, aber bei
diesen barocken Kolossen ist mittlerweile nichts mehr einfach.
> Das größte Problem ist,> dass dafür sehr schnell (wäre von Vorteil) zwischen verschiedenen> Speicherbereichen hin und her gehüpft werden muss.
Es ist eher die Umschaltung der Speicherverwaltung (MMU), die ziemlich
auf die Performance geht. Weshalb die Hersteller der Oberklasse sich
Mühe geben, mit dieser Umschaltung nicht wie sonst üblich alles
wegzuwerfen. Aber davon sieht man im Idealfall wenig bis nichts.
> Das schlimmste daran ist, meiner Meinung nach, die Stack-Kacke....
???
A. K. schrieb:> x86 sind ein eigene Liga. Was diese Architektur alles an historischem> Ballast mit sich rumschleppt, dass will man nicht garnicht wirklich> wissen, jedenfalls nicht am Anfang.
Wobei einige Dinge durchaus ihre Eleganz haben, auch wenn sie sich
teilweise in der Praxis nicht bewährt haben. Ein Beispiel sind die Task
State Segments (TSS), die eigentlich die Möglichkeit bieten, dass der
Prozessor selbst weiss, welcher Kontext wie zu sichern ist, und den
Taskswitch weitgehend eigenständig erledigt. In der Praxis werden TSS
von gängigen x86-Betriebssystemen aber nur rudimentär benutzt (war
früher (Linux vor 1.3, Windows 3.1) mal anders, es stellte sich aber
wohl heraus, dass Software-Kontextswitching letztlich schneller und
flexibler ist), und in der Folge werden sie bei x86-64 im 64bit-Modus
auch nicht mehr voll unterstützt.
> Es ist eher die Umschaltung der Speicherverwaltung (MMU), die ziemlich> auf die Performance geht.
Was übrigens auch mit einer der Gründe ist (neben der Vereinfachung der
Datenübertragung zwischen Kernel- und Userspace), warum Betriebssysteme
den Kerneladressraum mit in den Userspace-Adressraum einblenden (z.B.
Linux auf x86 oberhalb von 3GB).
Ohne die Einblendung müsste der MMU-Kontext nicht nur bei
Prozesswechseln, sondern auch bei jedem Systemcall oder Interrupt
mehrfach gewechselt werden, mit den damit verbundenen Kosten aufgrund
des TLB-Flushes.
> Weshalb die Hersteller der Oberklasse sich> Mühe geben, mit dieser Umschaltung nicht wie sonst üblich alles> wegzuwerfen. Aber davon sieht man im Idealfall wenig bis nichts.
Und auch moderne Betriebssysteme bemühen sich, TLB-Einträge für die
immer gleichen Teile des Adressraumes (Kernelspace) nicht jedesmal mit
zu invalidieren.
Nils S. schrieb:> Das schlimmste daran ist, meiner Meinung nach, die Stack-Kacke....
Das ist doch das eleganteste überhaupt am Kontextwechsel. Durch Umsetzen
nur eines einzelnen Pointers wird der komplette dynamische State
(Call-History, lokale Variablen etc.) zwischen zwei Ausführungssträngen
umgeschaltet (wenn wir mal von einem gemeinsamen Adressraum ausgehen).
Andreas
Andreas Ferber schrieb:> früher (Linux vor 1.3, Windows 3.1) mal anders, es stellte sich aber> wohl heraus, dass Software-Kontextswitching letztlich schneller und> flexibler ist), und in der Folge werden sie bei x86-64 im 64bit-Modus> auch nicht mehr voll unterstützt.
Yep. Das ist sowas wie die Eleganz des eigentlich vorgesehenen Befehls
für den Prozeduraufruf bei der VAX, den auch nur jene verwendet haben,
die keine Zyklen zählen konnten. ;-)
> Was übrigens auch mit einer der Gründe ist (neben der Vereinfachung der> Datenübertragung zwischen Kernel- und Userspace), warum Betriebssysteme> den Kerneladressraum mit in den Userspace-Adressraum einblenden (z.B.> Linux auf x86 oberhalb von 3GB).
Und was wohl auch einer der Gründe ist, weshalb IBMs Power Architektur
dem 32-Bit Adressraum eine Segmentierung verpasste, die sogar den
Transit zur 64-Bit Architektur überlebt hat. Weil im so entstehenden
Gesamtadressraum alle Prozesse sowie Kernel Platz finden, ohne dass dies
auf Prozessebene sichtbar ist.
