und mein liebe leut willkommen zum nächsten video zur vollesungsreihe betriebssysteme

worum soll es diesmal gehen diesmal geht es um fadensynchronisation

fadensynchronisation heißt ein faden möchte dem anderen was mitteilen ein faden möchte auf den

anderen warten irgendwas in der richtung heißt wir wollen zwischen fäden irgendwie kommunikation

stattfinden lassen mindestens mal die einfachste kommunikation im sinn davon ich warte auf das

was ein anderer getan hat gut und das wenn ich jetzt schon sage warten dann ist klar das betrifft

auch irgendwie für prozessverwaltung unsere liste der lauffähigen fäden die ändert sich ja

dann irgendwie da ist dann ja möglicherweise wenn einer wartet ein faden nicht mehr lauffähig

jo was gucken wir uns dazu an erstmal ein kleines einleitendes beispiel wo steckt überhaupt das

problem dann gucken wir uns das prioritätsmodell noch mal an erinnert euch nach synchronisierung

von interapp mit der normalen anwendung das muss man jetzt aufbohren das modell das wird auch

mehrere fäden mit unterkriegen gut und dann brauchen natürlich irgendwelche mechanismen

wie schaffen wir das jetzt fäden untereinander zu koordinieren zu synchronisieren und das gucken

wir uns dann am beispiel windows im nächsten schritt noch mal an ja erstes kleines einführendes

beispiel ihr erinnert euch an einen baunen den buffer den hatten wir schon mal und da hatten wir

eine konsum funktionen eine produce funktionen und jetzt haben wir einfach zwei fäden ganz typisches

beispiel ein faden der berechnet irgendwas packt das in einen buffer rein und ein anderer faden

der nimmt aus dem buffer immer irgendwas raus und verarbeitet es weiter ganz einfache idee

jetzt ruft dann möglicherweise einer auf er möchte irgendwie ein zeichen aus dem buffer

rausholen und während er jetzt gerade dabei ist ja da kann natürlich jetzt jederzeit zum

timeartik kommen zeitscheibe ist abgelaufen scheduler wird aufgerufen scheduler guckt

sich einen neuen faden aus ruft das resume für den neuen faden auf und der neue faden läuft

und das kann wieder teufel das will natürlich eine methode sein die jetzt kollidiert mit einer

gerade laufenden methode hier im beispiel das produce wird jetzt gestartet heißt das produce

unterbricht ein laufendes konsum das hatten wir schon mal ihr erinnert euch wie war das damals

ja damals war es das hauptprogramm was aus zum beispiel dem tastaturpuffer was rausholen

wollte und während es gerade beim rausholen war kam gerade einen tastendruck ein interrupt und im

interrupt händler hatten wir dann die produce methode aufgerufen die in den buffer eben ein

neuen tastendruck einsortiert ja und damit war damals der zustand von diesem buffer kaputt

ja wie haben wir es damals gelöst damals haben wir es gelöst mit harter synchronisation mit

weicher synchronisation beziehungsweise mit dem prolog epilogue modell die frage ist was ist jetzt

anders können wir da nicht irgendeine methode von damals recyceln ja wir werden sehen da ist was

grundlegend anders was ist da anders ja bisher war es einfach so dass wir gesagt haben interrupts

und hauptprogramm kommen aus verschiedenen ebenden einer kommt von oben einer kommt von unten dann

haben wir gesagt naja dann platzieren wir den zustand auf einer ebene irgendwo dazwischen und

sichern den zugriff entweder von oben mit harter synchronisation jenert euch glies die beziehungsweise

kann man das auch von unten synchronisieren im sinne von weiche zugriffe innerhalb einer

ebene haben wir einmal gesagt wird implizit alles sequentialisiert also interrupt laufen so inter

abt händler laufen so lange bis sie fertig sind in der epilogue ebene arbeiten wir so lange bis

wir fertig sind also bei dieser ranto condition semantik jetzt haben wir das problem jetzt haben

wir nicht zugriffe aus verschiedenen ebenden sondern jetzt sind es beispielsweise zwei

anwendungsfäden sie kommt beide aus der gleichen ebene kann ja jetzt jederzeit passieren wenn wir

jetzt mehrere fäden haben und ein time atti kommt ja dann wird ein faden verdrängt und ein anderer

kommt dran das kann entweder durch dieses ganz normale scheduling passieren das mal der eine mal

der andere dran ist im fall von mehreren cpu haben wir natürlich das problem generell da brauchen

wir nicht mal ein timer interrupt kein scheduling kein nix da laufen dann ja wirklich mehrere cpus

in einer ebene ja und das ist auch der witz der ganzen sache wir wollen ja mehrere fäden damit

wir mehrere cpus einsetzen können damit wir performance reinkriegen und das ist eben alle

wollen jetzt auch nicht wirklich cpus abschalten oder irgendeine ranto condition semantik einführen

weil dann ist der sinn von fäden weg also es muss jetzt irgendwie möglich sein dass mehrere fäden