From: gm@germal.escape.de (Gerald Malitz)
Newsgroups: de.comp.sys.amiga.misc
Subject: Re: Haeh? Was ist dass denn?
Date: Tue, 05 Jan 1993 13:30:33 GMT
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0

In article <Ofwes*Lr0@forge.franken.de>, Henning Schmiedehausen writes:

> Procure()
> Vacate()
>
> Was ist das?  Laut Autodocs sind das auch so eine Art Semaphores,

Die Autodocs ab 1.3 (1.2 hab' ich nicht nachgesehen, in den "White-
Books" stehen Procure und Vacate nur in der Liste der Exec-Vektoren)
unter Procure:

|       Straight "Semaphores" use the message system.  They are therefore
|       queueable, and users may wait on several of them at the same time.
|       This makes them more powerful than "Signal Semaphores"

	Das sagt doch schon einiges.  Damit ist "asynchroner" (wie as. IO)
Zugriff auf Semaphore moeglich.  D. h. mein Task kann was anderes machen
bis er Zugriff bekommt.  Das geht mit den SignalSemaphores auch, aber
laengst nicht so gut.  Mit AttemptSemaphore() kann ich testen, aber ich
muss das selber aktiv machen, d. h. ich muss immer wieder anfragen.  Bei
den MessageSemaphores werde ich benachrichtigt.

	Und Message-Semaphore sind fair.  Das meint, dass ich eine Garantie
dafuer habe, den Zugriff irgendwann zu bekommen - wenn nicht jemand das Ding
fuer ewig behaelt -, weil die Anfragen nach dem FIFO-Prinzip abgearbeitet
werden.  Wenn ich mit AttemptSemaphore() nach einem Signal-Semaphor frage,
ihn aber nicht bekomme, ist meine Anfrage weg.  Ich muss mich beim naechsten
Versuch wieder hinten anstellen.  Gibt es neben meinem noch Tasks, die mit
ObtainSemaphore() arbeiten, habe ich mit AttemptSemaphore() unter Umstaenden
keine Chance, denn es ist immer besetzt und immer jemand vor mir in der
Warteschlange.

	So ein Message-Semaphor waere z. B. ideal, um den Zugriff auf
das serial.device zu regeln.  Ein Terminal-Programm ruft Procure auf.
Wenn das serial.device besetzt ist - also Procure FALSE liefert -,
wird ein Requester aufgemacht, der dem Benutzer sagt, dass das
serial.device besetzt ist und nur ein Abort-Gadget (also kein Retry/Cancel)
enthaelt.  Das Terminal-Programm wartet dann darauf, dass entweder die
Message vom Semaphor kommt, die den Zugriff gewaehrt, oder der Requester
beantwortet wird.  Leider ist nirgends eine Methode beschrieben, einen
Request wieder abzubrechen.  Evtl. ist das aber schon mit Forbid()-
Remove()-Permit() erledigt.

	Natuerlich haben die Message-Semaphore auch Nachteile.  Sie sind
fuer Resourcen, die nur so lange wie unbeding noetig geschuetzt werden
sollen, schlecht geeignet.  Moeglicherweise ist das Programm, das nach
dem Semaphor gefragt hat, zwischendurch mit ganz anderen Dingen
beschaeftigt, so dass es auf die Zuteilung nicht sofort reagieren kann
oder will.

	Und wieder die Autodocs:

|       Signal Semaphores are different than Procure()/Vacate() semaphores.
|       The former requires less CPU time, especially if the semaphore is
|       not currently locked.

	Also fuer OS-Zwecke nicht so gut geeignet.  Und schliesslich:

|  BUGS
|       Procure() and Vacate() do not have proven reliability.

	Tja...

> IMHO  scheint  das  so eine Art 'advisory lock' zu sein, whrend die
> anderen Semaphore Funktionen 'exclusive lock's sind.

	Beide regeln nur exklusiven Zugriff.  Fuer andere Probleme -
etwa einer darf schreiben, viele lesen - brauchst Du andere Strukturen,
die aber auf den vorhandenen Semaphoren aufbauen koennen.

> Also: Hat jemals jemand irgendwas mit diesen Funktionen gemacht?

	Noe :-)

> Sind die nur noch aus Vollstndigkeit dabei? Oder wie oder was?

	Semaphore zu haben, ist immer gut :-)  Nur dass sich scheint's
der erste Versuch als fuer das OS selbst ungeeignet erwiesen hat.

> 	Alloooooooha!
> 		Henning

	Ich hoffe, das trifft Deine Frage, Gerald.

-- 
  // Gerald Malitz,  Bolchentwete 4,  3300 Braunschweig,  Voice: +49 531 796832
\X/ gm@germal.escape.de                                 Quo vadis, Deutschland?