Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
koordinierungsmittel
hi,
im multiple-choice-teil wird oft nach den koordinierungsmitteln gefragt, im skript steht aber zu meiner meinung nach zu wenig, was die einzelnen begriffe angeht. hab ich folgendes richtig verstanden:
binaerer semaphor: nur 2 zustaende
pv-chunk-semaphor: mehrere zustaende, kann um mehrere einheiten auf einmal hoch- / runtergezaehlt werden
pv-multipler-semaphor: vektor aus einzelsemaphoren (sind diese pv-chunk-semaphoren?)
und wth sind up-down-systeme?
ich hab mir das durchgelesen und es nicht verstanden. dann hab ich im netz gesucht und finde nur das skript der uni erlangen :]. koennte mir jemand weiterhelfen?
Meiner Meinung nach is das so: (ich übernehme natürlich keine Garantie für Korrektheit…)
binaere Semaphoren haben tatsächlich nur 2 Zustände. Das unterscheidet sie von zählenden Semaphoren (PV-Systemen)
PV-Chunk-Semaphoren besitzen 2 Operationen p(S,k) und v(S,k) (ähnlich den PV-Systemen), nur dass du den Semaphorenwert der Semaphore S nicht nur um 1, sondern um einen beliebigen Wert k an- bzw. absenken kannst.
PV-Mulitipe-Semaphoren operieren auf einer zählenden Semaphore S und einer Menge M anderer zählender Semaphoren. S wird jeweils mit P um 1 erhöht bzw. mit V um 1 erniedrigt, wenn mindestens EINE Semaphore aus M einen Wert > 0 hat. Dabei ist S nicht in der Menge enthalten.
up/down Systeme bestehen aus 2 Operationen up and down, die jeweils auf einer Menge M von mehreren (meines Wissens) zählenden Semaphoren operieren. Wenn du auf M bsp-weise ein ‘up’ machst, werden ALLE Semaphoren aus M um 1 erhöht. (‘down’ analog).
Ich bin grade an der Stelle im Skript…
Wozu sollen denn zählende Semaphoren gut sein? Hat da jemand plausible Beispiele für?
erzeuger-verbraucher?
glaub ich nicht. schau mal auf D-116. die philisosophen. P muss blockieren, wenn eine der semaphoren 0 hat.
ich glaube eine pv-multiple erlaubt einfach gleichzeitige P oder V operationen in mehreren semaphoren, wobei der P aufruf blockiert, wenn mindestens eine = 0 ist.
glaube ich auch nicht. eine up/down semaphore operiert auf einer einzigen semaphore, nur die nichtblockierbedingungen hängen von mehreren ab.
war da nicht immer nur ein verbraucher zugelassen? ich kann mir das mit den beispielen im skript auch nicht so recht vorstellen…
P: if (S > 0) S–;
Hier kann also nur auf Null gesetzt werden.
V: S++;
Da das Sperren nur auf Null setzen kann, kann hier nur auf eins gesetzt werden (weshalb man bei P auch nur auf Null kommt…).
Wo ist also der Nutzen, irgendwas zählen zu können? Oder dürfen da mehrere Anwendungen in den kritischen Bereich rein? Eigentlich nicht…
Die Semaphore haben gezählt wieviel Platz im Speicher belegt bzw frei war.
Das hat dann aber nix mit der eigentlichen Sperrfunktion zu tun, sondern ist ein benutzerdefiniertes Datenfeld, das da eben gleich mitgespeichert wird, richtig?
Ähm… ja?! 
Irgendwie hat es schon mit der Sperrfunktion zu tun, die Semaphoren sperren ja wenn leer bzw. voll ist. Und dafür sind die zählenden Semaphoren doch praktisch, mit binären Semaphoren wäre das etwas umständlicher…
Du willst ja nicht nur den exklusiven Zugriff damit bewerkstelligen, sondern auch den Verbraucherprozess solange blockieren, bis er wieder verbrauchen kann. (Erzeuger analog)
Öhm… vllt sollt ich doch erst nochmal die Aufgabe anschauen… das war die eine, die ich net gemacht hab. 
ach ja? schau mal auf D110. Die Bedinung lautet eindeutig ΣS[sub]i[/sub] ≥ 0 (ist erfüllt wenn mindestens eine Semaphore ≠ 0 ist) und nicht ∀i: S[sub]i[/sub] ≥ 0 wie Du meinst.
Sorry!
ach ja? schau mal auf D115. Die Anweisungen lauten hier eindeutig ∀i: S[sub]i[/sub] := S[sub]i[/sub]+1 für ‚up‘ und ∀i: S[sub]i[/sub] := S[sub]i[/sub]-1 für ‚down‘. Ausserdem ist klar ersichtlich, dass die beiden Operationen auf einer Menge von Semaphren S[sub]i[/sub] definiert sind.
Auch hier sorry!
kanns sein, dass du die beiden seitenabgaben genau verwechselt hast? wenn ich in meinem skript nachschlage, dann steht genau das drin, was ich geschrieben habe.
nur zur sicherheit: bedingung=NICHTblockierungsbedingung
mein fazit: hoffentlich kommt das zeug nicht dran…
richtig
auch richtig.
Aber vergesst die up/down’s (sorry, haette ich laengst sagen sollen) - ich hab’ in meiner
ganzen Karriere noch kein Beispiel finden koennen wofuer man sie in ihrer
ganzen Schoenheit brauchen kann (ausser 2. Leser/Schreiber-Prob. das man aber
auch mit den 0-Tests der UNIX-Sem. hinbekommt. Diese 0-Tests sind weniger maechtig
als up/down aber fuer 2. Leser/Schreiber reichts. Dabei geht’s nur darum, dass beliebig
viele einen kritischen Abschnitt betreten koennen sollen und einer will drauf
warten, dass alle wieder draussen sind. Das bekommt man sonst mit keinem
anderen P/V-irgendwas-System hin weil immer von einem festen Wert nach unten gezaehlt
wird und man damit nicht beliebig viele in den kritischen Abschnitt reinlassen kann.)
ganz abstrakt: man hat mehrere Exemplare eines Betriebsmittels (z.B. drei nebeneinander
stehende Drucker). Jeder der eins belegt zaehlt 1 runter. Wenn alle belegt sind blockiert
der naechste bis einer wieder eins freigibt.
Erzeuger-Verbraucher kann man natuerlich auch damit machen.
Eigentlich (in der schoenen Theorie) gibt’s dafuer PV-two-way-bounded: die blockieren
auch bei der V-Operation wenn sie bei irgendeinem bestimmten Wert oben anstossen.
Damit kann man dann den bounded-buffer mit einer solchen Sem. koordinieren.
In der Praxis macht man’s aber einfach mit 2 zaehlenden Semaphoren wie in der
Programmieraufgabe.
Natuerlich kann man sowas immer auch mit einem mutex und normalen Variblen zum
zaehlen machen. Die Idee hinter all diesen famosen PV-Systemen ist eigentlich nur,
all die verschiedenen Koordinierungsprobleme auf ein paar grundsaetzliche
Koordinierungsverfahren zusammenzufassen. Ob die jetzt in ihrer vollen
Komplexitaet vom BS angeboten werden oder ob sie der Anwender in
mit einfachen mutex-locks gesicherten Abschnitten selbst programmiert, ist letztlich
dann ja egal.
Argh. :motz:
Du hast natürlich recht.
Kann ich bestätigen… das Zeug bringt man krass durcheinander…