by x3Lynx3 » Mon Jan 07, 2019 9:14 am
Prozess Synchronization
WHY
Mehrere Prozesse müssen gleichzeitig laufen können. (Musst ggf. auf externe Events angepasst werden)
Synchronisation ist notwendig, für den vernünftigen Austausch von Ressourcen zwischen Prozessen
z.B. Kleine Teile eines größeren Problems auf Prozesse aufteilen, zwischenzeitliche Ergebnisse mit einander teilen (Optimierung), Endergebnisse in ein einzelnes gemeinsames File schreiben
Ohne Synchronisation könnten Ressourcen korrumpiert werden / Ergebnisse könnten sich von der Ausführungsreihenfolge abhängig verändern.
TERMS
Race Condition (RC): Situation in der das Verhalten/Ergebnis von Reihenfolge, Timing und/oder unkontrollierbaren Events abhängig ist. Unerwartete RCs sind meist problematisch.
Critical Section (CS): („Gleichzeitiger“) Zugriff mehrerer Prozesse auf eine gemeinsame Ressource, die eigentlich nur einzeln verarbeitet werden sollte.
Mutual Exclusion (Mutex): Die Anforderung selbst, oder Implementationen die die Anforderung beinhalten, dass keine 2 Prozesse gleichzeitig die gleiche Ressource benutzen (bzw. Instruktionen ausführen) dürfen, während einer CS.
needs: # Software Algorithmen (Dekker’s, Peterson’s, Bakery)
# Hardware Support (Keine Interrupts (on single-core), Zielstrebige Anweisungen)
# OS-Infrastruktur (IPC mit implizierter Synchronisation, spezielle Synchronisations-Konstrukte)
Semaphor
Nicht negativer Integer, entspricht „ready/busy“ und soll mehrfache Zugriffe in CS verhindern.
Proberen (can I has access?) und Verhogen (int+1 ( proberen a blocked/waiting process int-1))
Deadlock = Eingefahrene Situation – Unter den normalen Bedingungen ist kein Fortschreiten möglich
z.B. (4 Autos an Kreuzung, rechts hat Vorrang, keine Absprache) | 2 processes block each other (CS)
HOW: Kann passieren wenn Mutex gegeben ist, Prozesse Ressourcen halten dürfen und diese Ihnen auch nicht erzwungen wieder entzogen werden können. Außerdem: circular wait = Verkettung (mind. 2) so dass jeder Prozess eine Ressource hält, die der andere benötigt.
DEAL WITH IT:
Prevention: Verhindert dass alle Bedingungen eintreten können, die für einen Deadlock notwendig sind
z.B. # Allokiert alle notwendigen Ressourcen bei Prozessstart (statt hold and wait)
# Wenn ein Prozess eine Ressource nicht kriegt, muss er alle die er schon hat hergeben
# Lineare Anordnung von Ressourcen definieren und diese bei der Allokation einhalten
Avoidance: Bearbeitet Allokationsanfragen dynamisch basierend auf derzeitiger und maximaler zukünftiger Anfragen des jeweiligen Prozesses (Banker’s Algorithm)
Detection: Erkennt Deadlocks und leitet dann externe Lösungsmethoden ein
Livelock: Alle Prozesse ändern stetig ihren Zustand, in Antwort zueinander, ohne irgendetwas sinnvoll weiterzubringen. Kann beim Versuch einen Deadlock aufzuhalten entstehen.
Starvation: Wird der Zugriff auf eine Ressource von einem unfairen Algorithmus geschützt, kann es dazu kommen dass einzelne Prozesse diese nie bekommen / bzw. nie ihre CS erreichen.
Conditional Synchronisation: CS1 muss vor CS2 stattgefunden haben
Producer-Consumer: P generiert Materialien, für C zum konsumieren. Ring-Buffer mit 2 Pointern (in/out = Indexe der jew. Arrays) auf die Elemente, “geschützt” durch Semaphore (1/0)
Problem bei Synchronisationskonstrukten: Operationen sind auf alle teilnehmenden Prozesse verteilt und müssen von allen korrekt genutzt werden. (1 mistake -> all mistake), Alternative:
Monitore = Sotware Module aus privaten (shared) Ressourcen (var,proz) und Prozeduren, die Mutex garantieren, sowie mindestens einer Warteschlange.
Ebenfalls möglich: condition variables (signal events, used with wait and signal procedures).
# wait(X) blockt solange X nicht signalisiert wird
# signal(X) weckt alle Prozesse die auf X warten. Sonst passiert nichts (kein Status)
Großer Vorteil: Alle Synchronisationsfunktionen sind in einem Modul vereint.
I keep quitting and coming back. Slowly building up my collection again!

Hunter x Hunter | She-Ra: Princesses of Power | Avatar & Korra | Sherlock