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.
Zum Lernen ist Minix da aber deutlich übersichtlicher, deshalb mein Tip mit Tanenbaum.
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.
>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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.