Diskussion:Kritischer Abschnitt

message: 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)
thread_title:  Anmerkungen zu "Beispiele für kritische Abschnitte" etc. 

message: Hallo, sollte man die Artikel "kritischer Abschnitt" und "Race Condition" nicht zusammenfassen oder zumindest verknüpfen? --YourAntiHero 11:57, 6. Feb. 2007 (CET)
replies: text: Ich habe es mal unter "Siehe auch" erwähnt. --Trustable (Diskussion) 08:41, 29. Mai 2017 (CEST)
thread_title:  [[Race Condition]] 

message: 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)
thread_title:  Frage zur Definition 

message: 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)
thread_title:  Versuch zur Klärung 

message: 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)
thread_title:  Parallele / zeitlich verzahnte Ausführung