Informatik 4 (StuPO90)/Semaphoren - Versionsgeschichte

Martin Häcker: /* 4. "Priority" */ begrenzte kritische sektion -> begrenzte sektion

2007-05-22T16:39:03Z

‎4. "Priority": begrenzte kritische sektion -> begrenzte sektion

Martin Häcker: /* Eine "Pattern Language" für die Benutzung von Semaphoren */ link info 4 + formulierung

2007-05-22T16:14:46Z

‎Eine "Pattern Language" für die Benutzung von Semaphoren: link info 4 + formulierung

Martin Häcker: ss -> ß

2007-05-22T16:12:55Z

ss -> ß

Buchholz: Informatik 4/Semaphoren wurde nach Informatik 4 (StuPO90)/Semaphoren verschoben

2006-08-18T10:21:50Z

Informatik 4/Semaphoren wurde nach Informatik 4 (StuPO90)/Semaphoren verschoben

217.184.13.244: /* 4. "Priority" */

2006-05-28T09:55:29Z

‎4. "Priority"

Mutax: Martin hat einen zu breiten Monitor;) - Zeilenumbruch

2006-05-23T09:52:37Z

Martin hat einen zu breiten Monitor;) - Zeilenumbruch

192.168.23.194: /* 4. "Priority" */

2006-05-22T10:35:53Z

‎4. "Priority"

Martin Häcker: /* 4. "Priority" */ grammatik

2006-05-22T10:34:30Z

‎4. "Priority": grammatik

Martin Häcker: /* 6. "Einseitige Synchronisation" (Erzeuger- / Verbraucher-Probleme) */ auskommentiert bis verbessert

2006-05-22T10:33:16Z

‎6. "Einseitige Synchronisation" (Erzeuger- / Verbraucher-Probleme): auskommentiert bis verbessert

Martin Häcker: /* 4. "Priority" */ hinweis auf reihenfolge bei den mutex semaphoren

2006-05-22T10:32:01Z

‎4. "Priority": hinweis auf reihenfolge bei den mutex semaphoren

@@ Zeile 160: / Zeile 160: @@
 </nowiki>
-Will man "Priority" mit "Restricted Section" kombinieren, ist zu beachten, dass die begrenzte kritische Sektion der Gruppe, die überholt werden soll, natürlich den gesamten Code mit einschließt, der die Priorität sichert. Tut man das nicht, kann das Überholen nicht garantiert werden.
+Will man "Priority" mit "Restricted Section" kombinieren, ist zu beachten, dass die begrenzte Sektion der Gruppe, die überholt werden soll, natürlich den gesamten Code mit einschließt, der die Priorität sichert. Tut man das nicht, kann das Überholen nicht garantiert werden.
 Auf der anderen Seite, bei den Prozessen, die überholen sollen, muss die begrenzte kritische Sektion innerhalb des Codes liegen, der die Priorität garantiert, da andernfalls in dem Spezialfall, in dem die Restriktion auf eins liegt, das Überholen nicht funktioniert. (Vorsicht: Natürlich muss bei "Restricted Section" jede Prozessgruppe eine eigene Semaphore für die Beschränkung haben.)

@@ Zeile 13: / Zeile 13: @@
 * Einseitige Synchronisation
-Zu diesem Zweck werden hier in der Vorlesung Semaphoren eingesetzt, die eine P() (Passieren) und eine V() (Vreigeben) Operation haben. Außerdem können Semaphoren mit einem Wert initialisiert werden, der vorgibt, wie oft P() aufgerufen werden kann, bevor der Aufrufer blockiert wird. Für genauere Erklärungen siehe das Informatik 4 Skript.
+Zu diesem Zweck werden hier in der Vorlesung Semaphoren eingesetzt, die eine P() (Passieren) und eine V() (Vreigeben) Operation haben. Außerdem können Semaphoren mit einem Wert initialisiert werden, der vorgibt, wie oft P() aufgerufen werden kann, bevor weitere Aufrufer blockiert werden. Für genauere Erklärungen siehe das [[Informatik 4]] Skript.
 == 1. "Critical Section" ==

@@ Zeile 94: / Zeile 94: @@
 	innerer Kritischer Abschnitt
-äusserer kritischer Abschnitt
+äußerer kritischer Abschnitt
 </nowiki>
-Die Semaphore, die den inneren kritischen Abschnitt schützt, kann jetzt von einem anderen Prozess aus einer anderen Prozessgruppe gesperrt werden. Das funktioniert, da die anderen Prozesse ja gerade '''nicht''' auch an der äusseren Semaphore warten müssen. Damit muss der priorisierte Prozess maximal so lange warten, bis der Prozess, der die innere Semaphore gerade besitzt, sie wieder freigibt. Da nur maximal ein Prozess aus der niederprioren Gruppe an der Semaphore "hängen" kann, werden alle Prozesse überholt, die an der äußeren Semaphore warten.
+Die Semaphore, die den inneren kritischen Abschnitt schützt, kann jetzt von einem anderen Prozess aus einer anderen Prozessgruppe gesperrt werden. Das funktioniert, da die anderen Prozesse ja gerade '''nicht''' auch an der Äußeren Semaphore warten müssen. Damit muss der priorisierte Prozess maximal so lange warten, bis der Prozess, der die innere Semaphore gerade besitzt, sie wieder freigibt. Da nur maximal ein Prozess aus der niederprioren Gruppe an der Semaphore "hängen" kann, werden alle Prozesse überholt, die an der äußeren Semaphore warten.
 Etwas formaler:
@@ Zeile 162: / Zeile 162: @@
 Will man "Priority" mit "Restricted Section" kombinieren, ist zu beachten, dass die begrenzte kritische Sektion der Gruppe, die überholt werden soll, natürlich den gesamten Code mit einschließt, der die Priorität sichert. Tut man das nicht, kann das Überholen nicht garantiert werden.
-Auf der anderen Seite, bei den Prozessen, die überholen sollen, muss die begrenzte kritische Sektion innerhalb des Codes liegen, der die Priorität garantiert, da andernfalls in dem Spezialfall, in dem die Restriction auf eins liegt, das Überholen nicht funktioniert. (Vorsicht: Natürlich muss bei "Restricted Section" jede Prozessgruppe eine eigene Semaphore für die Beschränkung haben.)
+Auf der anderen Seite, bei den Prozessen, die überholen sollen, muss die begrenzte kritische Sektion innerhalb des Codes liegen, der die Priorität garantiert, da andernfalls in dem Spezialfall, in dem die Restriktion auf eins liegt, das Überholen nicht funktioniert. (Vorsicht: Natürlich muss bei "Restricted Section" jede Prozessgruppe eine eigene Semaphore für die Beschränkung haben.)
 Der dritte wichtige Punkt ist das Holen und Freigeben der ''innerCriticalSection'' im niederprioren Prozess. Das holen muss '''vor''' dem ''mutex'' und das Freigeben '''nach''' dem ''mutex'' passieren, da das System sonst ein Deadlock produzieren kann.

@@ Zeile 91: / Zeile 91: @@
 	innerer kritischer Abschnitt <- an dieser Semaphore ist also immer nur maximal ein Prozess gleichzeitig
-		... kritischer Bereich ...
 	innerer Kritischer Abschnitt

@@ Zeile 116: / Zeile 116: @@
 Die niederprioren Prozesse:
   <nowiki>
-outerCriticalSection = Semaphore(1), innerCriticalSection = Semaphore(1), lowPriorityCounterProtection = Semaphore(1), mutex = Semaphore(1)
+outerCriticalSection = Semaphore(1), innerCriticalSection = Semaphore(1),
 outerCriticalSection.P()

← Nächstältere Version	Version vom 18. August 2006, 10:21 Uhr
(kein Unterschied)

@@ Zeile 163: / Zeile 163: @@
 Auf der anderen Seite, bei den Prozessen, die überholen sollen, muss die begrenzte kritische Sektion innerhalb des Codes liegen, der die Priorität garantiert, da andernfalls in dem Spezialfall, in dem die Restriction auf eins liegt, das Überholen nicht funktioniert. (Vorsicht: Natürlich muss bei "Restricted Section" jede Prozessgruppe eine eigene Semaphore für die Beschränkung haben.)
-Der dritte wichtige Punkt, ist dass holen und freigeben der ''innerCriticalSection'' im niederprioren Prozess. Das holen muss '''vor''' dem ''mutex'' und das Freigeben '''nach''' dem ''mutex'' passieren, da das System sonst ein Deadlock produzieren kann.
+Der dritte wichtige Punkt ist das Holen und Freigeben der ''innerCriticalSection'' im niederprioren Prozess. Das holen muss '''vor''' dem ''mutex'' und das Freigeben '''nach''' dem ''mutex'' passieren, da das System sonst ein Deadlock produzieren kann.
 == 5. "Reduction" ==

@@ Zeile 167: / Zeile 167: @@
 == 5. "Reduction" ==
 Die Lösungen, die man aus der Kombination dieser Muster erhält, verwenden in Spezialfällen mehr Semaphoren als unbedingt nötig. Man kann daher manchmal einige der Semaphoren weglassen, da ihre Funktion schon von einer der anderen Semaphoren erfüllt werden.
 == 6. "Einseitige Synchronisation" (Erzeuger- / Verbraucher-Probleme) ==
@@ Zeile 196: / Zeile 198: @@
 Soll nur einmal ein Signal übermittelt werden, beispielsweise dass alle notwendigen Vorraussetzungen für eine einmalige Aktion jetzt erfüllt sind, dann genügt natürlich auch eine Semaphore.
 [[Informatik 4|<- Zurück zur Informatik 4 Seite]]

← Nächstältere Version		Version vom 22. Mai 2006, 10:32 Uhr
Zeile 162:		Zeile 162:

	Auf der anderen Seite, bei den Prozessen, die überholen sollen, muss die begrenzte kritische Sektion innerhalb des Codes liegen, der die Priorität garantiert, da andernfalls in dem Spezialfall, in dem die Restriction auf eins liegt, das Überholen nicht funktioniert. (Vorsicht: Natürlich muss bei "Restricted Section" jede Prozessgruppe eine eigene Semaphore für die Beschränkung haben.)		Auf der anderen Seite, bei den Prozessen, die überholen sollen, muss die begrenzte kritische Sektion innerhalb des Codes liegen, der die Priorität garantiert, da andernfalls in dem Spezialfall, in dem die Restriction auf eins liegt, das Überholen nicht funktioniert. (Vorsicht: Natürlich muss bei "Restricted Section" jede Prozessgruppe eine eigene Semaphore für die Beschränkung haben.)
		+
		+	Der dritte wichtige Punkt ist dass holen und freigeben der ''innerCriticalSection'' im niederprioren Prozess beim holen '''vor''' dem ''mutex'' und beim Freigeben '''nach''' dem ''mutex'' passiert, da das System sonst Deadlocken kann.

	== 5. "Reduction" ==		== 5. "Reduction" ==