Rekursion unterdrücken

[BiedermannS]

Hallo, ich bin vor kurzem unter die Delphi-Entwickler gegangen (auch beruflich) und auch neu hier im Forum. Und hab auch gleich mal meine erste Frage.

Ich schreibe grade an einer Unit zum Synchronisieren von Threads und hab mir eine Hilfs-Methode gebastelt, welche einen Codebereich automatisch mit einem Lock versieht und nach der Ausführung den Lock wieder entfernt. Die Methode sieht ca. so aus:

Code:

type
  TLockedCode = reference to procedure;

procedure Locked(proc: TLockedCode);
begin
{ Code zum Erzeugen des Locks }

proc;

{ Code zum Entfernen des Locks }
end;

Ausführen lässt sich das Ganze über:

Code:

Locked(procedure
begin
{ Code der auf eine kritische Ressource zugreift }
end);

Das funktioniert auch, allerdings würde ich gerne prüfen, ob der Parameter "proc" der aufrufenden Funktion entspricht, weil bei einer Rekursion sonst ein Deadlock entstehen würde, was ich lieber über eine Exception behandeln würde.

Gibt es eine Möglichkeit an die aufrufende Methode heranzukommen, welche auch ohne Stackframes funktioniert? (Eine Methode habe ich bereits gefunden, aber die funktioniert nur mit Stackframes)

LG

[BUG]

Zitat:

Zitat von BiedermannS (Beitrag 1258570)

weil bei einer Rekursion sonst ein Deadlock entstehen würde, was ich lieber über eine Exception behandeln würde.

Ich glaube die Variante mit der Methode ist der falsche Ansatz: Warum darf ein anderer Thread die Methode nicht aufrufen?

Wichtig ist, ob der aktuelle Thread schon diesen Lock belegt hat ... und selbst dann: Mutexe und Critical-Sections unter Windows sind rekursiv / reentrant.

Du könntest aber für jeden Lock auch die Thread-ID speichern, die diesen Lock gerade besitzt.
Damit könntest du rekursive Eintritte erkennen bzw. verhindern :wink:

Im Prinzip könnte das so aussehen:

Delphi-Quellcode:

procedure Locked(proc: TLockedCode);
begin
{ Abfragen der Thread-ID.
  Achtung: Das ist nur ungeschützt nur sicher,
    um festzustellen, ob die eigene Thread-ID drinsteht.
  Dann eventuell: Fehlerbehandlung. }
{ Code zum Erzeugen des Locks }
{ Eigene Thread-ID eintragen. }

proc;

{ Thread-ID des Locks auf ungültigen Wert setzen. }
{ Code zum Entfernen des Locks }
end;

[BiedermannS]

Andere Threads können die Methode ja aufrufen, allerdings soll eine Rekursion verhindert werden. Also z.B.:

Code:

procedure CriticalCode;
begin
  Locked(CriticalCode);
end;

Das führt nämlich unweigerlich zum Deadlock und das möchte ich verhindern, indem ich überprüfe ob die übergebene Methode gleich der aufrufenden Methode ist.

[himitsu]

Zitat:

Zitat von BiedermannS (Beitrag 1258572)

indem ich überprüfe ob die übergebene Methode gleich der aufrufenden Methode ist.

Die Adressen/Pointer vergleichen?


Nja, und was machst du, wenn die übergebene Methode das nicht direkt aufruft, sondern sie ruft wen Anderes auf, der dann aber letztendlich dennoch wieder hier landet?

[BUG]

Ah, jetzt verstehe ich vermutlich, was du vorhast: Jeder übergebenen Funktion wird in deiner Funktion ein Lock zugeordnet.

Aber wie gesagt: Ein Deadlock muss nicht auftreten, wenn du rekursive Synchronisierungsmittel benutzt.

Zitat:

After a thread obtains ownership of a mutex, it can specify the same mutex in repeated calls to the wait-functions without blocking its execution. This prevents a thread from deadlocking itself while waiting for a mutex that it already owns.

[Mutex Objects]

Zitat:

When a thread owns a critical section, it can make additional calls to EnterCriticalSection or TryEnterCriticalSection without blocking its exe

[Critical Section]

Wenn du trotzdem noch Rekursion feststellen möchtest, bleibt mein Vorschlage der Gleiche:
Merke dir pro Lock bzw. Methode, welcher Thread der Besitzer ist (sollte ja nur einer sein). Wenn es der gerade eintretende Thread ist, kannst du deine Exception werfen.

[Dejan Vu]

Wenn Du auf deine Aufrufkonvention verzichten könntest, dann ändere die Signatur einfach zu:

Delphi-Quellcode:

Procedure Locked (lockedCode : TMyLockedCode);
Begin
  if lockedCode.Busy then raise Exception.Create('recursion not allowed here');
  lockedCode.Busy := True;
  try
    LockedExecute(lockedCode.Code);
  finally
    lockedCode.Busy := False;
  end
End;

Eventuell kannst Du den Prozedurzeiger auch direkt hashen und dann einfach eine Hashtabelle nehmen und prüfen, so etwa (pseudocode)

Delphi-Quellcode:

Procedure Locked (lockedCode : TMethod);
var
  hash : DWORD;
Begin
  hash := MakeHash(lockedCode);
  
  if Busy[hash] then raise Exception.Create('recursion not allowed here');
  Busy[hash] := True;
  try
    LockedExecute(lockedCode());
  finally
    Busy[hash] := False;
  end
End;

Vielleicht geht #2 ja wirklich.

[BiedermannS]

Die Antwort von BUG hat mich letztendlich in die richtige Richtung geleitet. Ich brauche die Rekursion nur dann verbieten wenn, wenn der Lock für darunterliegende Aufrufe nicht verfügbar ist. Da ich zu Hause kein Delphi habe, hab ich das auch nicht wirklich testen können.

Nach einem initialen Test habe ich festgestellt, dass eine rekursive Funktion sich nicht selbst locked, da dies anscheinend bei TMonitor mit berücksichtigt wird.

Auf jeden Fall danke für die Hilfe (die Idee mit dem Hash ist auch nett :-D)

Wenn ihr wollt kann ich anschließend noch den fertigen Code posten.

LG

[Uwe Raabe]

Du solltest auch beachten, daß der Lock nicht zwingend an eine einzelne Methode gebunden ist. So würde es z.B. bei einem Listenobjekt nicht reichen, die Methoden Add und Delete mit jeweils einem getrennten Lock zu versehen. Vielmehr müssen die beiden auf denselben Lock verweisen. Beim Multi-Threading synchronisiert man nicht die Methoden, sondern die gemeinsam verwendeten Ressourcen. Methoden mit ihren lokalen Variablen und Parametern sind von Haus aus thread-safe. Im Allgemeinen nicht thread-safe ist der Zugriff auf Variablen, die außerhalb der Methoden deklariert sind. Mit deinem Ansatz deckst du nur den seltenen Spezialfall ab, daß diese Variablen ausschließlich von einer deiner Methoden verwendet werden. Das solltest du in deinem Design vorsehen, selbst wenn es zur Zeit nicht relevant ist.

[BiedermannS]

Zitat:

Zitat von Uwe Raabe (Beitrag 1258587)

Du solltest auch beachten, daß der Lock nicht zwingend an eine einzelne Methode gebunden ist.

Der Code wird innerhalb eines Objektes im Setter der Resource verwendet. Der Lock bezieht sich dahingehend also nicht auf die Prozedur an sich. Die Prozedur ist nur ein Helper um den Lock automatisch zu generieren und nach Ausführung automatisch wieder freizugeben (erspart dem Programmierer Denkarbeit :wink:)

Die Unit kann auch ohne den Helper verwendet werden um mehrere Ressourcen mit dem selben Lock zu sichern.