Bsys

- Abstraktion/Erweiterung des physischen Speichers durch eine Vortäuschung von grossen physischen Adressräumen

- Befasst sich mit der Abbildung von virtuellen Adressräumen auf physische Adressräume

- Jeder Prozess hat seinen privaten, grossen, virtuellen Adressraum -> Nicht mehr Eng und ist isoliert von anderen Prozessen

- Jeder virtuelle Adressraum (pro Prozess) VAp wird mittels eines individuellen Abbildung (vmp: VAp -> PA) auf den physchischen Adressraum (RAM) abgebildet

- MMU nimmt dabei die Abbildung vor -> Seitentabelle mit Seitennummer und Frame-Nummer

1) Aufteilung jedes virtuellen Adressraums in Seiten gleicher Grösse, typisch 4 oder 8 KByte (2^10 -> 1KB)

2) Aufteilung des physischen Adressraums in Rahmen gleicher Grössen

3) Seite eines virtuellen Prozessadressraums mit Seitenrahmen des physischen Adressraums assoziieren ("Fliesen legen") -> Seitenabbildungtabelle

Relative Adresse -> x-Stellen ab Referenz(Start)

- Pro virtuelle Seite gibt es einen Eintrag in der Seitentabelle

Seitenattribute:

- anwesend: Ob Seite im Arbeitsspeicher liegt (present-bit)

-benutzt: Ob auf die Seite zugegriffen wurde (used/referenced-bit)

-verändert: Ob die Seite "schmutzig" ist (dirty/modified-bit)

-schutz: erlaubte Zugriffsart je Privilligierungsebene (access control list)

-caching: Ob Inhalte der Seite ge"cached" werden darf

VMM is not free

-> Speicher: Seitentabellen können riesig werden!

-> Performanz: Je Speicherzugriff Zugriff auf die Seitentabelle!

- Viele Prozesse können gleichzeitig aktiv sein

- normalerweise passt der gesamte VA eines Prozesses nicht in den Arbeitsspeicher (Da gilt VA >> PA)

- Paging lagert einzelne Seiten auf ein Hintergrundspeicher aus.

- Es kann jederzeit ein Page Fault kommen, wenn auf eine ausgelagerte Seite zugegriffen werden möchte

RAM voll, was jetzt?

- Seitenaustauschalgorithmus -> FIFO, Second-Chance, Last-Recently-Used (LRU)

Swapping: Ganzer Prozess wird aus dem RAM entfernt -> Prozess wird suspended

Paging: Einzelne Seiten werden auf einen Hintergrundspeicher ausgelagert -> Prozess bleibt aktiv

- gleichzeitige Ausführung von Befehlen

- Mehrere Prozesse laufen gleichzeitig oder überlappend

Scheinbare Nebenläufigkeit: 

- präemptives Multitasking auf einem Prozessor (OS zwingt P zu unterbrechen)

- Unterbrechung durch Interrupts

- Die Prozesse tauschen so schnell (Context-Switch), dass man denkt, dass sie parallel laufen

Echte Nebenläufigkeit:

- Mehrkernprozessor

- Mehrprozessorsystem

- Computernetzwerk

Probleme:

- enstehen bei der Interaktion von nebenläufiger Ausführung von Threads oder Anwendungen, insbesondere beim Zugriff auf geteilte Ressourcen (Bei echter Nebenläufigkeit)

- Zwei oder mehrere Prozesse ändern eine geteilte Ressource (Kritischer Abschnitt)

- Ergebnis hängt vom zeitlichen Verhalten der Ausführung ab und wird dadurch nichtdetermentisch (Nicht vorhersehbar) und Inkonsistenz (Fehlerhaftes Ergebnis).

- Konzept zur Vermeidung von Race Conditions

- Teil des Codes, der den Zugriff auf geteilte Ressourcen koordiniert

- Anwendung des Prinzips des gegenseitigen Ausschlusses:

(MUTEX)-> Wenn ein Prozess einen kritischen Abschnitt durchläuft, können keine anderen oder nur bestimtme andere Prozesse diesen Abschnitt ebenfalls durchlaufen.

- Koordinierung von nebenläufigen Prozessen

- Verhinderung von Inkonsistenz beim Zugriff auf gemeinsam genutze Ressourcen

- Mutex oder Schedulingverfahren

- Kontrollmechanismen: -> Locks (sperren, nur ein Prozess darf in den Bereich), Semaphore (Zähler, der Zugriffe steuert (mehrere Prozesse möglich)

Locks -> einfache Sperre (0/1) oder (True/False)

Semaphore -> Zähler >1 erlaubt mehrere gleichzeitige Zugriffe

Synchronisation verhinder:

- Race Conditions

- Datenverluste

- Inkonsistenz

- Sperre, die den Zugriff auf eine Ressource (kritischer Abschnitt) regelt.

Vor Zugriff (Sperre anfordern) -> nach Zugriff (Sperre wieder aufheben)

Mehraufwand durch -> Locking-Mechanismen

Softwaredesign: richtige Grösse der kritischen Abschnitte finden

- Erlaubt nur einem einzigen Prozess den Zugriff auf eine Ressource

- Nur der Prozess, der die Mutex angefordert hat, kann sie auch wieder freigeben

- Lock mit einem Zähler (Anzahl der maximal gleichzeitigen Zugriffen)

- Vor Zugriff muss Lock reseriert werden (Zähler wird dekrementiert)

- Nach Zugriff muss Lock wieder freigegeben werden (Zähler wird inkrementiert)

- Jeder Prozess darf wieder freigeben, bei Mutex nur der Prozess, welcher gesperrt hat.

Prozess wird suspendiert, bis Semaphore wieder verfügbar ist ("sleeping lock")

Varianten:

- starke Semaphore (echte FIFO-Warteschlange)

- schwache Semaphore (z.B. priorität)

- binäre Semaphore (Zähler nur 0 und 1 / True oder False)

- zählende Semaphore (Zähler auch grösser als 1)

- Daten werden häufig von vielen Prozessen gelesen und nur von wenigen Prozessen geschrieben

- Spezielle Lock für diesen Anwendungsfall

- Zugang für mehrere Leser ist gestattet

- Zugang nur für einen Schreiber

- erhöht Nebenläufigkeit im System (Bessere Performanz)

Grobgranulares Locking (Grosses Lock für alles):

- Kann schnell zu einem Flaschenhals werden, bei dem viele Prozesse vor dem Zugriff auf eine geteilte Ressource warten müssen ("lock contention").

Feingranulares Locking (Viele kleine Locks):

- aufwendiger, aber laufen paralleler

- zyklische Wartesituation zwischen mehreren Prozessen

- Jeder Prozess wartet auf die Freigabe von Betriebsmitteln, die ein anderer beteiligter Prozess bereits exklusiv hat.

- Ein Prozess bekommt nie Ressourcen, obwohl der Prozess sonst eigentlich laufen könnte

Ursachen: 

- Deadlock oder ungeeignete Schedulingverfahren, bei dem grosse Prozesse z.B. verhungern

Starvation: Andere Prozesse laufen weiter

Verklemmung: Alles bleibt stehen, zirkuläre Wartesituation

cool