Diskussion:Kritischer Abschnitt

kleine Anmerkungen

Moin,

hier einige kleine Anmerkungen.

• Ein kritischer Abschnitt ist kein Mechanismus, sondern nur ein Codeabschnitt, der auf eine gemeinsame Ressource zugreift und deswegen geschützt werden muss.
• Bei den Bedingungen des wechselseitigen Ausschlusses fehlt meines Erachtens noch, dass der kritische Abschnitt in endlicher Zeit verlassen werden muss und dass jeder Prozess, der eintreten möchte, wegen Fairness und Vermeindung von Verklemmung/Verhungern auch nach endlicher Zeit eintreten darf
• Insgesamt denke ich, dass dei Bedingungen vielleicht eher in einen Artikel über wechselseitigen Ausschluß gehören (mit Mutex zusammenführen?)
• Der Artikel liest sich so, als ob es hier nur um Threads ginge, vielleicht sollte das allgemeiner formuliert werden
• Java raus, lieber allgemein halten?

Das nur kurz... hm, ist doch mehr geworden... -- Glauschwuffel 08:03, 31. Jan 2006 (CET)

Die Idee, einen inhaltsreichen Artikel unter Zusammenführung mit dem Mutex-Problem zu gestalten, hatte ich auch. In der englischen Wikipedia habe ich den Hinweis gelesen, Spinlock mit Busy waiting zusammenzuführen. Das ist im Ganzen an sich ein großes Thema.

Java raus, dafür bin ich nicht, denn: Java ist fast allgemein bekannt, plattformübergreifend und unterstützt insbesondere diese Probleme. Aber Java alleine tut's nicht. In der englischen Wiki habe ich wiederum ein Beispiel unter [[1]] Critical_section gefunden, das auf Win - API bezogen ist. Ich meine, das sollte man ungetestet erstmal übernhemen dürfen (wenn man unseren englischen Wiki-friends vertraut), wenn ich Zeit habe, zuweilen brauche ich das auch auf Arbeit, werde ich versuchen das auch praktisch einzusetzen. Auf Arbeit bin ich an Problemen der Automatisierungstechnik mit einem Haus-Multithreadsystem beteiligt, da kommt es aber darauf an, das ganze unter PC-Bedingungen (Visual Studio) simulativ zu testen, da kann ich's brauchen.

Ich habe also vor, das ganze demnächst zu überarbeiten, ..... brauche nur noch die nötige Zeit --HartmutS 21:02, 10. Feb 2006 (CET)

Jetzt habe ich mal die Einleitung geändert. Diese Fehlerhafte Beschreibung hat doch nur verwirt. Zusätzlich habe ich mal eine Zwischenüberschrift eingefügt um den Artikel etwas aufzulockern. Aber einiges vermisse ich hier schon noch:

• Mutex und Semaphore fehlen hier völlig. Ich habe es wenigstens mal unten in den Links eingefügt. Sie müssen ja nicht erklärt werden, denn dafür gibt es ja eigene Artikel, aber erwähnt und mit einem oder zwei Sätzen definiert müsse sie hier schon werden.
• Es wirkt hier so, als dürfe immer nur ein Thread sich im kritischen Abschnitt befinden. Es gibt aber auch Situationen, in denen sich bis zu drei Threads gleichzeitig auf die Resource zugreifen dürfen. Zum Beispiel ein Drucker, der drei Aufträge gleichzeitig bearbeiten kann (siehe Semaphor)

Stefan2 12:04, 21. Feb 2006 (CET)

In den Artikeln im Umfeld des wechselseitigen Ausschlusses werden zuviele Dinge durcheinander geworfen, wie z.B. Mutex einerseits als Kofferwort, andererseits eben auch als konkrete Implementation eines binären Semaphors. Dann entsteht vielleicht auch bei einigen Lesern der Eindruck, dass wechselseitiger Ausschluss bedeutet, dass sich immer nur genau ein Prozess in seinem kritischen Abschnitt befindet.

Vielleicht sollte man Mutex sauber aufdröseln als Begrifssklärung -- einerseits Konzept, andererseits Implementation eben eines binären Semaphors. Und in der Seite (etwa wechselseitiger Ausschluss (Problem)) kann dann auf die verschiedenen Unterartikel verwiesen werden. Da sollten dann auch unbedingt Standard-Probleme wie das Leser-Schreiber, Bankiers- und Produzent-Verbraucher-Problem aufgenommen werden. --Glauschwuffel 07:35, 22. Feb 2006 (CET)

Ich habe den einleitenden Satz dahingehend eindeutig gestaltet, dass er auf den Codeabschnitt bezogen ist, der - aus vielerlei Gründen - kritisch ist. Das ist das, was auch Glauschwuffel oben gemeint hat, IMHO. Alles andere ist dringeblieben, aber ich denke, hier ist noch Überarbeitung, im Zusammenhang mit Mutex usw., nötig, schrittweise ... --HartmutS 11:11, 11. Apr 2006 (CEST)

Also, nunmehr stimmt nur der einleitende Satz, der Rest ist hier Unsinn. Ich sehe die Grundprinzipien zum Artikel genauso, wie oben in der Diskussion Glauschwuffel geschrieben hat. Demzufolge sollte folgendes erwähnt werden:

• Wie kann ein kritischer Abschnitt als kritisch bezeichnet werden, Interruptsperre, Taskwechselsperre oder Mutex.
• Sicherstellen dass ein kritischer Abschnitt in definiert kurzer Zeit wieder verlassen wird, das ist ein etwas umfangreichers Problem (eigener Abschnitt)
• Was ist, wenn das Programm darin festhängt (Probleme mit kritischen Abschnitt als Überschrift

mfG --HartmutS 12:51, 13. Apr 2006 (CEST)

Ich hab mal den Artikel in oben genannter Form überarbeitet. Das CRITICAL_SECTION-Beispiel stammt aus der englischen Wiki. Dort habe ich allerdings auch einen Kommentar in die Diskussion hineingeschrieben, da auch in der englischen Wiki ein kritischer Abschnitt nicht als solcher betrachtet wird sondern sofort wieder mit Mutex verwechselt wird. --HartmutS 21:26, 26. Apr 2006 (CEST)

Zweifel an Verständlichkeit

Ich halte die Erläuterung des Begriffs für nicht wirklich verständlich.
Ein kritischer Abschnitt ist wie angemerkt ein Codeabschnitt. In diesem Codeabschnitt werden Daten (allgemein Betriebsmittel) verändert, die auch von anderen Prozessen verändert werden. Eine parallele oder zeitlich verschränkte Veränderung dieser Daten durch diese Prozesse darf jedoch nicht erfolgen, da es sonst zu unverhergesehenen Ergebnissen oder inkonsistenten Zuständen der Daten kommt. Das aufgeführte Zählbeispiel verdeutlicht das. In der einleitenden Erläuterung heißt es hingegen, dass beliebige Unterbrechungen nicht zugelassen werden dürfen. Für einen Programmierer stellen sich doch dann folgende Fragen: wie erkennt man, ob ein Codestück nicht unterbrochen werden darf, und wie erreicht man die Nichtunterbrechbarkeit.
Ein Prozess darf unterbrochen werden, wenn er sich im k.A. befindet. Dies erfolgt z.B., wenn eine Geräterückmeldung vom BS zu bearbeiten ist. Ein Prozess im k.A. kann sogar blockiert werden, wenn er z.B. einen Seitenfehler ausgelöst hat. Es darf nur kein Prozess ausgeführt werden, der dann auch in seinen k.A. bezüglich der Daten ist.
Mit den zwei weiteren Sätzen der Einleitung komme ich nicht klar: wie hängen k.A. mit "generelle Unterbrechungssperre" zusammen? Was heißt "Die Ursache für einen kritischen Abschnitt kann eine zeitliche sein"? Was ist ein "zeitlich deterministischer Hardwarezugriff"? Was sind Multithreading- oder Mutex-Gründe? Folgt man dem Mutex-Link, so stellt sich die Frage, wie ein Verfahren, das etwas verhindert, einen Grund für einen k.A. darstellt. Mit "Mutex-Gründe" ist wohl der wechselseitige Ausschluss gemeint.

Ich schlage folgende Erläuterung vor und stelle sie erstmal zur Diskussion:
Als Kritischer Abschnitt wird in der Informatik ein Abschnitt im Programm des Prozesses bezeichnet, in dem Daten oder Betriebsmittel verändert werden und der nicht parallel oder zeitlich verzahnt zu Programmabschnitten anderer Prozesse, in denen die Daten bzw. Betriebsmittel ebenfalls verändert werden, ausgeführt werden darf. Andernfalls kommt es zu inkonsistenten Zuständen der Daten bzw. Betriebsmittel.

Anmerkungen zu "Beispiele für kritische Abschnitte" etc.

Der Mutex-Unterabschnitt enthält m.E. kein Beispiel für einen k.A., sondern für die Lösung eines Problems, das im Zusammenhang mit k.A. entsteht. Das Beispiel unter dem Abschnitt Beispiele ist hingegen deutlicher (wieso eigentlich zwei Beispielabschnitte?).

Der Unterabschnitt Hardwarezugriff behandelt den Aspekt der Ausführung innerhalb einer gewissen Zeit. Diese Zeitbedingungen werden aber im klassischen Sinn nicht im Zusammenhang mit k.A. verwendet. Ein Andeuten, k.A. mittels Unterbrechungssperre zu behandeln, halte ich für problematisch, da eine einfache Anwendung die privilegierten Befehle zum Setzen von Unterbrechungssperren nicht ausführen kann.

Auch der Unterabschnitt Threadwechselsperre verdeutlicht den Begriff k.A. nicht durch ein Beispiel, sondern skizziert ein Symptom, dass durch eine k.A.-Behandlung mittels Mutex im Zusammenhang mit Prioritäten entsteht.

Ich würde es besser finden, wenn das Beispiel aus Beispiele hier aufgeführt würde.

Sorry - aber auch mit dem Abschnitt Bedingungen habe ich Schwierigkeiten. Aufgrund des Titels würde ich erwarten, dass Umstände aufgeführt werden, die beschreiben, wann ein Codeabschnitt ein k.A. ist. Aufgeführt werden aber i.w. die Anforderungen an Lösungen zum wechselseitigen Ausschluss, d.h. zum Umgang mit k.A. Im übrigen darf in einem k.A. ein Mutex-Zugriff erfolgen. Wie will man sonst ausdrücken, dass man auf mehrere, unterschiedliche Daten/Betriebsmittel verändern zugreifen will. Man muss sich natürlich dabei der Gefahr einer Verklemmung bewusst sein. Die Bedingung, blockierende Systemdienstaufrufe zu unterlassen, deckt sich mit der ersten Bedingung, dass ein Prozess seinen k.A. in endlicher Zeit verlassen muss. Es wird aber nicht gefordert, dass der k.A. in einer bestimmten Zeit verlassen wird. Als Programmierer umrahme ich einen k.A. z.B. durch Mutex-Operationen. Aber weder der Programmierer noch das BS legt vor Ausführung des k.A. fest, wie lange die Ausführung dauern darf. --AHagerer 12:15, 20. Jan. 2007 (CET)

Race Condition

Hallo, sollte man die Artikel "kritischer Abschnitt" und "Race Condition" nicht zusammenfassen oder zumindest verknüpfen? --YourAntiHero 11:57, 6. Feb. 2007 (CET)

@YourAntiHero: Ich habe es mal unter "Siehe auch" erwähnt. --Trustable (Diskussion) 08:41, 29. Mai 2017 (CEST)

Frage zur Definition

Die definition besagt, kritische Abschnitte sind Kodestücke, bei denen jeweils die Daten geändert werden: "Abschnitt im Programm...in dem Betriebsmittel ... verändert werden ... nicht parallel ... zu Programmabschnitten ... in denen die gleichen Betriebsmittel ebenfalls verändert werden". Ich denke, dass ist nicht ganz richtig: Es kann auch ein Programmabschnitt ein kritischer Abschnitt sein, der gemeinsame Betriebsmittel nicht verändert, sofern es einen anderen Abschnitt gibt, der das tut. Einfachstes Beispiel: Zwei Variablen, die zusammen immer 0 ergeben sollen, also z.B. VA=10, VB=-10; Dazu Prozess 1: VA -= 5; VB += 5; Nun Prozess 2: Print (VA+VB) -- hier können inkonsistente Werte ausgegeben werden, obwohl Prozess 2 die Variablen nicht verändert. Nach der Definition ist aber der Kode in Prozess 2 kein kritischer Abschnitt. Sollte man die Definition dann so anpassen, dass es heißt, dass mindestens einer der Prozesse die gemeinsamen Betriebsmittel ändert, dass das aber nicht zwangsweise alle machen müssen? Oder ist das wirklich kein kritischer Abschnitt?

Versuch zur Klärung

Es geht im Zusammenhang mit Kritischen Abschnitten um die Gefährdung der Konsistenz des Systemzustands durch Race Conditions (vgl. auch Erläuterungen von Andrew S.Tanenbaum in: "Modern Operating Systems"). Dabei ist zu beachten, dass die Konsistenz von der Anwendung her definiert wird (Semantik). Soll heissen, was Konsistent ist, definiert letztlich der Mensch, der ein bestimmtes Resultat einer Operation seiner Anwendung erwartet.

Zur Verdeutlichung nochmal das Beispiel aus dem Artikel:

local_v = shared_v
local_v = local_v + 1
shared_v = local_v

Nach der Definition "Kritische Abschnitte sind Code-Abschnitte, die auf Shared Resources arbeiten", wäre hier auch folgende Klammerung korrekt:

critical {
 local_v = shared_v
}
local_v = local_v + 1
critical {
 shared_v = local_v
}

Es wird einsichtig, dass ein Schutz der mit critical gekennzeichneten Abschnitte nicht ausreicht, um das von dem gesamten Code erwartete Ergebnis (nämlich shared_v = shared_v + 1) gegen Race Conditions zu Schützen.

Kritische Abschnitte sind jene Code-Abschnitte im System in denen die Konsistenz des Systemzustands im Sinne der Anwendung durch Race Conditions gefährdet wird.

Betrachtet man nun ein System als Menge kooperierender Ressourcen und Tasks (Prozesse/Threads), dann ist ein konsistenter Zustand eine Kombination von Zuständen aller beteiligten Ressourcen und Tasks, die im Sinne der Anwendung konsistent ist. Zustände der Ressourcen müssen ebenso zueinander passen, wie Zustände der Ressourcen zum aktuellen Fortschritt der Tasks in deren Code. Bezogen auf das Beispiel oben: Auch Code-Abschnitte die eine Menge von Operationen auf den Ressourcen VA und VB ausführen sind Kritische Abschnitte, weil die Konsistenz im Sinne der Anwendung (VA+VB == 10) gefährdet wird. -- Homac 22:37, 24. Mär. 2010 (CET)

Parallele / zeitlich verzahnte Ausführung

Momentan steht folgender Satz in der Einleitung:

Als Kritischer Abschnitt wird in der Informatik ein Abschnitt eines Programms bezeichnet, 
in dem Betriebsmittel (z. B. Datenstrukturen, Verbindungen, Geräte usw.) verändert werden 
und der nicht parallel oder zeitlich verzahnt zu Programmabschnitten anderer Prozesse/Threads 
ausgeführt werden darf, in denen die gleichen Betriebsmittel ebenfalls verändert werden.

Wo ist der Unterschied, wenn es um die Nutzung von Betriebsmitteln mit gegenseitigem Ausschluss geht? Wenn das Betriebsmittel den Zugriff nur für einen Prozess / Thread erlaubt, gibt es keine echte Parallelität also nur die zeitlich verzahnte Ausführung. Wenn das so stimmt, dann würde ich gerne das parallel raus löschen. Der satz ist eh viel zu lang. --MartinThoma (Diskussion) 14:13, 13. Mär. 2012 (CET)