Mehrere oder eine Globale CriticalSection?

[QuickAndDirty]

Vermutlich ist die Frage Sau dämlich...

Szenario 1)
-Globale Resource GR-Z
-Thread-A benutzt CS-A
-Thread-B benutzt CS-B
-Beide Threads konkurieren um GR-Z und Blocken mit den Zugriff mit ihrer jeweiligen CS.
Wird die Resource so erfolgreich geblockt?

Szenario 2)
-Globale Resource GR-Z
-Globale Resource GR-Y
-Globale CS-Z
-Globale CS-Y
Threads benutzen jeweils immer CS-Z um in GR-Z zu schreiben und CS-Y um in GR-Y zu schreiben.
Läuft die Anwendung dann flüssiger als mit einer globalen CS für alle GR?

[himitsu]

Gegenfrage:

Wenn jeder Thread seine eigene Sperre hat, wie sollen sich sich dann gegenseitig Sperren/Absichern?


Eine Resource muß mit einer eingeutigen (globalen) Sperre abgesichert werden und jeder der darauf zugreift muß diese Sperre nutzen.

Und ja, es kann schneller sein, daß wenn man mehrere Sachen absichert, für jedes eine eigene Sperre (CS) verwendet, da dann parallele Zugriffe, auf unterschiedliche (und hoffentlich unabhängige) Resourcen möglich sind.
Man muß nur aufpassen, daß sich die CS nicht gegenseitig behindern.

z.B.

Code:

Thread 1:
  Sperre A holen
    mach was mit A
    Sperre B holen
      mach was mit A und B
    Sperre B freigeben
  Sperre A freigeben

Thread 2:
  Sperre B holen
    mach was mit B
    Sperre A holen
      mach was mit A und B
    Sperre A freigeben
  Sperre B freigeben

Hier kann es passieren, daß sich beide Threads gegenseitig blockieren.
und zwar wenn sie Beide gleichzeitig im ersten "mach was" Teil sind und dann jeweils auf den Anderen warten, bis er die Sperre freigibt, was niemals passieren wird, weil sie ja aufeinander warten.

Wenn zwei/mehrere Sperren kompiniert werden, dann müssen sie immer in der gleichen Reihenfolge gesperrt werden, damit es keine Probleme gibt.
Bei mehreren verschachtelten Sperren muß die Reihenfolge stimmen und egal ob man eine Sperre benötigt, es müssen immer alle Vorgänger (in der Reihenfolge) mit gesperrt werden, damit man nicht in einem Deadlock landen kann.

Code:

Thread 2:
  Sperre A holen
  Sperre B holen
    mach was mit B
    //Sperre A holen // optional ... kann man, wenn recursive Sperren möglich sind, muß man aber nicht (z.B. wenn es für die Logik und einen einheitlichen Code gut ist)
      mach was mit A und B
    //Sperre A freigeben
  Sperre B freigeben
  Sperre A freigeben

[QuickAndDirty]

Zitat:

Zitat von himitsu (Beitrag 1185243)

Gegenfrage:

Wenn jeder Thread seine eigene Sperre hat, wie sollen sich sich dann gegenseitig Sperren/Absichern?


Eine Resource muß mit einer eingeutigen (globalen) Sperre abgesichert werden und jeder der darauf zugreift muß diese Sperre nutzen.

Ich wusste nicht wie CS intern funktionieren...habe mir sowas aber schon gedacht...deswegen schrieb ich ja , daß es vielleicht eine Sau dumme Frage ist... :)

Danke, daß du diesen Punkt klargestellt hast.

Zitat:

Zitat von himitsu (Beitrag 1185243)

Und ja, es kann schneller sein, daß wenn man mehrere Sachen absichert, für jedes eine eigene Sperre (CS) verwendet, da dann parallele Zugriffe, auf unterschiedliche (und hoffentlich unabhängige) Resourcen möglich sind.
Man muß nur aufpassen, daß sich die CS nicht gegenseitig behindern.

z.B.

Code:

Thread 1:
  Sperre A holen
    mach was mit A
    Sperre B holen
      mach was mit A und B
    Sperre B freigeben
  Sperre A freigeben

Thread 2:
  Sperre B holen
    mach was mit B
    Sperre A holen
      mach was mit A und B
    Sperre A freigeben
  Sperre B freigeben

Hier kann es passieren, daß sich beide Threads gegenseitig blockieren.
und zwar wenn sie Beide gleichzeitig im ersten "mach was" Teil sind und dann jeweils auf den Anderen warten, bis er die Sperre freigibt, was niemals passieren wird, weil sie ja aufeinander warten.

Wenn zwei/mehrere Sperren kompiniert werden, dann müssen sie immer in der gleichen reihenfolge gesperrt werden, damit es keine Probleme gibt.
Bei mehreren Sperren muß die Reihenfolge stimmen und egal ob man eine Sperre benötigt, es müssen immer alle Vorgänger (in der Reihenfolge) mit gesperrt werden, damit man nicht in einem Deadlock landeten kann.

Oh gut, das sollte ich auch noch beachten.

Danke, du hast mit sehr geholfen!