Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
Fragen zur Klausur
ich hab’ eine Frage zur Klausur bekommen - nachdem solche Sachen vielleicht mehr Leute bewegen, kopier ich meine Antwort auch mal hier rein:
Hallo,
ich bin beim Wiederholen der SP1-Vorlesung hängengeblieben bei einem
Beispiel zum Pentium 4 (E37-E42). Ist das klausurrelevant bzw wie detailliert soll man hier
Bescheid wissen?
Also generell geht’s uns immer mehr darum, dass Grundprinzipien
verstanden wurden als dass irgendwelche fummeligen Details einer
bestimmten Implementierung auswendig gelernt werden.
Segmentierung, Seitenaddr und die Kombination davon, aber auch viele
Details in diesem Zusammenhang (z.B. was in den Deskriptoren stehen
kann und wozu das gut ist - z.B. Rechte, Dirty-Bit, Access-Bit,
Praesenz-Bit usw.) sind prinzipielle Dinge - wenn man sowas kapiert
hat, wird man die Funktion jeder MMU leicht verstehen koennen.
Wie das nun genau beim Pentium funktioniert sind Details die
man jederzeit in der Prozessorbeschreibung nachlesen kann.
Sowas auswendig zu lernen ist Schwachsinn - also wuerde ich
auch nicht in der Klausur danach fragen.
fragen
Klausurrelevanz
Hi,
ich habe zum Thema Klausurrelevanz auch ein Paar Fragen.
Prof. Schröder-Preikschat hat in den Vorlesungen 2 mal kleine Bereiche übersprungen. Sind diese dennoch Relevant?
Es geht um folgende Folien:
- Banker’s Algorithm H22-H26
- Erkennung durch Reduktionsverfahren H34-H36
Dann hat er in der Vorlesung über Capability-basierte Systeme (Bsp. Hydra) angedeutet, dass dies nicht in der Klausur dran kommt - stimmt dies?
Die letzte Frage erübrigt sich eigentlich, da sie eigentlich schon indirekt im vorletzten Post beantwortet wurde. Dennoch: Gilt für das Beispiel Modulkonzept beim Pentium I34-I42 das gleiche, wie im vorletzten Post (sicher ist sicher 
) ?
Vielen Dank
mein Gott, wie sollen aus Euch mal ordentliche Theoretiker werden?
Aber um ehrlich zu sein, muesste ich mir das auch erst mal genauer anschauen -
man braucht diese Algorithmen halt doch nicht jeden Tag im Leben eines
Betriebssystemforschers.
Ich glaub’ ich denk’ mir das besser keine dummen Fragen dazu aus.
Was aber nicht heisst, dass man nicht zumindest wissen sollte, wozu diese
Sachen erfunden wurden, auch wenn man nicht weiss, wie sie im Detail funktionieren -
und das ist gleich eine Grundregel fuer die Klausur - weclhe Konzepte wofuer
da sind, da muss man einen breiten Ueberblick haben, sonst weiss man im
Enrnstfall ja nicht mal, wonach man suchen muss, wenn man ein Problem loesen will.
Bei den wichtigen Dingen muss man aber natuerlich auch tiefergehendes Wissen haben.
Da muss ich ihn nochmal interviewen, wie viel oder wenig er darueber erzaehlt hat.
Was Capabilities konzeptionell sind, find’ ich unheimlich wichtig - wie das in Hydra
im Detail aussieht ist eher historisch interessant.
Das mit dem Pentium ist eine schwierige Geschichte. Einerseits sind bei dem Prozessor
viele konzeptionell hochinteressante Sachen umgesetzt worden (ich hab’ in einem anderen
Post ja die Speicherverwaltung mal im Gegensatz zu dem Multics-Konzept kurz
skizziert) - eben auch das Modulkonzept. Andererseits ist das alles mit einem Haufen
Details verbunden, die man im Zweifelsfall immer nachlesen kann.
Auch hier muss ich nochmal nachfragen, was alles in der Vorlesung dazu
erzaehlt wurde (da sind jetzt alle die in der Vorl. waren und zugehoert haben
echt im Vorteil :-).
Aber wenn ich ueber diese Dinge so nachdenke, da fallen mir tollsten
Klausurfragen ein 
Also so wie es aussieht kam das alles in der Vorlesung dran - und Herr Schroeder-Preikschat
meint auch, dass er da nichts explizit ausgeschlossen hat.
Mein Standpunkt ist damit klar:
Capabilities sind ein sehr wichtiges Konzept
Letzlich sind z.B. ja auch die UNIX-Filedeskriptoren sowas wie Capabilities:
man bekommt vom Betriebssystem eine Zahl genannt, mit der man (= der Prozess)
dann im weiteren Verlauf wieder zum Betriebssystem gehen kann und die damit
verbundenen Ressourcen (=Datei) nutzen darf.
Prinzipiell kann man sich sogar vorstellen, dass man so einen Filedeskriptor
an einen anderen Prozess verschicken kann.
Berkeley-UNIX hat das auch realisiert: Da kann man Filedskriptoren ueber spezielle
lokale Socket-Verbindungen - socketpairs - verschicken. Beim empfangenden Prozess
wird ein entsprechender Eintrag in der Deskriptor-Tabelle im Prozesskontrollblock
gemacht und er empfaengt den Index in die Tabelle als offenen Filedeskriptor (wenn
ein Prozess z.B. seinen stdout = Filedeskriptor 1 losschickt, dann kann es durchaus
sein, dass der Empfaenger die Zahl 3 empfaengt, weil in seiner Deskriptor-Tabelle
der Eintrrag auf die geoeffnete Datei eben im Slot 3 eingetragen wird).
Wie gesagt, Capabilities sind ein sehr wichtiges Betriebssystemkonzept! Sowas koennte
durchaus in der Klausur gefragt werden.
Was es genau mit Hydra auf sich hat ist werde ich nicht fragen.
Also auch hier sieht’s so aus, dass das Thema Modulkonzept in der Vorlesung noch
komplett behandelt wurde.
Was den Pentium angeht: das Ringkonzept und die Callgates sind schon eine ganz
tolle Sache - ein Konzept, das letzlich auch schon in Multics so existierte.
Welches Bit wo in welchem Selektor steht muss man nciht wiss, wie sowas
grundsaetzlich funktioniert und was man damit machen kann aber evtl. schon.
also ich (als treuer Vorlesungsbesucher) erinnere mich, dass Herr S-P. meinte, er wisse eigentlich gar nicht, was Datenschutz und Zugriffssicherheit in einer System-Programmierungs-Vorlesung zu suchen hat. Das seien eher Themen für Vorlesungen über Netzwerk- und verteilte Systeme (OTR3-Vorlesung)
aber naja. dann wirds halt doch noch gelernt! :-/
Da hat er den Krypto-Teil gemeint.
Capabilities und Modulkonzept ist ureigenster BS-Stoff. Das hat nix
mit Netzwerk und verteilte Systeme zu tun.
Threads, Speicherverwaltung
Hi,
ich hab mehrere inhaltliche Fragen:
I. Aktivitätsträger (Threads):
Wie bauen genau Koroutinen, (User- / Kernel-Level-)Threads und Prozesse aufeinander auf. Mich interessiert nicht das, was auch schon in den Folien steht, sondern der Zusammenhang.
Zu meinem Begriffsverständnis:
Ich kann mich entsinnen, dass in der Vorlesung gesagt wurde, dass Prozesse durch Threads implementiert werden, bzw in einem Prozess und seinem Adressraum ein bis mehrer Threads ablaufen können (steht ja so ähnlich auch im Skript). Threads werden dann wohl durch Koroutinen (auf Benutzerebene) implementiert? Schwergewichtige Prozesse sind ja Prozesse, die einen eigenen Adressraum haben, in dem ein Thread läuft. Für mich waren leichtgewichtige Prozesse daraufhin immer das gleiche wie Threads. Allerdings sieht man ja in Folie D68, dass das auch nicht 100% stimmt. Liegt diese Ungereimtheit daran, dass die Begriffe unterschiedlich in den einzelnen Systemen genutzt werden und wenn nein, was ist die allgemein richtige Definition?
Btw: Wäre ein User-Level Thread, ein Thread, den ich z.B: selber in Java gestartet habe und ein Kernel Thread ein Thread, den allein das Betriebssystem verwaltet und der von mir als Programmierer nicht beeinflussbar wäre?
II. Speicherverwaltung:
Hierzu hab ich einige Fragen über den Zusammenhang zwischen den einzelnen Verfahren (Segmentierung, Seitenadressierung,…) und den Vor- bzw. Nachteile.
Tanenbaum unterscheidet in seinem Buch beim erweiterten Memory Management die zwei Oberkapitel Swapping und Virtual Memory.
Es gibt ja auch die Folien Swapping im Skript gefolgt von 2.4 Segmentierung und dem darauf folgenden Paging, was ja schon dem Virtual Memory dient. Ist Segmentierung nun eine Möglichkeit Swapping flexibel durchzuführen (um z.B das Problem der absoluten Adressen zu beheben) und ist somit ein Segment auch genau der Adressbereich eines Prozesses? Ist das nicht der Fall und ein Segment ist nur ein Teil des Adressraumes eines Prozesses, wo liegt denn dann noch der Unterschied zum Paging (außer in der unterschiedlichen Größe bei Segmenten im Vergleich zur immer gleichen Größe bei Seiten)?
Tanenbaum hat in einem Unterkapitel zu Swapping auch die Freispeicherverwaltung erklärt, die bei uns im Skript am Anfang des Kapitels erklärt wird (E7-E10). Braucht man somit beim Paging diese Art der Freispeicherverwaltung nicht? Hier könnte man ja über die Seitenkacheltabelle (oder Kachelseitentabelle) die freien Kacheln finden!
Vielen Dank!!
Kann mir jemand vielleicht kurz erklären um was es sich bei einem Arbeitsmengenmodell mit Zeitgeber oder WS-Clock handelt?Und ob allgemein das Thema überhaupt relevant ist für die Prüfung!?
Ja im wesentlichen schon - bis auf Preemption, die bekommt man nur mit
Koroutinen nicht so richtig erklaert.
Koroutinen sind ja voll kooperativ. Waehrend Prozeduren immer so funktionieren,
dass jemand die Proz. aufruft, die Prozedur return macht und der Aufrufer dann
nach dem Aufruf fortfaehrt, ruft Koroutine K1 irgendwann K2 auf, die arbeitet
ein stueck und ruft dann ihrerseits K1 auf, die arbeitet ein Stueck weiter, ruft wieder
K2 auf, usw.
Ein entscheidender Unterschiced zu Prozeduren ist die Arbeit mit dem Stack. Fuer einen
Prozeduraufruf erzeuge ich einen Stackframe auf dem die Prozedur arbeitet, beim return
kann ich den wieder freigeben. Bei Koroutinen hat jede K. einen eigenen Stack und
bei den Aufrufen dazwischen schalte ich zwischen den Stacks um (lade letztlich
einen anderen Zeiger in das Stackpointer-Register).
Damit haben wir eigentlich Threads die voll kooperativ arbeiten - jeder Thread muss
irgendwann entscheiden, welchen anderen Thread er jetzt weiterlaufen lassen will
und den aktivieren (= Koroutinen-Aufruf).
Preemption haben wir so natuerlich nicht - dazu brauchen wir irgendweclhen
asynchronen Signale (z.B. Timer-Interrupts oder Interrupts eines Geraets).
Das Eintreffen eines Signals kann man wie den unfreiwilligen Prozeduraufruf innerhalb
einer Koroutine sehen (wie bei UNIX-Signalen ja auch). Und in so einer Prozedur
koennte dann der Aufruf der anderen Koroutine passieren. Wenn die Prozedur jetzt
auch noch nach irgendwelchen Kriterien eine Entscheidung triff, welche andere
Koroutine sie aufruft, dann koennten wir sie auch Scheduler nennen.
Reine user-level-threads sind also Koroutinen und mit Signalen kann ich
dann sogar Preemption und ordentliches Scheduling dazu bauen.
Ja. Die LWPs unter Solaris z.B. sind quasi die user-level-Repraesentationen von
Kernel-Threads. Kernel-Threads sind Koroutinen innerhalb eines Prozesses - aber
der Betriebssystemkern kennt sie und kuemmert sich um die Umschaltung dazwischen.
Z.B. wenn einer einen blockierenden Systemaufruf macht, dann aktiviert marschiert
quasi diese Koroutine in den Kern und ruft dort sleep auf. Und in dieser sleep-Funktion
wird dann einfach eine andere Koroutine (=ein anderer Thread des gleichen Prozesses)
aufgerufen, die arbeitsfaehig ist und die laeuft dann aus dem Kern raus und macht was
im user-level. Die Umschaltungen zwischen den Koroutinen (kernel threads)
passieren aber immer im Kern (waehrend die Umschlatung bei user-level threads auf
user-level passiert).
nicht unbedingt, das kommt drauf an, was sich hinter dem Thread verbirgt.
Wenn’s ein user-level-thread package ist, dann ja, es kann aber
auch ein LWP erzeugt werden, dann hat man einen kernel-thread.
Es kommt also darauf an, was sich hinter der Java-API verbirgt.
meistens bietet einem das BS dann aber Schnittstellen um die Kernel-Threads zu
beeinflussen (schlafen legen, aufwecken, Prio einstellen, etc.)
nein, ein Segment ist ein Teil des Adressbereichs. In segmentierten UNIX-Systemen
hatte ein Prozess typischerweise immer drei Segmente: text, data und stack
Aber es ist richtig, dass man durch die Adressabbildung Segmente woanders
einlagern kann (oder auch einfach mal verschieben, wenn man Luecken
zusammenschieben will).
genau da liegt er
prinzipiell koennte man das, aber das waere natuerlich wahnsinnig aufwaendig, wenn man
immer durch alle SKTs durchsuchen muesste um eine freie Kachel zu finden.
In der Praxis hat man haeufig einen Freiseitenpuffer (E-73) - und nach einiger
Zeit sind ja die Kacheln alle entweder belegt oder da drin.
PS. bin jetzt bis Freitag nachmittag auf einer Tagung
Zur Speicherverwaltung:
Hab ich das richtig verstanden:
Segmentierung und Paging sind hauptsächlich dafür da um das Ein-/Auslagern zu vereinfachen.D.h dass nur die Übersetzungstabelle angepaßt werden muss!?
Und bei Prozessen muss nur die Segmentbasis/SKT ausgetauscht werden!?
Ansonsten sehe ich nicht viel Nutzen der beiden Methoden!? :#:
Aber wahrscheinlich habe ich wieder mal was wichtiges übersehen.
dadurch verhindert man ja auch externe fragmentierung, auch ein großer vorteil…
Ansonsten stimmts dann oder?
Ich würd sagen ja :red:
Wobei man auch beachten muss, dass auch bei Paging Fragmentierung entsteht. => Je kleiner die Seiten, desto kleiner die Fragmentierung
Also ich hab das so verstanden, dass für bequemes ein- und auslagern vor allem das Paging zuständig ist.
Man kann zwar auch ohne Paging arbeiten, und nur Segmente ein- und auslagern, was aber ineffizient ist, da ja niemals ein komplettes Segment gebraucht/nicht gebraucht wird. Außerdem ist das ein-/auslagern mit gleich großen Seiten/Kacheln natürlich sehr viel komfortabler.
Die Segmente sind wohl eher dafür zuständig, dass jeder Prozess seinen eigenen Adressraum (mit lokalen Adressen) besitzt, und für gemeinsamen Speicher natürlich.
absschließend zitier ich meister silberschatz …
“Consider how you think of a program when you are writing it. You think of it as a main program with a set of subroutines, procedures, functions, or variables.[…]Segmentation is a memory-management scheme that supports this user view of memory.”
“A particular advantage of segmentation is the association of protection with the segments.”
“Another advantage of segmentation involves the sharing of code or data.”
Ist das ein Vorteil, den man nur bei der Segmentierung hat, oder hat man diesen Vorteil nicht auch beim Paging? Laut Antwort von juk (ich interpretiere hier mal ein bisschen:) liegt der Unterschied zwischen Segmentierung und Seitenadressierung, (nur?) darin, dass ein Segment meist ein bestimmter Teil des Adressraums eines Programmes ist (Codeseg. ,…) und somit unterschiedlich groß sein kann und beim Paging hat man immer gleich große Seiten. Ergo ist Paging ja eigentlich ein „Spezialfall“ vom Segmentieren und so müsste eine Seite doch gleiche Möglichkeiten anbieten, wie ein Segment. Natürlich müsste das Implementieren von Sicherheit bei Segmenten einfacher sein, da ein Segment an sich ja schon Semantik mitbringt, es repräsentiert ja einen speziellen Bereich, was eine Seite nicht tut; oder sehe ich das falsch?
Zu Capability-basierten Systemen: Die Seiten, die allgemein C.-b. S. erklären sind ja im Skript recht rar. Die Seiten, die sich direkt auf Hydra beziehen, sind hingegen sehr zahlreich! @juk: Nur die allgemeinen Seiten zu lernen reicht für die Klausur wahrscheinlich nicht aus, das komplette Beispiel braucht nicht gelernt zu werden. Wie tief und was sollte zu diesem Bereich gelernt werden?
Ein ganz wesentlicher Vorteil ist die virtuelle Adressierung. Nur wenn jeder Prozess
einen eigenen Adressraum hat vermeidet man das Relokieren (d.h. das Anpassen aller
Pointer im Code) beim Laden eines Programms.
Was den Unterschied Segmentierung und Paging angeht: da hab’ ich mich neulich vielleicht
doch etwas zu lax geaeussert.
Der eigentlich Sinn von Segmentierung ist, innerhalb eines Prozesses quasi virtuelle
Teiladressraeume zu schaffen (mit unterschiedlicher Groesse, ggf. unterschiedlichen Zugriffs-
rechten), die bei Bedarf auch jeweils fuer sich verlaengerbar sind.
Damit erreicht man z.B. sofort eine Fehlermeldung der Hardware, wenn man ueber das
Ende eines solchen Speichers hinauslaeuft - waehrend bei Seitenadressierung es
erst kracht wenn man ueber das Ende der entsprechenden Seite rauslaeuft.
Adressiert wird immer mit (Segment-Nr, Offset im Segment).
Mit Seitenadressierung bekommt man dagegen einen linearen Adressraum
(z.B. von 0 bis 4GB), der allerdings Luecken haben kann.
Wenn man nun aber die Bits von Segment und Offset hintereinander zusammen betracht,
dann hat man in der Praxis auch wieder 32 bit Adressen und einen Adressraum mit
Loechern drin (wo halt grade kein Segment ist). Macht man dann noch alle Segmente
gleich gross hat man doch wieder so was aehnliches wie Seiten.
Der urspruengliche Sinn war aber ein anderer: Segmentierung sollte fuer die
Strukturierung von Anwendungen dienen - und damit auch auf Anwendungsebene
sichtbar sein. In der Praxis wird das heute aber soweit ich das ueberblicke nirgends
so eingesetzt. Auch bei der Pentium-MMU benutzt kaum ein BS die Segmentierungs-
Features.
Es wurde in der Vorl. wohl doch einiges mehr zum Thema Capabilities gesagt und
z.B. im Buch von Tanenbaum stehen auch 3 1/2 Seiten drin.
Die Hydra-Details sind halt ein Beispiel - aber nach denen frage ich sicher nicht.