Diskussion:Semaphor (Informatik)

Zum Archiv

Wie wird ein Archiv angelegt?

Automatische Archivierung

Auf dieser Seite werden Abschnitte halbmonatlich automatisch archiviert, wenn sie mit {{Erledigt|1=--~~~~}} markiert sind. Um die Diskussionsseite nicht komplett zu leeren, verbleibt mindestens ein Abschnitt.

Stellungnahmen zwecks Verbesserung

Ich habe alle Einzelpunkte mit meinem Namen signiert, damit direkt hinter jedem auch eine andere Meinung gesetzt werden kann. Ziel der Stellungsnahmen ist eine Verbesserung des Artikels.--HartmutS 19:09, 29. Apr 2006 (CEST)

• Semaphor == Signalmast der Eisenbahn passt genau in die Anwendung der Semaphor in der Informatik. --HartmutS 19:09, 29. Apr 2006 (CEST)

Was willst du damit sagen bzw. anregen? --MartinThoma (Diskussion) 13:43, 13. Mär. 2012 (CET)

• Bei Semaphor geht es nicht um Interprozesskommunikation, auch nicht um Prozesssynchronisation, sondern um eine Regelung des Zugriffs zu Daten, Interprozesskommunikation wird mit diesen Daten ausgeführt (nicht mit dem Semaphor) und Prozesssynchronisation wird nur beeinflusst, wenn ein anderer Prozess gleichzeitig zugreifen wollte. Ansonsten wird mit einem Semaphor kein anderer Prozess beeinflusst. Aber mit den Daten, die mit einem Semaphor geschützt sind, ist eine Prozesssysnchronisation erreichbar (beispiel indem ein anderer Prozess auf bestimmte Daten wartet und dann losläuft). Ich lese sehr oft (auch in anderen Artikeln) diese Feinunterschiede nicht heraus, siehe auch Mutex.--HartmutS 19:09, 29. Apr 2006 (CEST)

Ist das deiner Meinung nach inzwichen besser geworden? --MartinThoma (Diskussion) 13:43, 13. Mär. 2012 (CET)

• Der Begriff Thread kommt hier sehr selten vor, statt dessen sehr oft Prozess_(Informatik). Statt Prozess sollte aber mindestens gleichberechtigt Thread stehen, denn wenn eine Semaphor-Struktur direkt angesprochen wird, dann steht sie im selben Speicherraum, das geht nur mit Threads. Prozesse können mit einem Sempahor nur dann arbeiten, wenn der Semaphor-Zugriff auf der Systemebene geregelt ist.--HartmutS 19:09, 29. Apr 2006 (CEST)
• Semaphor im Zusammenhang mit Mutex ist meist ein binäres Semaphor, ggf. mit anhängender Warteschlange. Das ist eine der Hauptanwendungen. Die Dijkstras Lösung ist eine andere Aufgabe, die sich auf begrenzte Ressourcen bezieht. Das ist im Artikel nicht sehr gut auseinandergehalten ==> Gliederung.--HartmutS 19:09, 29. Apr 2006 (CEST)
• Der Abschnitt Implementierung bezieht sich wieder nur auf die Regelung für begrenzte ressourcen und nicht auf den allgemeinen Fall. das beispiel sieht wie Java aus, ist aber kein java (Diskussionen oben). Verbesserungswürdig. --HartmutS 19:09, 29. Apr 2006 (CEST)

wie wird der Semaphor von wem geändert?

P(Semaphor s)
{
  while (s <= 0) {}
  s = s-1 ;
}

Schon für ein Semaphor innerhalb eines Programmes erscheint mir das seltsam. Wenn s ein Funktionsparameter ist, ist es wohl kaum eine globale Variable. Wie kann dann aber s erhöht werden, während ein Prozess im while im Kreise flitzt?

Aber egal ob globale Variable oder Funktionsparameter, wie soll ein externer Prozess denn eine Variable in einem anderen Programm ändern? --jailbird 22:09, 16. Dez. 2006 (CET)

Hat sich vmtl. ebenfalls erledigt (Beispiel ist nirgends mehr im Artikel...) ? --arilou 14:19, 10. Aug. 2010 (CEST)

Anmerkungen

Semaphore gehören zu den klassischen Elementen der Informatik. Eine Umbenennung der Operationen in Anfordern o.ä. sollte auf keinen Fall vorgenommen werden. Ich plädiere für eine einheitliche und durchgängige Verwendung von P() und V(). Die von systemnahen Bibliotheken angebotenen Operation wie down/up oder wait/signal sollten aber erwähnt werden.

Semaphore werden für die Prozesssynchronisation verwendet. Synchronisation bedeutet das Herstellen einer Reihenfolge. Dies ist erforderlich beim Zugriff auf gemeinsam genutzte, aber exklusiv zu nutzende Daten (Konkurrenz). Da ein Prozess A nicht weiss, ob andere Prozesse ebenfalls auf derartige Daten zugreifen wollen, muss A seine Zugriffe immer mittels Semaphoroperation umrahmen. Gibt es andere Prozesse, die auf die Daten zugreifen, nachdem A seine P-Operation ausgeführt hat, so werden sie blockiert. Gibt es keine anderen, so passiert halt nichts. Das Besondere an Semaphoren im Vergleich zu anderen HW-nahen Synchronisationsmethoden ist, dass bei Absetzen einer V-Operation ein wartender Prozess deblockiert wird und dies ohne dass der V-absetzende Prozess sich im Detail darum kümmern muss.

Eine andere Form der Herstellung einer Reihenfolge liegt vor, wenn Prozess B mit seinen Aktionen erst dann weiter machen darf/kann, wenn Prozess A eine bestimmte Aktion ausgeführt hat (Kooperation). Auch hierfür werden Semaphore eingesetzt.

In der einleitenden Erklärung sollte daher "zur Prozesssynchronisation" unbedingt stehen bleiben. Gut fände ich es, wenn beide Synchronisationssituationen aufgeführt würden:

Ein Semaphor (zur Wortherkunft siehe Begriffserklärung) ist ein Datentyp zur Prozesssynchronisation. Der Datentyp stellt Prozessen/Threads Operationen zur Verfügung, mit denen Konkurrenz- wie Kooperationssituationen zwischen Prozessen/Threads effizient behandelt werden.

Die Beispiele der Einleitung zu Betriebsmitteln finde ich nicht passend. Die Nutzung der Ressource CPU wird nie über Semaphore geregelt. Programmteile (die krit. Abschnitte) sind keine Betriebsmittel, die von Prozessen angefordert werden. In einem krit. Abschnitt greift ein Prozess/Thread auf gemeinsam genutzte, aber exklusiv zu nutzende Daten zu.

Hinsichtlich Prozess - Thread schlage ich die Kombination Prozess/Thread vor. Eine Unterscheidung ist m.E. nicht erforderlich. Semaphore werden allgemein als ein Betriebssystemkonzept für die Prozesssynchronisation angesehen. Semaphore werden i.a. vom BS implementiert. Ein Prozess ruft Systemdienste auf, um einen Semaphor zu initialisieren und zu nutzen. Andere Prozesse operieren mit dann ebenfalls mit diesem Semaphor, der im Adressbereich des Betriebssystems und damit allen Prozessen gemeinsam platziert ist.

Den Abschnitt Probleme bei mehreren Prozessen (oder vielleicht: Formen der Interaktion paralleler Prozesse/Threads?) würde ich gemäß den oben erwähnten Synchronisationssituationen gliedern:

• Konkurrenz: Prozesse/Threads arbeiten exklusiv mit Betriebsmitteln, die nur in beschränkter Anzahl zur Verfügung stehen, und bei denen ein Verzicht auf eine Regelung Probleme der Art auftreten lassen, wie sie unter Zugriffsarten aufgeführt sind.
• Kooperation: Prozesse/Threads müssen ihre Aktionen in vorgegebener Reihenfolge ausführen (z.B. Initialisierung von Nutzung oder klassisch: Erzeuger kann nur dann etwas im Puffer ablegen, wenn dort von einem Verbraucher Platz geschaffen wurde).

Im Lösungsabschnitt würde ich es besser finden, wenn Datenstruktur durch den mächtigeren Begriff Datentyp (abstrakter Datentyp?) ersetzt wird. Falsch ist die Aussage "Es wird festgelegt, wie viele kritische Prozesse existieren dürfen". Es können beliebig viele Prozesse über einen Semaphor synchronisiert werden. Es weiss i.d.R. auch niemand, wie viele Prozesse gleichzeitig ein Betriebsmittel benötigen. Um die Erläuterung auch für die Kooperation gültig zu halten, sollte statt "im Falle Zähler größer als Null darf er den kritischen Abschnitt betreten" allgemeiner etwas wie "im Falle Zähler größer gleich(!) Null darf er weiter machen" ausgesagt werden. Wo kommt die Aussage "Manchmal wartet auch der Prozess bei wait in einer Schleife" her? Charakteristisch für Semaphore ist m.E. das Blockieren von Prozessen. Dies unterscheidet den Semaphor von Polling-/Busy-Waiting-Lösungen. Entsprechend habe ich Bedenken, die Busy-Waiting-Implementierung aufzuführen. Zumal sie nicht richtig ist. In der while-Schleife "while (s-- <= 0) {;};" wird s mit jedem Schleifendurchlauf dekrementiert. Somit wird ein einmaliger V-Operationsaufruf den durch P blockierten Prozess nicht entblockieren.--AHagerer 15:48, 20. Jan. 2007 (CET)

Zu "Umbenennung P und V" : Wikipedia ist nicht für Leute, die's schon wissen, selbige brauchen kein Lexikon...

Zu "Prozess-Synchronisation" : Da stimme ich HartmutS zu (s.o.), Semaphore sind nur ein Teil der Prozess-Synchronisation.

Zu "Ressource CPU" : Auch nicht bei Mehrkern-CPUs ?

Zu "Semaphor ist BS-Teil" : Nicht in Programmiersprachen, die ihrerseits "intern" Multithreading anbieten (z.B. Java). i.A. ist aber wohl notwendig, dass die Semaphoren-Implementierung ihrerseits atomar ist.

Rest: Weitgehend erledigt.

--arilou 14:32, 10. Aug. 2010 (CEST)

Semaphore <= 0 und Prozess darf weiterlaufen?

Hallo zusammen!

Müsste es nicht heißen:

Ist der Zähler danach größer gleich 0, so wird ein Prozess aus der Warteschlange entfernt.

Und im Listing entsprechend:

    if (s.zaehler >= 0)
         ready (s.queue);       /* Entblockieren eines Prozesses aus der Warteschlange */

Gruß Torsten --Chiefluz 22:48, 28. Jun. 2007 (CEST)

Nein, dass darf es nicht. Ist der Zähler größer 0, so gibt sein Wert an, wie viele Prozesse noch ohne Blockierung die P-Operation aufrufen können. Ist der Zähler negativ, so gibt sein Absolutwert an, wie viele Prozesse die P-Operation aufgerufen haben und dabei blockiert wurden. Im Fall des Schutzes eines kritischen Abschnitts wird der Semaphor mit 1 initialisiert (= ein Prozess darf in den k.A.). Ein zweiter, dritter, vierter usw. Prozess, der anschließend in den k.A. will, ruft die P-Operation auf und wird blockiert. Der Zähler nimmt dann die Werte -1, -2, -3 usw. an. Verlässt ein Prozess den k.A. und ruft die V-Operation auf, so muss bei negativem Zählerstand ein Prozess entblockiert werden. Bei positivem Zählerstand gibt es keine blockierten Prozesse.

-- AHagerer 14:44, 6. Jul. 2007 (CEST)

^^Richtig! Daher habe ich nun das if (s.zaehler >= 0) entfernt da es einfach falsch war. Es muss immer ein Prozess aufgeweckt werden(ausser es ist keiner zum aufwecken in der Schlange). Ich denke an die vielen armen Mitmenschen die hier das Falsche gelesen haben und es dadurch nicht oder falsch verstanden haben. :-(

Nein! Es muss nur ein Prozess aufgeweckt werden, wenn auch einer wartet. Also "if (s.zaehler <= 0)"!

Durchlaufbeispiel:

Initialisierung mit zaehler=1

Thread1.P -> zaehler = 0 -> läuft durch

Thread2.P -> zaehler = -1 -> blockiert sich selbst

Thread3.P -> zaehler = -2 -> blockiert sich selbst

Thread1.V -> zaehler = -1 -> Ein Thread muss freigegeben werden (oBdA: Thread2)

Thread2.P -> zaehler = 0 -> Ein weiterer Thread muss freigegeben werden.

Thread3.P -> zahler = 1 -> kein Thread muss freigegeben werden.

Habe die (mal wieder) falsche Seite korrigiert.

--AndiHoffi (ohne Account), 2008-09-29, 16:35

In der Implementierung von V() muss die Bedingung zaehler<=0 geprüft werden. Ich habe es verbessert, jetzt sollte es wer freigeben. (nicht signierter Beitrag von 80.149.17.50 (Diskussion | Beiträge) 09:01, 12. Aug. 2009 (CEST))

In dem Beispiel von Andi müsste es nach Freigabe von Thread2 (4. Schritt) doch Thread2.V und Thread3.V heißen, oder? --79.242.20.127 12:24, 16. Okt. 2009 (CEST)

Sehe ich auch so, war wohl ein Copy&Paste Fehler ;) --F GX 10:08, 22. Feb. 2010 (CET)

mit Atombomben auf Spatzen geschossen !?

Ihr Lieben (diese Anrede an Euch soll meine wirklich tiefe Wertschätzung bezeugen),

mit allerhöchstem Respekt an Eure dozierenden - und gleichwohl ganz sicher richtigen - Statements:

Hinsichtlich WP:OMA bitte ich indes um etwas Mäßigung zu diesem Thema.

Ich bin IT-Berater. Unsereiner hat oftmals die Aufgabe, Nichtwissenden bestimmte Themen nahe zu bringen. Wenn ich meinen Kunden dieses Thema - oder schlicht den Begriff - näherbringen würde mit der Empfehlung, sich auf dieser Seite kundig zu machen (dies ist eine Enzyklopädie und kein Informatik-Lehrbuch, oder?), würden sie mir wohl meine armen entzündeten Augen auskratzen.

Ich - bei aller Demut nur ein Dipl.-Ing. TH - mit 20 Jahren Berufserfahrung im IT-Bereich, muss den Artikel schon 20 Mal lesen, um ein Viertel zu verstehen. Da kann also was nicht stimmen: in meinem Kopf oder womöglich auch im Artikel. Mmmmh....

In erster Näherung ist es doch ganz einfach, oder? Meine ich.

VORSCHLAG:

Ein Semaphor dient dazu, zwei voneinander unabhängig ablaufende Prozesse derart zu steuern, dass der zweite Prozess erst dann mit seiner Arbeit beginnt, wenn der erste Prozess seine Aufgaben erledigt hat.

Ich tendiere stark dazu, dies MIT GEWALT - Wikipedia:Sei mutig - in den Einführungssatz zu schieben.

Indes überlege ich noch ein wenig... Ich bin kein Hooligan.

Seit MUTIG und gebt mir ein GO (oder no-GO, wenn Ihr das meint).

Liebe Grüße von -Wolfgang- --195.4.187.242 00:42, 23. Aug. 2007 (CEST)

toll. dein beitrag hier beweist nur, dass ein informatikstudium offensichtlich gar nichts bringt, wenn man programmierer werden möchte.ich bin während meiner arbeit auf semaphore gestossen und mir hat der artikel weitergeholfen. ich musste ihn auch nur einmal lesen. fachwissen muss sich einem laien nicht sofort und in vollem umfang erschließen - wenn man da ganz konsequent sein wollte, wäre der artikel gar nicht in der wikipedia. --217.84.43.214 12:02, 21. Apr. 2008 (CEST)

Lieber Wolfgang,

Ich stimme Dir zu, dass der Text den WP:OMA-Test wohl nicht besteht. Gegen eine Erweiterung um eine mehr allgemein gehaltene Erläuterung ist daher nichts einzuwenden. Allerdings habe ich bei Deinem Vorschlag Bedenken. Er spricht nur an, dass ein Semaphor in Situationen der Form "Prozess A vor Prozess B" (die Kooperationssituation) genutzt wird. Die ursprünglich bedeutendere Situation, in der ein Semaphor verhindert, dass Prozesse gemeinsam genutzte Daten in inkonsistente Zustände bringen, bleibt unerwähnt. Er klingt mir auch zu sehr danach, dass ein Semaphor so etwas ist wie eine Ampel, die auf grün springt, um dem zweite Prozess zu signalisieren, dass er nun beginnen kann. Die Ampel könnte von einem Beobachter/Operateur bedient werden. Wäre der Operateur mit der Ampel dann ein Semaphor? Mir fehlt da, dass die Programmierer der Prozesse selbst den Semaphor einrichten und benutzen müssen. Ferner bin ich der Ansicht, dass der Artikel auch erläutern sollte, was ein Semaphor ist, und nicht nur wozu er verwendet wird. -- AHagerer 10:14, 23. Aug. 2007 (CEST)

Ich gebe Euch beiden Recht, der Artikel bedarf einer Überarbeitung nicht nur der inhaltlichen Darstellung, sondern auch des Ausdrucks wegen. Für eine einleitende Beschreibung würde ich gerade der schnellen Erschließung eines Themas eine einfache Beschreibung wählen und darauf auch hinweisen durch ein Stichwort "(ver)einfach(t)" oder "beispielsweise" oder "umgangssprachlich" und danach dann die vollständige Beschreibung folgen lassen. Eine vereinfachte Beschreibung kann durchaus auch durch einen Anwendungsfall skizziert werden! Bezüglich einer anderen Verbesserung: Bsp: "Der entblockierte Prozess setzt dann seine Aktionen mit denen fort, die dem P-Aufruf folgen, der den Prozess blockierte. " (Bereich: Lösung von Dijkstra) Weder inhaltlich verständlich, noch grammatikalisch ;) Gerade bei Ablaufsänderungen sollte eindeutig und gern auch redundant beschrieben werden (z.B. zusätzliche Grafik). Denn hier ist nicht klar, ob die Betriebsmittel gleichzeitig genutzt werden (und dürfen). Da der Prozess, der die BM blockierte, als auch der Prozess, der nun freigegeben wurde laufen (und damit ebenfalls auf die BM zugreift), was zu einem Fehler führen kann - abhängig davon, wieviele Prozesse auf die eine Resource BM zugreifen dürfen. --Glasgoogle 17:39, 13. Mai 2013 (CEST)

Sourcecode für V und P korrekt?

Ich lerne gerade für eine Prüfung. In meinen Unterlagen steht, dass bei der V-Operation der Zähler nur inkrementiert wird, wenn kein anderer Prozesse in der Warteschlange steht. Steht dort jedoch ein Prozess (oder mehrere Prozesse), wird einer von diesen geweckt, ohne dass der Zähler verändert wird. Das bedeutet natürlich, dass der neue, geweckte Prozess den Zähler selbst nicht mehr ändert. Was ist nun korrekt? Im Code im Artikel sieht es ja auch so aus, als würde ein geweckter Prozess nicht noch einmal die P-Methode aufrufen, müsste er aber, wenn vom vorherigen Prozess der Zähler inkrementiert wurde. Oder ist das nur nen Implementationsdetail? --Admiral kay 17:52, 27. Apr. 2008 (CEST)

Generell gilt für Semaphore, dass ein Prozess für eine Synchronisation nur einmal die P-Operation absetzt. Im Rahmen der Ausführung der P-Operation kann es zu einer Blockierung des Prozesses kommen. Für den Prozess, der die Details der P-Operation nicht kennt/sieht, sieht es dann so aus, als ob die Ausführung der P-Operation viel Zeit benötigen würde. Ist die Ressource, die mittels des Semaphors verwaltet wird, verfügbar oder ist der kritische Abschnitt betretbar, so setzt der Prozess mit der Aktion fort, die dem P-Aufruf folgt. Ob nun der Zähler, der zur Implementierung eines Semaphors verwendet wird, bei der V-Operation inkrementiert wird oder nicht, hängt von der konkreten Implementierung der P-Operation ab. Man kann die Operationen z.B. mit einem Zähler implementieren, der niemals negative Werte annimmt (das ist vermutlich bei der von Dir geschilderten Implementierung der Fall): bei P wird geprüft, ob der Zähler gleich 0 ist; wenn ja, wird der Aufrufer ohne Veränderung des Zählers blockiert; wenn nein, wird der Zähler dekrementiert; bei V wird nur dann inkrementiert, wenn kein Prozess blockiert ist. Positiv an der Beispielimplementierung im Artikel ist m.E., dass man am Zählerwert ablesen kann, wie viele Prozesse am Semaphor blockiert sind. --AHagerer 13:02, 13. Mai 2008 (CEST)

Müsste es bei der V-Operation nicht >= 0 sein? sagen wir mal, der zaehler startet bei 4. Dann werden 4 Prozesse reingelassen. Und der Zaehler steht auf 0. Wenn jetzt ein Prozess P ausführt, wird der zaehler wieder hochgezählt, also steht er auf 1 --> kein Prozess wird geweckt.. Macht meiner Meinung nach keinen Sinn.. (nicht signierter Beitrag von 109.91.30.87 (Diskussion) 00:46, 10. Jul 2014 (CEST))

Geschichte

Bitte darum, die Behauptung, Semaphore gingen auf mechanische Eisenbahnsignale zurück, nochmals zu prüfen, denn m. W. greift diese Behauptung keineswegs weit genug in die Geschichte zurück, denn Semaphore gab es bereits früher. Semaphore waren auch schon während der Napoleonischen Kriege bekannt, z. B. als Küstensignalstationen (damals bereits als Semaphore bezeichnet), mit denen Flotteninformationen für küstennahe Schiffe übermittelt wurden. Im Grunde wurde da bei der Matrose, der ansonsten Signalfahnen schwenkte, durch einen mehrere Stockwerke hohen Signalturm mit Armen ersetzt. Insofern gehen Semaphore eben nicht auf mechanische Eisenbahnsignale zurück, denn es gab Semaphore bereits bevor es diese Eisenbahn überhaupt gab.Giotto-X 23:01, 19. Mär. 2009 (CET)

Kooperationssituation: Beispiel fehlerhaft und unklar

Hi. beschäftige mich gerade zum ersten Mal mit Semaphoren, da mir bisher Monitoring und Reentrantlock-Konstrukte genug waren (ist ja grob dasselbe). Was ich hier aber nicht verstehe ist, warum man für eine Kooperationssituation das Semaphor mit 0 initialisiert. Wenn jetzt ein erster Thread s.P() aufruft, sperrt es sich selbst und das Programm ist im Deadlock. Was soll das denn bewirken? Zweitens ist der Code für das Anwendungsbeispiel eben jener Koop Situation nicht verständlich, was soll es denn bewirken s.P() und dann gleich s.V() aufzurufen? Und warum macht der zweite Thread garnichts? Danke. --F GX 10:34, 22. Feb. 2010 (CET)

Bei Kooperation/Kommunikation läuft es anders herum: Annahme: Thread A erzeugt Datenpakete, die an Thread B weitergegeben werden sollen. Die Semaphore zählt, wie viele Datenpakete verfügbar sind. Wenn jetzt B mit einem Probieren() startet, dann muss er warten, bis A endlich ein Paket (mittels V()) anliefert... Und am Anfang stehen tatsächlich 0 Datenpakete für B zur Verfügung. --arilou 14:39, 10. Aug. 2010 (CEST)

Rechtsschreibung

Null Fakultät Semikolon? (nicht signierter Beitrag von 77.22.49.78 (Diskussion) 22:59, 11. Aug. 2010 (CEST))

Null betonendes_Ausrufezeichen Satzende_Semikolon ;-) --arilou 14:50, 12. Aug. 2010 (CEST)

Hat dieser Abschnitt irgendeinen Sinn? --MartinThoma (Diskussion) 13:20, 13. Mär. 2012 (CET)

Definition vs. Funktionsweise

Ich finde, man sollte den zweiten Teil aus dem Abschnitt Funktionsweise: "...ist eine Datenstruktur, die bei der Programmierung zur Prozesssynchronisation eingesetzt werden kann..."
zur Eingangsdefinition und den Satz
"...die aus einer Ganzzahl und den Nutzungsoperationen „Reservieren/Probieren“ und „Freigeben“ besteht..."
zu Funktionsweise verschieben.

Damit käme eine OMA besser zurecht (imo). --RobTorgel (Diskussion) 14:28, 13. Mär. 2012 (CET)