Diskussion:Mutex

Mutex im Userspace

Die Aussage, dass sich Mutex im Userspace implementieren lässt, ist falsch. Jede art von Locking (Locks, Semaphore, Monitore) lässen sich durch Spinlocks/Buisy-Waiting (und nur so) im userspace implementiren. Echtes locking geht nur mit unterstützung des Laufzeitsystems: man braucht einen Mechanismus, um einen Prozess warten zu lassen. Das muss von der Komponente bereitgestellt werden die das Scheduling macht.

Die Beispielimplementation hier verlässt sich auf "synchronized"/"wait"/"signal", also auf Monitore die vom Laufzeitsystem zur Verfügung gestellt werden. Die Implementation des Mutex wird hier also durch ein vom System vorgegebenes Mutex erreicht. -- D. Dÿsentrieb ⇌ 21:22, 26. Jan 2005 (CET)

der erste satz ist falsch: mittels spinlocks ist echtes mutex-verhalten, also ausschließlicher zugriff auf eine resource rein im userspace erreichbar. der scheduler muß davon nichts wissen. wenn ein prozess schlafen gelegt werden soll, braucht man den scheduler natürlich, der rest ist also in ordnung. interessant sind noch futex-operationen, die komplett im userspace ablaufen, solange kein anderer prozess darum konkurriert. erst wenn es tatsächlich zu einem konflikt kommt, wird der kernel gebraucht um den prozess schlafen zu legen. siehe http://ds9a.nl/futex-manpages/futex4.html -- ∂ 21:46, 26. Jan 2005 (CET)

Die Aussage: "Der Effekt ist, dass der Prozess warten muss wenn gerade ein anderer auf diese Daten zugreift.", ist unklar. Wartet er aktiv? Dies trifft z.B. auf die bekannten Spinlockimplementierungen im Linuxkernel zu. Dagegen gibt es Muteximplementierungen, wo ein anfordernder Prozess bei einem belegten Mutex schlafen gelegt wird. Dazu erfolgt ein Eintrag in einer Warteliste. Gibt der belegende Prozess den Mutex frei, so weckt er einen wartenden Prozess(in Abhänigkeit seiner Priorität) und kennzeichnet ihn als Besitzer des Mutexes. Desweiteren ist die Aussage: "Auf anderen Systemen (insbesondere Echtzeitsystemen) muss auf Spinlocks zurückgegriffen werden, die die Performanz durch Busy Waiting erheblich beeinträchtigen." so nicht richtig. Da gerade Spinlocks unkalkulierbare Latenzzeiten beinhalten (wie lange dauert der kritische Abschnitt?), stellen sie ein großes Problem für Echtzeitsysteme dar. Bestes Beispiel ist wieder Linux, das durchgehend Spinlocks verwendet und nur weiche Echtzeit bietet. Hier müßte man recherchieren, wie kritische Abschnitte in Echtzeitbetriebssystemen(z.B. QNX und VxWorks) geschützt werden, bzw. was die zusätzlich machen, wenn sie Spinlocks verwenden. Auch hinsichtlich der schlechteren Performanz wäre ich vorsichtig, da in erster Line das Konzept der Mutexe / Spinlocks nicht die Geschwindigkeit steigert sondern die Preemptivität. Es gilt abzuwägen, wie lange es dauert einen Prozess schlafen zu legen und wieder aufzuwecken, oder ihn nur einfach aktiv Warten zu lassen. Gerade wenn man die kritischen Abschnitte klein hält, kann sogar der umgekehrte Effekt eintreten, Performanceverlust. Was noch gar nicht angeprochen wurde, sind die Probleme, die bei der Verwendung von Mutexen auftreten: z.B. Prioritätsinversion, Deadlocks, Interrupthandler(wenn der wartende Prozess schlafen gelegt wird) und "race conditions" & "common case"(Vergleich zwischen Prinzip der aktive wartenden Prozesse und der schlafengelegten Prozesse). Es wäre auch angebracht zwischen Einzelprozessormaschienen(Preemptionsperren) und SMP-Systemen(Spinlocks) zu unterscheiden, wenn man aktiv wartenden Prozesse hat. Bei der anderen Version gibt es diese Unterscheidung nicht. Das ein Mutex nichts weiter als ein binärer Semaphor ist, könnte man auch noch unterbringen.

Du hast absolute recht, wenn ich die Zeit finde, werde ich das ein oder andere noch einarbeiten. Aber warum erweiterst du nicht selbst den Artikel? Du scheinst dich ja recht gut auszukennen. -- D. Dÿsentrieb ⇌ 19:33, 31. Jan 2005 (CET)

Begriff

Moin,

ich finde den den Seitennamen unglücklich gewählt. Mutex ist eher ein Begriff für die konkrete Implementation eines Mechanismus', mit dem die Eigenschaft des wechselseitigen Ausschlusses prozessübergreifend realisiert wird. Das steht hier zwar auch im Artikel, aber „gegenseitiger Ausschluss“ ist schlicht eine Umlenkung hierher. Hm. Klingt ein wenig nach einer Begriffsklärungsseite.

Auf der Seite wechselseitiger Ausschluss (Eigenschaft) könnten dann auch eher die Bedingungen aufgeführt werden, die unter Kritischer_Abschnitt aufgeführt sind.

Bin ich zu pingelig? Dies ist mein erster Versuch, Inhalte, die über mehrere Artikel verstreut sind, zusammenzuführen. Hole ich mir jetzt eine blutige Nase? :-) --Glauschwuffel 08:16, 31. Jan 2006 (CET)

Also, "Mutex" ist ein Kofferwort für mutual exclusion, was die wörtliche Übersetzung von gegenseitiger Ausschluss ist. Das ist wirklich das selbe. Auch ist Mutex nicht notwendigerweise Prozessübergreifend (wenn man "Prozess" im engeren Sinne versteht): das bezieht sich auch auf Threads, etc. Es stimmt schon dass der Ausdruck "Mutx" manchmal auch etwas ungenau für Monitore verwendet wird, aber das ist nicht die eigentliche Bedeutung.

Vergleiche en:Mutex: Mutual exclusion (often abbreviated to mutex) algorithms are used in concurrent programming to avoid the concurrent use of un-shareable resources by pieces of computer code called critical sections. Examples of such resources are fine-grained flags, counters or queues, used to communicate between code that runs concurrently, such as an application and its interrupt handlers. The problem is acute because a thread can be stopped or started at any time.

Mutex ist das, was man braucht, um einen kritischen Abschnitt zu Schützen. Monitore, Semaphore, Queues, etc sind möglichkeiten, das zu implementieren. Die Begriffe sind eng Verwand, aber IMHO schon unterschiedlich. Vielleicht wäre es aber besser, wie in der englischen WP von "Mutex-Algorithmen" zu sprechen, und den Artikel entsprechend zu präzisieren.

zwei weitere eng verwandte Artikel sind übrigens Interprozesskommunikation und Prozessynchronisation. Es wäre schon prima, den ganzen Themenkomplex mal zu überarbeiten - aber man sollte dabei nicht unterschiedliche Begriff in einen Topf werfen. -- D. Dÿsentrieb ⇌ 10:24, 31. Jan 2006 (CET)

In meinem Kopf hakte es nur, weil ich „Mutex“ wirklich nur als programmiersprachliches Konstrukt (etwa POSIX Mutex) kenne und mir dieser Begriff in der Bedeutung des wechselseitigen Ausschlusses an sich noch nicht über den Weg gelaufen ist.

Mit „Prozess“ meinte ich oben etwa „Arbeitsvorgang“ und nicht genau „Prozess“ als Gegenstück zu „Thread“. War wohl deutlich zu undeutlich...

Ich denke, dass „Mutex“ eben nicht nur (wie Du oben schreibst) den Mechanismus der Programmiersprache/des Betriebssystems bezeichnet, sondern ursprünglich eben die Eigenschaft bezeichnet, die man gerne erreichen möchte. Und die sähe ich gerne genauer präzisiert, so wie das z.B. in diversen Büchern gemacht wird oder eben auch ein bisschen in kritischer Abschnitt.

Beim Überarbeiten des Komplexes bin ich gerne dabei. Wie machen wir das am besten? Gibt's dafür eine bewährte Vorgehensweise? Vielleicht sollten wir mal sammeln, welche Artikel es so gibt. Das wird wohl hoffentlich nicht die gesamte Kategorie Parallelverarbeitung umfassen... :-) --Glauschwuffel 07:36, 2. Feb 2006 (CET)

Die zu erreichende Eigenschaft ist mMn die Sequentialisierung der kritischen Abschnitte. Der Gegenseitige Ausschluss ist wohl die einfachste Möglichkeit das zu Erreichen. Ich verstehe nicht ganz... du sagst einerseits, du kennst Mutex nur als konkretes Konstrukt, andererseits bezeichnest du es als Eigenschaft... was denn nun? Ich würde Mutex als Konzept oder Methode verstehen... weniger Konkret als Monitore, Semaphore, etc, aber schon Konkreter als der allgemeine Begriff der Sequentialisierung bzw. Prozesssynchronisation.

Was das überarbeiten angeht... ja, ein Sammeln der Zusammengehörigen Begriffe ist ein gute Anfang. Man kann dan versuchen, die Begriffe in den Artikeln abzugrenzen bzw. in Beziehung zu setzen. Dabei sollten Überlappungen und Unklarheiten eigentlich von alleine Auffallen. -- D. Dÿsentrieb ⇌ 10:50, 2. Feb 2006 (CET)

Vielleicht hakt bei mit auch nur das englische Kofferwort. Ich versuche noch einen Anlauf. :-)

Im Deutschen kenne ich Mutex so konkret wie POSIX Mutexe sind. mutual exclusion kenne ich als Kofferwort im Deutschen genau dafür - ein POSIX Mutex garantiert wechselseitigen Ausschluss.

Die Eigenschaft, dass sich nebenläufige Prozesse beim Wettbewerb um eine Ressource artig verhalten, um Verklemmung und Verhungern zu vermeiden, kenne ich als wechselseitigen Ausschluss.

Da fällt mir gerade auf, dass im Artikel „gegenseitiger Ausschluss“ steht. „Wechselseitig“ trifft′s genauer, da sich gegenseitig ausschliessende Prozesse ganz prächtig in einer Verklemmung befinden...

Wo würden wir denn zusammengehörigen Begriffe sammeln? Hier oder auf Benutzerseiten? --Glauschwuffel 11:42, 2. Feb 2006 (CET)

Hm, vielleicht wäre es am besten, nochmal auf Portal Diskussion:Informatik nachzufragen, und eventuelle Überarbeitungen dort zu besürechen und zu koordinieren. Meine Ansichten sind ja auch nicht der Weissheit letzter Schluss ;) -- D. Dÿsentrieb ⇌ 11:49, 2. Feb 2006 (CET)

Was es nicht alles gibt in der Wikipädie... ich stöbere mal auf der Diskussionsseite ;) --Glauschwuffel 13:57, 2. Feb 2006 (CET)

Hallo Wikipedianer, ich hatte mich gerade entschieden, bei Kritischer_Abschnitt überarbeiten zu wollen und dort alle Probleme über Mutex, spinlock usw. zusammenzuführen, und war gerade beim Blättern in den Diskussionsseiten. Die Artikelbearbeitungen selbst sind eher selten (im Vergleich beispielsweise zu Atlantis, das sollte aber ein Negativvergleich sein. Auf Arbeit bin ich teilweise auch mit solchen Dingen zu gange. Ich will mal ganz auf die schnelle ein paar Gedanken hier benennen (noch weniger durchdarcht):

• Mutext = mutial exclusion = gegenseitiger Ausschluss bezeichnet wortwörtlich und allgemein das Problem, das nicht zwei Threads oder Prozesse oder irgendwer sonst gleichzeitig auf etwas zugreifen dürfen. Das ist kein konkretes Verfahren sondern eher die Benennung des Problems.

• Kritischer Abschnitt = critical section ist ein Programmcodefragment, das ununterbrochen ablaufen soll weil es zueinandergehörige Operationen enthält, das ist also das selbe Problem aus Sicht der Codierung bzw. des Maschinencodeablaufes. Aber hier ist nachzufragen, wer unterbrechen darf. Wenn die Zeit keine Rolle spielt, dann kann in der CPU jeder unterbrechen, der nichts mit denjenigen Daten zu tun hat, die hier kritisch bearbeitet werden. Wenn mehrere CPUs am Werk sind, dann genügt nicht die Nichtunterbrechung im kritischen Abschnitt, sondern die Nichtbusabgabe für den Speicherzugriff im kritischen Abschnitt! Das muss erwähnt werden. In diesem Sinne geht es eigentlich um Mutex und 'kritischer Abschnitt' ist nur ein Teil des Problems.

• Semaphore, Monitor sind Ausdrücke aus den technischen Lösungsmöglichkeiten.

• Spinlock ist eine Möglichkeit des Wartens auf eine Freigabe, die durchaus sinnvoll und gebräuchlich ist, die aber nur funktiniert, wenn entweder ein wait(time) gerufen wird, mit Abgabe der CPU damit ein anderer Prozess überhaupt arbeiten kann!! oder damit nicht hektische Buslast erzeugt wird. Ich würde also das wait() als sinnvollste Nunance etwas deutlicher herausstellen. Ich habe schon gegen 1992 ein wait eingebaut, wenn ich auf recordlocking in einem File gewartet habe, unter DOS!

Ich würde das Ganze so gestalten, dass alle Begriffe auf einen Artikel umgeleitet werden, denke Mutex weil dass die allgemeinste Problemstellung ist, und das auf einer Bildschirmseite alle zugehörigen Begriffe fett sichtbar kurz erläutert werden, mit ihrer englischen Entsprechung und einem Link auf die eigenständigen Seiten für Monitor, Semaphore usw. Darunter sollte in Abschnitten gegliedert (könnte länger werden) auf Probleme und Lösungen eingegangen werden. Beispielsweise auch sowas: Eine niedrig priore Task schnappt sich über Semaphor-Locking eine Bearbeitung von Daten, die sonst hochprior bearbeitet werden, um ganz schnell in einem kritischen Abschnitt zusammenhängend was zu tun. Dummerweise wird diese niedrig priore Task von einer mittelprioren einige -zig ms unterbrochen, und die hochpriore Task hat das Nachsehen. System crashed. Solche Probleme treten selten auf, weil der Zufall es selten dazukommen lässt und werden daher oft missachtet. Aber sie sind fatal für eine Echtzeitsteuerung. Erwähnt werden muss auch, was ohne besonderes zutun nichtunterbrechbar ist, so gibt es bei einigen Prozessoren extra Befehle für TestAndSet. Auch ein unteilbarer Zugriff eines Schreibens eines 32-bit-Wertes, der auf einem 16-bit-Prozessor dummerweise doch wieder geteilt wird, ist erwähnenswert. Interruptsperre als Geamtsperre des Prozessors, Buslock als Gesamtsperre des Speicherzugriffes, wann ist die nötig, aber das geht nur auf Betriebssystemebene usw. Das ist ne Menge Stoff und viel Details.

... mehr fällt mir für heute abend nicht ein, hab noch was andres vor. Ich freue mich auf Rückmeldungen. mfG --HartmutS 22:17, 10. Feb 2006 (CET)

Fein, wir werden mehr :-) Ich werde mal ein wenig in Wikipedia:Wartung lesen, wie wir das am geschicktesten anstellen. Ich habe mich soeben in Wikipedia:Werkstatt/Computer_und_Internet eingetragen, da könnten wir dann ja zu überarbeitenden Artikel sammeln.

Ich denke, bezüglich Überarbeitung eines Artikels ist diese Diskussionsseite da, ... ich habe erstmal nur den einleitenden Satz bereinigt:

• Alle vorher vorhandenen Links aus diesem Satz sind nicht verloren sondern stehen unten.
• Es ist keine Methode zur Prozesssynchronisation sondern hat (nur) indirekt damit etwas zu tun.
• Die nichtsequentielle Programmierung ist umgeleitet zu parallele Programmierung, und dieser Inhalt ist m.E. nicht ganz stimmig. Dort sind zwei Aspekte vermischt (Diskussion siehe dort). Das kernproblem diesbezüglich ist eher Thread_(Informatik).
• Aber das Mutexproblem ist nicht auf Multithreading beschränkt, statt der Transaktionssysteme, die eher speziell sind, habe ich hier einleitend das allgemeine Beispiel des konkurrierenden Datenbankzugriffes (eigentlich wollte ich eher auf File-Locking eingehen) erwähnt, um nicht beschränkend auf Multithreading zu wirken.

Ich denke, der einleitende Satz sollte nun stimmen. Weitere Bearbeitung, Diskussion sollte folgen. --HartmutS 10:47, 11. Apr 2006 (CEST)

Ich habe mir die Seite kritischer Abschnitt angeschaut und gesehen, dass diese gar nicht mehr stimmig ist. Insbesondere das Java-Beispiel gehört zu Mutex, daher habe ich es hierhin kopiert. Es sollte aus kritischer Abschnitt demnächst verschwinden. Querverweise sind da. Außerdem habe ich diesen Artikel gegliedert. Vorhandene Texte haben gepasst. Ich sehe folgende weitere Bearbeitungsnotwendigkeit:

• Lock kann etwas ausführlicher werden.
• das Problem des Pollings ist irgendwo beschrieben, gehört aber ursächlich hier hin als Verfahren zur Mutex-Realisierung. Polling ist aber noch mehr, Prozess-Synchronisation (dazu dient es auch) ist ein anderes Thema als Mutex. Also darf man nicht in den Fehler verfallen, alles bezüglich Polling hierhin zu ziehen.
• ... ich werde demnächst weiter arbeiten, wenn es die Zeit erlaubt, warte aber auf Diskussionsmeldungen hier.

Mit freundlichen Grüßen --HartmutS 09:27, 13. Apr 2006 (CEST)

Hm... Mutex und kritischer Abschnitt sind konzpetionell sehr eng verwant... ein Mutex-Mechanismus wird für kritische Abschnitte bnötigt (und nur dort). Ich finde durch die erweiterung haben wir jetzt auch starke überlappungen mit Prozesssynchronisation. Mechanismen sind auch unter Interprozesskommunikation beschrieben. Polling wird unter Spinlock beschrieben. Irgendwie müsste man das mal auseinanderfusseln. -- D. Dÿsentrieb ⇌ 11:09, 13. Apr 2006 (CEST)

Genau daher habe ich hier die Überarbeitung angefangen. Ich würde aber sagen, dass Mutex und Prozesssynchronisation eben nichts miteinander zu tun haben, außer das sie zu einem gemeinsamen Thema gehören. Warum: Es sind zwei verschiedene Ansinnen, die dahinter stehen:

• Prozesssynchronisation um Daten zwischen Threads (Prozessen) auszutauschen und um gemeinsam parallel zu arbeiten. Dort braucht man überhaupt keinen Mutex, wenn man alle Daten über Events übergibt oder zeitlich so koordiniert, dass ein konkurrierender Zugriff nicht passiert. Das ist überhaupt ein wichtiges Konzept und muss erklärt werden.
• Mutex ist genau dann nötig, wenn zwei verschiedene Partner (Prozesse) zwar auf gemeinsame Daten zugreifen, aber sonst miteinander nichts zu tun haben, also auch nicht synchron ablaufen müssen. Beispiel: Zwei Threads tragen Informationen in eine Liste ein, zwecks Verwaltung von listenzeigern ist Mutex bitter nötig, aber die Threads haben nichts miteinander zu tun.

Daher möchte ich diese beiden Dinge getrennt sehen.

Bei kritischer Abschnitt habe ich ja die Überarbeitung angekündigt. Ich schreibe gleich dort noch was in die Diskussion. Was sagst Du zu den überarbeitenden einleitenden Sätzen? Diese müssen zuerst stimmig sein.

Ich habe Formulierungne zum Thema Polling im Kopf. Polling selbst findet man nicht in der deutschen Wiki, wohl aber wenn auch nur kurz in der englischen. Diesbezüglich habe ich auch schon in Spinlock kritisch gelesen. Ich würde das hier anders formulieren, und erst danach (Diskussion zwischendurch) auch an Spinlock bearbeiten. Wo ist der Sachunterschied zwischen Spinlock und Busy Waiting ???

Ich schreib bzgl Polling demnächst in den Artikel, man kann dann immer noch feilen. HartmutS --HartmutS 12:56, 13. Apr 2006 (CEST)

Was unter Spinlock und Busy Waiting beschrieben ist, lässt sich meiner meinung auf 1 Artikel zusammenführen, das ist in wesentlichen das Polling. (Also nicht noch'n Artikel für Polling). Aber ich würde bzgl Polling bei Mutex auf folgendes hinweisen:

• wenn zyklisch, dann nicht hochzyklisch (wait(millisec) zur CPU-Abgabe)
• Auch je eine Abfrage in einer Zeitscheibe (Verweis auf Zeitteilverfahren ist ein polling, und auch sehr sinnvoll!
• Ein polling ist insbesondere dann notwendig wenn Prozesse sonst keine Verbindung haben, beispielsweise bei einem File-Locking. Hier ist aber insbesondere das niederzyklische Polling wichtig.

--HartmutS 13:41, 13. Apr 2006 (CEST)

Polling: Lesen und Nachdenken über das Aktives Warten, Schauen in die en.wikipedia.org, Nachdenken über polling, danach habe ich mich doch entschieden, einen eigenen Artikel über Polling_(Informatik) zu verfassen, weil das Spinning (=engl. synonym für aktives Warten) nur eine Möglichkeit des polling ist, polling umfasst mehr. Die engl. Wikipedia ist zu polling auch sehr kurz, aber eindeutig. Für die eigentliche Mutex-Thematik ist es unwichtig, ob man für das polling das Aktives Warten oder eine andere Form benutzt. (Wichtig wird es aber für die Gesamtsystemgestaltung.) --HartmutS 09:51, 14. Apr 2006 (CEST)

Stimmt schon: Polling ist viel allgemeiner als Aktives Warten - und hat an sich nichts mit Mutex zu tun. Ich frage mich gerade, ob wir analog auch Pushing brauchen - immerhin gibt es ja die Dichotomie Push vs. Poll, genau wie's die Dichotomie Synchron vs. Asynchron gibt, etc. Der Unterschied zwischen Busy Waiting und Spinlock ist in der Tat etwas künstlich, hatte ich aus der en wp übernommen: Ein Spinlock ist ein konkretes "Ding", das Busy Waiting (oder Lazy Polling) macht. Könnte man schon zusammenfassen.

Übrigens: wenn man Polling zur Prozessynchronisation einsetzt, setzt das die atomarität und exklusivität der Abfrage voraus (also letztlich:Mutex) - sonst könnten zwei Konsumenten gleichzeitig grünes Licht bekommen. Ich sehe daher nicht wirklich, wie man Mutex mittels Polling realisieren kann, ohne bereits einen Mutex-Mechanismus zu haben... -- D. Dÿsentrieb ⇌ 10:32, 14. Apr 2006 (CEST)

Pushing wäre das ständige Ansagen, da gibt es aber keine Kommunikation. Polling als Abfragen ist dagegen eine Art der Kommunikation. Pushing ist mir noch nicht begegnet, Polling sehr häufig.

Polling als solches setzt den Mutex nicht voraus, wenn man aber nur einen von mehreren Partnern, die allesamt pollen, drankommen lassen will dann muss also das Polling mit einem Mutex versehen werden. Das ist OK, das ist aber bereits eine konkrete Ausprägung eines besonderen Polling. --HartmutS 02:57, 18. Apr 2006 (CEST)

Mechanismen

Ich have die letzte Änderung von Benutzer:HartmutS erstmal zurückgenommen. Eigentlich finde ich aber den ganzen Abschnitt Mechanismen um einen Mutex zu realisieren komisch.

Um Mutex zu realisieren (um also einen kritischen Abschnitt zu schützen), benutzt man einen der Mechanismen der Prozesssynchronisation. Die einzelenen Mechanismen sollten dort aufgezählt, verglichen und abgegrenzt werden. Detailliert Beispiele gehören in die einzelartikel. Kritik im einzelnen: (Düsentrieb)

Prozessynchronisation und Mutex sind zwei grundverschiedene Themen, ich habe das oben schon mehrfach beschrieben, Warum? Es wird zu schnell in einen Topf geworfen, weil die Mechanismen ähnliche oder gleiche sind. Mir kommt es darauf an, die Unterschiede zu betonen. Wenn zwei Prozesse oder Threads nur wegen einem Mutex miteinander müssen, dann sind sie noch lange nicht synchron = zeitlich gleichlaufend sondern sie haben sich eben nur an dem Mutex kooperativ verhalten. Nichts mehr. Ich halte diese Klärung für grundlegend, auf der Diskussionsseite sollten durchaus Argumente und Gegenargumente gesammelt werden ....--HartmutS 02:57, 18. Apr 2006 (CEST)

Mit Mutex ist nicht ein kritischer Abschnitt zu schützen (siehe Diskussion dort, der kritischer Abschnitt ist auch überarbeitungswürdig, sondern mit Mutex sind Daten zu schützen. Der kritischer Abschnitt ist derjenige, der wegen der Datenbearbeitung kritisch ist. Auch hier sollten wir nochmal Argument sammeln.--HartmutS 02:57, 18. Apr 2006 (CEST)

Semaphore und Monitore kann man nicht über einen Kamm scheren (bzw wenn, warum dann nicht auch Locks?). Semaphore können z.B. durchaus mehreren Threads gleichzeitig den Zugriff erlauben (sie können eine Kapazität von > 1 haben). Ein Monitor bezieht sich auch immer explizit auf einen (oder mehrere) kritischen Abschnitt, ein Semaphor nicht unbedingt. Die Tabelle unten im Artikel Monitor (Informatik) Zeigt auch einige Unterschiede. (Düsentrieb)

Das Monitorkonzept ist umfassender, Semaphore ist zunächst nur eine Hilfsvariable zum Mutex-Schutz von Daten. Mit Semaphoren lassen sich Mutex-Schutzmechanismen aufbauen. Bei Semaphoren wird traditionell die Mehrwertigkeit betont. Das ist aber eigentlich nur eine besondere Ausprägung. Es lassen sich Mechanismen mit Semaphoren realisieren und beschreiben, es lässt sich der Monitormechanismus beschreiben. Vollkommen unabhängig. Doch letzlich steht das gleiche dahinter, meine ich. --HartmutS 02:57, 18. Apr 2006 (CEST)

Lock ist eine Ausprägung eines Mutex-Mechanismus. Dasjenige Bit im Filesystem, das das Lock speichert, könnte man als Semaphore bezeichnen. Eine automatische Benachrichtigung wartender Threads entspräche dann dem Monitor-Mechanismus. Alles das selbe. Aber: Der Unterschied ist eher im Begriff und in der Verwendung zu finden. Lock bedeutet "Festhalten", "Zuschließen" und bezieht sich auf den Datenzugriff (auf den gelockten File, die gelockte Version eines CVS). Wie das Lock realisiert wird, erscheint in diesem Zusammenhang eher unwichtig. Bei gelockten Dingen muss man sich meist mit Polling behelfen, um den zeitpunkt mitzukriegen, wann das Lock weg ist. Das ist IMHO das Spinlock. Spinlock ist ein Grundkonzept. Im Spinlock-Artikel wird das leider nicht gut erklärt sondern zu schnell auf Nachteile und wieder auf Scheduler, Monitor, Semaphore verwiesen, was hier unter Mutex steht. --HartmutS 02:57, 18. Apr 2006 (CEST)

Was unter Thread Waiting zu verstehen ist, ist mir schleierhaft, der Absatz dazu ist mir auch unverständlich. Jede Art der Prozessynchronisation (außer evtl. dem Spinlock) verwendet ein Blockieren des Prozesses - das ist kein eigener Mechanismus. (Düsentrieb)

Thread waiting als Begriff habe ich benutz als Gegensatz zu dem Polling-Verfahren, bei dem der Thread nicht auf wartend gestellt wird (höchstens und sinnvoll mit einem wait()-Befehl, aber nicht auf wartend wegen dem Mutex insgesamt). Es gibt zwei Dinge:

• aktives Warten (mit oder ohne wait()) und die zyklische Abfrage mit Polling
• und das, was ich als Thread waiting bezeichnet habe, wenn man so will passives Warten. Der Thread wird per Scheduler auf Wait gestellt und tut von sich aus nichts, er wird ausschließlich vom Scheduler geweckt. Dafür müsste es einen griffigeren Begriff geben.

"Polling" and sich als Mutex-Mechanismus aufzuführen halte ich für falsch - wenn, dann müsste mann das Spinlock nennen. Jede HTTP-Abfrage ist auch Polling, das hat nichts mit Mutex zu tun. Polling setzt voraus, dass ein Mechanismus zur Prozessynchronisation existiert - bei einer Kommunikation über gemeinsamen Speicher kann das ein Mutex-Mechanismus sein. Um,gekehrt wird also ein Schuh draus... (Düsentrieb)

Polling: Es gibt eben neben dem Spinlock noch das zyklische Abfragen, was auch Polling, aber kein Spinlock ist. Das Polling auch für andere Dinge benutzt wird, HTTP-Anfragen usw. steht außer Frage und nicht im Widerspruch. Ich meine, die Benutzung von Polling zählt zu den Mechanismen, um Mutex zu beherrschen. Ich meine nicht, Polling wäre ein Mutex-Mechanismus. --HartmutS 02:57, 18. Apr 2006 (CEST)

Polling setzt nicht voraus, dass ein Mechanismus zur Prozesssynchronisierung existiert. Für Polling braucht man nichts weiter als die Möglichkeit der Abfrage. Mit Polling kann man eine Prozessynchronisation erreichen (Abfrage, um dann zeitlich gleichlaufend zu agieren).--HartmutS 02:57, 18. Apr 2006 (CEST)

Die Bemerkung bei einer Kommunikation über gemeinsamen Speicher kann das ein Mutex-Mechanismus sein kriege ich nicht auf die Reihe. Wie genau kommuniziert wird, über ist für alle diese Fragen ein realisierungstechnischer Aspekt und hat nichts mit dem Prinzip zu tun, IMHO.--HartmutS 02:57, 18. Apr 2006 (CEST)

Ein Lock mit Polling abzufragen scheint mir übrigens auch widersinnig - bzw. müsste man klarstellen, ob das Warten auf Freigabe schon Teil des Lock-Konzeptes ist, oder nicht (IMHO ist es das). (Düsentrieb)

Für die Lock-Abfrage selbst gibt es die einfache Abfrage, hat nichts mit Polling zu tun. Aber um irgendwann kein Lock anzutreffen, ist Polling notwendig.--HartmutS 02:57, 18. Apr 2006 (CEST)

nochmal @HartmutS: Sorry für den revert, aber ich habe im Augenblick den Eindruck, dass deine Überarbeitung mehr Verwirrung stiftet, als sie behebt... -- D. Dÿsentrieb ⇌ 12:15, 14. Apr 2006 (CEST)

OK, also schaun wir mal was wir draus machen. Ich habe mich entschieden, evtl. entgegen dem Wiki-Stil die Antworten auf einzelne Anmerkungen von Duesentrieb in diesem Abschnitt Mechanismen einzeln eingerückt direkt darunter zu schreiben, weil der Text sonst auseinanderfällt. Das nicht eingerückte ist insgesamt von Düsentrieb. Ich habe immer (Düsentrieb) hinter die einzelnen Absätzen geschrieben. Die Diskussion möchte ich als interessant bezeichnen und weiterführen, um danach einen gemeinsamen Standpunkt zum Artikel zu bekommen. --HartmutS 02:57, 18. Apr 2006 (CEST)

Also, ich habe nunmehr einen zweiten Versuch, den Abschnitt Aktives und passives Warten, Artikelstand 2006-04-23 gewagt, um die Problematik darzustellen. Ich denke, könnte besser sein? --HartmutS 20:47, 23. Apr 2006 (CEST)

Unverständlich

Ich bekomme den Eindruck, dass ähnliche Mechanismen mit mehreren Namen belegt werden, vielleicht Unterschiede da sind, aber keiner genau weiß welche. Der Absatz Begriffe im Zusammenhang mit Mutex ist allein durch seine Überschrift schon sehr assoziativ. Die betreffenden Begriffe sollten aufgeräumt werden in die betreffenden Abschnitte. Offenbar handelt es sich bei Semaphor, Monitor und Lock um Mechanismen zur Markierung und Sperrung von Daten und bei Polling und Aktives Warten um Vorgehensweisen der konkurrierenden Threads. Vielleicht schafft es jemand, da Ordnung reinzubringen. Wenn die Begriffe unscharf definiert sind, sollte man sie genauer definieren, auch wenn unterschiedliche Ansichten darüber bestehen. --Siehe-auch-Löscher 10:00, 22. Mai 2007 (CEST)

Die unscharfe Begriffsverwendung ist nicht das Problem des Artikelinhaltes sondern ein allgemein sprachliches. Der Eine sagt A und versteht darunter in seinem Umfeld xy, der Andere sagt auch A, versteht aber unter seinen Bedingungen xz, der Dritte sagt B, versteht aber darunter das Gleiche xy wie der Andere unter A. Es soll gerade das Anliegen von Wikipedia sein, die Begriffsverwendung aufzudecken, nicht zu vertuschen indem so getan wird als sei alles klar! Ein Monitor ist ein Beobachtungsgerät im allgemeinen englischen Sprachgebrauch, jeder kennt den Begriff für ein Gerät in Form eines Bildschirmes. Ich war irgendwann einaml überrascht, dass der Begriff Monitor auch dort gebraucht wird, wo andererseits auch von Semaphore, Kritischer Abschnitt und ähnlichem geredet wird. Die Einen sagen semaphor, weil sie eine Assoziation an ein Eisenbahnsignal haben zur Realisierung eines gegenseitigen Ausschlusses, die Anderen sagen monitor weil sie im selben Zusammenhang eher den Schwerpunkt auf die Überwachung eines Betriebsmittels legen. Das sind unsere amerikanischen IT-Spezialisten verschiedenster Organisationen. Und wir übersetzen das dann direkt ins deutsche, ohne Rücksicht auf die englische etymologische Bedeutung der Begriffe und Feinunterschiede der direkten Übersetzung, stellen uns dabei aber die Bedeutung anders vor als im Englischem und mixen dann womöglich das Ganze in der eigenen Vorstellung mit ähnlichen deutschen Begriffen - false friends. Und schon gibts Begriffswirrwarr und Erklärungsnotstand. Das ist die Lage der Dinge. Nebenanmerkung zur Übersetzung: Schlimmer ist es noch, wenn Begriffe zwanghaft in deutsche Begriffe übersetzt werden, die eher ungeläufig sind, und dann noch mit falscher Begriffsnuance. Man sollte also im Zweifelsfall die englischen und geläufigen Begriffe beibehalten, aber in deutsch erklären.

Der Artikel soll unter dem geläufigen Fachbegriff Mutex die vielfältigen für den Ablauf von Software grundlegenden Mechanismen zum Themas Gegenseitiger Ausschluss erläutern. Das Thema ist ein Überthema. Gegenseitiger Ausschluss ist eine wörtliche Übersetzung von mutual exclusion. Daher sollte es passen, in diesem Artikel das Thema Mutex übergreifend zu beschreiben und auf weitere Artikel zu Details zu verweisen. Es sollte auch vollkommen in Ordnung sein, wenn man dann in Monitor_(Informatik) das eigentlich gleiche Thema aber anders beschrieben findet. Das wird man nicht verhindern können, evtl auch nicht wollen. Wikipedia ist nunmal nicht ein von einem Herausgeber verantwortetes Gesamtwerk sondern eine ziemlich freie Enziklopädie. Es ist doch besser, auf einen ähnlichen Artikel aber mit anderer Schreibweise, Sicht und Schreibern zu verweisen, als so zu tun als gäbe es den anderen Artikel nicht. Andere schreiben halt auch was Anderes, was ich vielleicht nicht gut finde, aber durch den Verweis wird man ja gerade gegeneinander aufmerksam und kann sich gegenseitig abgleichen - Diskussion und Wissenszuwachs. Das ist etwas Lebendes.

Schätzungsweise ist der Artikel in diesem Sinn zu ca. 40% angearbeitet. Eine Weiterbearbeitung wäre notwendig.--HartmutS 22:22, 17. Jun. 2007 (CEST)

Ich habe bei meiner letzten Bearbeitung des Artikels (ebenfalls zur Verhinderung der Löschung) genau versucht 1) Die Einleitung verständlicher zur Erklären und 2) zu erklären, dass der Begriff durchaus mehrere Bedeutungen hat. So sind auch die ersten Abschnitte im Artikel mehr oder weniger Begriffsdefinitionen, damit zunächst mal alle vom Gleichen sprechen. Sicher ist der Artikel noch verbesserungsfähig, aber löschen ist meiner Meinung nach mit Kanonen auf Spatzen geschossen. Ich glaube auch, den Baustein Unverständlich kann man jetzt entfernen, zumindest die Einleitung ist nun wohl OMA-tauglich. --PaterMcFly 08:39, 18. Jun. 2007 (CEST)

Weiterbearbeitung

Nachdem der Artikel sich in letzter Zeit nicht wesentlich geändert hat, aber immernoch nur ca.40% der Thematik drinstehen, sollte ich einiges hinzutun. Ausgehend von Praxiserfahrungen sehe ich die Themen:

• Testbarkeit von Algorithmen und Programmen unter Mutex-Gesichtspunkten: Hier ist mehr zu beachten als die einfachen üblichen Tests, Mutex-Probleme zeigen sich bei asynchronen Threads ggf. erst nach langer Laufzeit, bei quasi-Synchronität zunächst gar nicht sondern erst nach Änderung von Eingangsbedingungen, die mit den betreffenden Codes scheinbar nichts zu tun haben. Also ist ein systematischer Test noch wichtiger als sonst.
• Atomic, Stichwort z.B. aus java.util.concurrent.atomic, aber auch aus C-Sicht: Wann ist ein Zugriff atomic (16-bit-Prozessor: Zugriff auf 32 bit...), atomic ist ein grundlegender Mutex-Mechanismus, oft unbewusst eingesetzt,
• Multicore-Prozessoren, Mutex auf Speicherbereiche, auf die mehrere Prozessor-Kerne zugreifen. Ich habe auf der Jax-2008 in Wiesbaden zu diesem Thema einen interessanten Artikel gehört: A. Langer: Java-Programmierung im Multicore-Zeitalter, wäre ggf. zu verlinken.
• lock-free-programming ist auch ein essentielles Mutex-Thema, bei dem aber bewusst keine Exclusion stattfindet sondern stattdessen eine Wiederholung des Zugriffes mit letztgültigem atomic CompareAndSet. Wann verwendet man dies...

Das wäre übersichtlich anzubringen. Im Vergleich zu manch anderen Artikeln nicht aus dem Informatikbereich ist dieser Artikel eher kurz, kann also noch wesentlich mehr Umfang ertragen. Gerade weil das Thema in Informatikerkreisen oft uneinheitlich dargestellt wird, sollte man hier einen Grundlagenartikel ausbauen. - Ich hoffe ich finde demnächst dafür Zeit. --HartmutS 10:08, 18. Mai 2008 (CEST)

Oder vielleicht erst einmal überarbeiten?
Ich zweifle, ob die Erläuterungen prinzipiell erhellend sind. Es werden sehr viele Begriffe und Aspekte aufgezählt, die irgendwie im Zusammenhang mit "mutual exclusion" stehen. Viele Zusammenhänge werden aufgeführt, ohne näher erläutert zu werden (z.B. Semaphor und Task-Scheduler). In der Abgrenzung wird zwar Mutex als Verfahren für wechselseitigen Ausschluss verwendet. Dabei wird auf die Artikeleinleitung verwiesen. Dort findet sich aber keine Erläuterung, was mit wechselseitigem Ausschluss gemeint ist. Einige Aussagen sind nicht präzise. Ein synchronized-Programmblock wird nicht aufgerufen. Nach dem ursprünglichen Sempahorkonzept wird mit einem Semaphor nicht angezeigt, dass ein kritischer Abschnitt betreten wird. Ein Sempahor ist ein Objekt, dessen Benutzung den wechselseitigen Ausschluss garantiert. Im ursprünglichen Konzept gibt es auch keine Testmöglichkeit eines Semaphors. Semaphore sind Lösungen eines Betriebssystems (und nicht nur eines RTOS) für das Problem des wechselseitigen Ausschlusses. Ich teile ferner die unter der Diskussionsüberschrift Begriff aufgeführte Anmerkung, dass der Seitennamen unglücklich gewählt ist. Die Verkettung sollte umgekehrt sein: mutual exclusion ist die Aufgabe, die es zu bearbeiten gibt; wechselseitiger Ausschluss ist die Übersetzung, die in einer deutschsprachigen Enzyklopädie verwendet werden sollte; mutex als Abkürzung sollte auf wechselseitigen Ausschluss verweisen. --AHagerer 18:26, 24. Mai 2008 (CEST)

Diese Anmerkung soll von mir nicht unkommentiert stehengelassen werden:

• Also, bei genauer Betrachtung der Wortwahl wird ein synchronized-Programmblock nicht aufgerufen sondern durchlaufen oder ähnliches, bitte korrigieren. Dafür steht die Wikipedia jedem frei. Ich denke, dass muss man nicht groß diskutieren.
• RTOS ist auch falsch, das RT ist zuviel. Entschuldigung, bin realtimegeschädigt.
• Der einleitende Satz ist nicht von mir, also kann ich ihn loben! Ich meine, er stellt in etwa dar, worüber es bei Mutex geht. Mehr als nur um ein Betriebssystemhilfsmittel.
• Grundsätzlich (auch woanders schon diskutiert): Die krampfhafte Verwendung deutscher Begriffe für Dinge, die umgangssprachlich englisch verwendet werden, halte ich nicht für gut (Wer sagt heute schon Auskunftsschalter wenn jede Oma weiß dass das ein Infopoint ist). Also, der Begriff ist im deutschen Sprachraum in der englischen Form geläufig, und darf/sollte daher auch als Titel in dieser Form in einer deutschen Enzyklopädie stehen. Meines Erachtens ist aber die Bedeutungsübersetzung ins deutsche in der Erklärung wichtig. Sonst verwendet man Begriffe, keiner weiß was sie eigentlich bedeuten, und dann erfolgen Fehldeutungen.
• Wenn es ein ursprüngliches Semaphorenkonzept gibt (ich vermute eine Dissertation aus den 60-gern), dann bitte genauer benennen, mit link darauf.
• Ein Sempahor ist mitnichten ein Objekt, dessen Benutzung den wechselseitigen Ausschluss garantiert (wie soll das gehen, Zauberei?). Man kann nämlich auch programmieren, dass etwas benutzt wird (also ein kritischer Abschnitt betreten) ohne dass das Semaphor dabei getestet wird. Natürlich ist das meist fehlerträchtig oder falsch. Ein Semaphor ist lediglich ein Hilfsmittel, das es richtig einzusetzen gilt. In diesem Sinn meine ich schon, dass ein Semaphor anzeigen kann, dass ein kritischer Abschnitt betreten wurde.
• Der Artikel soll das Thema Mutex insgesamt fassen und dabei mit Verweisen auf andere Artikel nichts ungeklärt stehenlassen,dass sollte das Ziel sein. --87.175.76.220 19:03, 26. Mai 2008 (CEST) Entschuldigung für die IP, habe mich vergessen einzuloggen, HartmutS

Unberücksichtigt davon, dass mir ein deutscher Seitenname besser gefällt, halte ich "Mutex" (nicht mutual exclusion) als Seitennamen für problematisch/missverständlich. Sucht man nach "Mutex", so finden sich Seiten, auf denen es heißt, dass ein Mutex ein Synchronisationsobjekt ist. In der .NET Framework-Klassenbibliothek ist Mutex ein "primitiver Synchronisierungstyp". Diese Seite will aber den wechselseitigen Ausschluss (das Thema Mutex) und seine Realisierungsformen erläutern. Ich halte es für verwirrend, wenn Mutex hier ein Problem bezeichnet, an anderer Stelle aber eine Lösung.
Ein Semaphor garantiert natürlich den wechselseitigen Ausschluss - nicht durch Zauberei, sondern durch Implementierung im Betriebssystem (z.B. durch ein Spinlock oder Unterbrechungssperre). Ein Thread muss gerade nicht zyklisch abfragen, ob er seinen kritischen Abschnitt betreten kann. Ein Thread ruft vor dem krit. Abschnitt eine Semaphoroperation (s. POSIX sem_wait) auf, die ihn weiterläufen läßt oder blockiert, je nach Situation des krit. Abschnitts. Dies macht die Nutzung von Semaphoren gerade so einfach. Im allgemeinen bietet ein Betriebssystem zwar eine Funktion an (s. POSIX sem_try), mit der ein Thread testen kann, ob er ohne Blockierung in den kritischen Abschnitt kommt. Dies gibt ihm die Möglichkeit, etwas anderes Sinnvolles (also nicht die sofortige erneute Abfrage) statt des krit. Abschnitts zu erledigen, wenn dieser belegt ist. Aber er muss nicht testen. Ein Semaphor ist mehr als eine Anzeige oder ein Hilfsmittel. --AHagerer 19:07, 27. Mai 2008 (CEST)

Also, um nochmal die Einleitung zu loben, sieht immer noch gut aus! Ich finde aber die Formulierung Problem des kritischen Abschnitts gelöst unglücklich. Ich schreibe das deshalb in die Diskussion, weil ich auch in Kollgen/Fachdiskussionen dort schon viele Nuancen gehört habe. M.E. gibt es kein Problem des kritischen Abschnittes sondern das Problem eines geordneten Zugriffes auf irgendwas: Daten, Betriebsmittel. Der kritische Abschnitt bezeichnet ja nur ein Programmstück, was gesonderter Aufmerksamkeit bedarf, als Folge vom ersteren. Im Artikel kritischer Abschnitt habe ich vor längerer Zeit eine recht allgemeine Definition untergebracht, unter anderem auch, dass ein Programmcode unter Interruptsperre dazu zählt. -bin aber offensichtlich nicht verstanden worden von Lesern, die maschninennahe Programmierung nicht kennnen. Der aktuelle Stand dort handelt wieder nur von ...Betriebsmitteln... sehr allgemein, um danach ein sehr plattes Beispiel mit dem Zähler zu bringen. Das ist zuwenig, aber das gehört zu kritischer Abschnitt.

Im Gespräch mit Kollegen habe ich nochmals mich versichert, dass beispielsweise der umgangssprachliche Satz das muss unter Mutex ausgeführt werden allgemein benutzt und verständlich ist. Also ist Mutex ein wenn zwar künstlich und englisch, aber dennoch im deutschen Sprachraum so verwendetes Wort. Folglich sollte man an der Benennung des Artikels nichts ändern.

Die Definition Mutex ...Ein Objekt (bzw. eine Datenstruktur), das ... sehe ich kritisch. Das stimmt zwar - ist aber ungenau:

• Ein Schlüsselwort/Typdefinition einer bestimmten Programmiersprache kann schonmal identisch mit einem umgangssprachlichen Wort sein, aber das ist dann zweitrangig. Also nicht neben den Begriff als solchen zu stellen sondern spezialisiert zu konkretisieren Der Begriff Mutex wird unmittelbar in Programmiersprachen und Libraries verwendet, dabei in der Programmiersprache x ... soundso. Das bedarf mehrerer Sätze vielleicht in einem eigenen Abschnitt.
• Es stimmt eben nicht, dass Mutex == binäre Semaphore ist. In der Windows-API bezieht sich Mutex auf prozessübergrefende Sperren, ist also viel mehr. Dort ist die CRITICAL_SECTION dass, was als Datenstruktur für eine Implementierung eines Mutex innerhalb eines Prozesses verwendet werden sollte. Aber CRITICALSECTION ist wiederum mehr als eine einfache Semaphore, weil beispielsweise das mehrfache Belegen der selben CRITICAL_SECTION-Instanz (EnterCriticalSection) vom selben Thread akzeptiert wird. Diese Leistung macht auch synchronize in Java. Bei der Belegung einer Semaphore wird zunächst nicht der Thread selbst berücksichtigt. Der Thread kommt erst dann ins Spiel, weil eben dieser wegen der Semaphore zurückgestellt wird. - Zuguterletzt gibt es auch in der Windows-API noch Semahoren als solche, aber mehrwertig....

Ansonsten gibt es denke ich keine Differenzen in der Auffassung von Semaphoren. ...ruft vor dem krit. Abschnitt eine Semaphoroperation (s. POSIX sem_wait) auf, die ihn weiterläufen läßt oder blockiert..., ist genau dass, was ich auch kenne, mal auf ein firmeninternes RTOS bezogen. Die Sempahore ist ein grundlegender und einfacher Mechanismus, der eine gute Basis für alles Andere ist. Wie gesagt, CRITICAL_SECTION ist bereits umfassender. Die Semaphore steht also in einer API zu einem Multithreadsystem recht betriebssytemnahe. Damit ist auch klar, dass die richtige Anwendung von Semaphoren selbstverständlich den wechselseitigen Ausschluß garantiert (das ist das, was der Zauberer unterm Tisch eben macht), die Semaphore als solche aber noch nicht. Ich denke da gibt es keinen Widerspruch.

wait vs. polling/spin lock ist ein wichtiges Thema, nicht kurz abzuhandeln. Beides hat seine Berechtigung, oft auch nebeneinander. Das ist ein Thema, was unbedingt unter Mutex genauer erklärt werden sollte. Ich denke, dass ist im Abschnitt Aktives und passives Warten bereits angeordnet, kann aber noch ausgebaut werden.

Weshalb schreibe ich so viel - weil das Thema wichtig ist. Der Artikel hat sich im letzten Jahr kaum bewegt und ist nicht besser geworden. Gibt es zuwenig Schreiber, die sich hier etwas zutrauen? Besser Schreiben, Diskutieren und Korrigieren als nichts tun. Aber es ist eine Zeitfrage, mindestens für mich. --HartmutS 22:21, 30. Mai 2008 (CEST)

Ich begrüße diese Diskussion sehr. Ich finde aber, dass die Einleitung nun besser aussieht :).
So wie Mutex - wie geschildet - eine auch im deutschsprachigen Raum benutzte und i.a. verständliche Sammelbezeichnung für Verfahren ist, gegenseitigen Ausschluss zu realisieren, so ist kritischer Abschnitt eine Bezeichnung für Programmabschnitte in Prozessen/Threads, in denen Zugriffe auf gemeinsam genutzte Daten koordiniert werden müssen. Problem des k.A. ist dann eine prägnante, gebräuchliche Bezeichnung/Benennung der Aufgabe/Schwierigkeit, die geforderte Koordination zu erzielen. Die Kombination kritisch und Abschnitt ist im Zusammenhang mit Prozessen/Threads in dem geschilderten Sinne belegt. Die Verwendung von kritischer Abschnitt im Hinblick auf Erzielung/Erhalt andere Eigenschaften als die der Konsistenz einer Datenstruktur (z.B. Erhalt der Reaktivität) wird daher immer zusätzliche Situationsbeschreibungen und Erläuterungen erfordern. Dies geht m.E. über notwendige Erklärung des Begriffs kritischer Abschnitt hinaus.

Es stimmt eben nicht, dass Mutex == binäre Semaphore trifft den Kern meiner Bedenken bezüglich der Erläuterungen. Mal werden mit Mutex die Verfahren des gegenseitigen Ausschlusses bezeichnet und ein anderes Mal wird mit Mutex der Einfachheit halber (?) ein bestimmtes Verfahren referenziert. Hier müssen wir eine deutliche Trennung realisieren, vielleicht sogar sprachlich: Mutex-Verfahren oder Mutex-Objekt, aber nie nur Mutex. --AHagerer 13:32, 31. Mai 2008 (CEST)

Lassen sich Deadlocks so einfach vermeiden?

Zitat: „Solche Verklemmungen können durch eine geeignete Planung des Programmablaufs vermieden werden, ...“

Das ist sicher richtig.

und weiter im Zitat: „... zum Beispiel nach dem Peterson-Algorithmus oder dem Dekker-Algorithmus.“

Das ist sicher falsch, Peterson-Algorithmus und Dekker-Algorithmus sind nur „vollständige Lösung des Problems des wechselseitigen Ausschlusses“. Die Deadlock Problematik läßt sich durch diese trivialen und lokalen Algorithmus nicht lösen. 92.198.5.248 10:34, 12. Sep. 2008 (CEST)

Verbesserungen

Der Artikel ist imho zu implentierungs- und zu javalastig. Was völlig fehlt ist eine übersichtliche Erklärung als binärer Semaphore in einer Pseudogrammiersprache und/oder einer (UML)-Graphik, die allein das Konzept erläutert und zwar bevor man alle möglichen Verwandten Begriffe anreißt. Zudem ist der Artikel immer noch völlig quellenlos.--Kmhkmh 01:13, 12. Nov. 2009 (CET)

Mutex-*Verfahren*

Mutex bedetuet Wechselseitiger Ausschluss, und ein Mutex-Verfahren bezeichnet eine Gruppe von Algorithmen, die das Problem des kritischen Abschnitts lösen. In der (englischsprachigen) Literatur wird der Name "Mutex" auf für "Lock" verwendet. So, wie es jetzt da steht, klingt es, als wäre die Gruppe der Mutex-Verfahren und ein Mutex dasselbe. --sts ^(Tacheles) 12:02, 29. Jan. 2010 (CET)

Der, Die oder Das Semaphor

Im Abschnitt "Semaphor oder Monitor" wird Semaphor teilweise mit "das S.", aber auch "die S." bezeichnet. Leo gibt bei Semaphor "Das (oder Der)" an. Durch die unterschiedlichen Genera liest sich das teilweise holprig. Das sollte auf einen einheitlichen Genus verbessert werden. Welcher ist in der Informatik gebräuchlich? solovej 08:46, 30. Apr. 2010 (CEST)