Rekursion unterdrücken

[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 )

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 von Uwe Raabe:

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 )

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