3.2.11.5 Zusammenfassung Synchronisation
| [gesichtete Version] | [gesichtete Version] |
| Zeile 23: | Zeile 23: | ||
</p> | </p> | ||
<p> | <p> | ||
* Das größte Problem beim Einsatz von Semaphoren ist also der Mensch (<math>\rightarrow</math>der Programmierer). | * Das größte Problem beim Einsatz von Semaphoren ist also der Mensch (<math>\rightarrow</math> der Programmierer). | ||
</p> | </p> | ||
<p> | <p> | ||
| Zeile 29: | Zeile 29: | ||
</p> | </p> | ||
<p> | <p> | ||
* Dabei wird der Mensch (<math>\rightarrow</math>Programmierer) als Fehlerquelle bei der Synchronisation weitgehend ausgeschaltet. | * Dabei wird der Mensch (<math>\rightarrow</math> Programmierer) als Fehlerquelle bei der Synchronisation weitgehend ausgeschaltet. | ||
</p> | </p> | ||
Version vom 6. Februar 2015, 19:38 Uhr
Zusammenfassung Synchronisation
Das Kapitel zur Prozess-Synchronisation lässt sich ganz einfach zusammenfassen:
- Durch nebenläufige Ausführung von Prozessen (oder Threads) können Race Conditions entstehen.
- Mit Aktivem Warten können kritische Abschnitte geschützt werden.
- Um dabei das Problem des ungünstigsten Moments zu lösen, mussten die CPU-Hersteller den TSL-Befehl in den Prozessor integrieren.
- Der Nachteil des Aktiven Wartens ist die Verschwendung von CPU-Zeit.
- Diesen Nachteil besitzen Semaphore nicht, denn sie blockieren Prozesse, wodurch diese keine weitere CPU-Zeit mehr zugesprochen bekommen.
- Ein durch einen Semaphor blockierter Prozess muss durch einen anderen Prozess wieder entblockiert werden. Wenn der Programmierer des anderen Prozesses dieses vergisst, so gibt es ein Problem.
- Das größte Problem beim Einsatz von Semaphoren ist also der Mensch ( der Programmierer).
- Das Monitor-Konzept wurde als Verbesserung des Semaphor-Konzepts entwickelt.
- Dabei wird der Mensch ( Programmierer) als Fehlerquelle bei der Synchronisation weitgehend ausgeschaltet.
Diese Seite steht unter der Creative Commons Namensnennung 3.0 Unported Lizenz http://i.creativecommons.org/l/by/3.0/80x15.png