Wann wird TInterfacedObject.Destroy aufgerufen (eine ScopedLock-Klasse)

Question

Ich frage mich, wenn eine Instanz einer TInterfacedObject abgeleiteten Klasse zerstört wird und wer den Destruktor aufruft. Ich habe eine ScopedLock-Klasse geschrieben, die automatisch die Methode Release eines Synchronisierungsobjekts aufrufen sollte, wenn die Instanz den Gültigkeitsbereich verlässt. Es ist ein RAII-Konzept, das aus C++ bekannt ist, aber ich weiß nicht, ob es garantiert ist, dass der Destruktor aufgerufen wird, wenn die Sperrinstanz den Gültigkeitsbereich verlässt.

ILock = interface 
end; 

ScopedLock<T: TSynchroObject> = class(TInterfacedObject, ILock) 
strict private 
    sync_ : T; 
public 
    constructor Create(synchro : T); reintroduce; 
    destructor Destroy;override; 
end; 

implementation 
{ ScopedLock<T> } 

constructor ScopedLock<T>.Create(synchro: T); 
begin 
    inherited Create;; 
    sync_ := synchro; 
    sync_.Acquire; 
end; 

destructor ScopedLock<T>.Destroy; 
begin 
    sync_.Release; 
    inherited; 
end; 

{ Example } 
function Example.Foo: Integer; 
var 
    lock : ILock; 
begin 
    lock := ScopedLock<TCriticalSection>.Create(mySync); 
    // ... 
end; // mySync released ? 

Es funktioniert gut in einem einfachen Testfall, aber ist es sicher?

Answer 1

Ja, das ist sicher. Ihr Code

function Example.Foo: Integer; 
var 
    lock : ILock; 
begin 
    lock := ScopedLock<TCriticalSection>.Create(mySync); 
    // ... 
end; 

wie der folgenden Pseudo-Code kompiliert wird

function Example.Foo: Integer; 
var 
    lock : ILock; 
begin 
    lock := ScopedLock<TCriticalSection>.Create(mySync); 
    lock._AddRef; // ref count = 1 
    try 
// .. 
    finally 
    lock._Release; // ref count = 0, free lock object 
    end; 

Sie können sehen, dass, wenn Schloss var den Gültigkeitsbereiches verläßt seine ref Zahl verringert wird, wurde Null und Sperrobjekt wird automatisch zerstört.

Answer 2

Das einzige Problem ist, wenn die Funktion inline ist: Die lokale Variable, die die ILock-Referenz enthält, wird in den Bereich der Funktion hochgestuft, die die inline-Funktion aufruft. Das kann dazu führen, dass das Schloss länger als gewünscht funktioniert.

Auf der anderen Seite ist es nicht notwendig, eine Variable zu deklarieren, die die Schnittstellenreferenz enthält, wenn Sie eine Funktion schreiben (z. B. eine Klassenfunktion namens Create), die eine Schnittstellenreferenz (im Gegensatz zu einer Objektreferenz) zurückgibt. Der Compiler erstellt ein verstecktes Local, um den Rückgabewert zu erhalten (da alle verwalteten Typen wie Interfaces und Strings tatsächlich zurückgegeben werden, indem eine Ergebnisvariable übergeben wird). Dieses versteckte Lokal verhält sich genau wie das explizite Local.

Ich schrieb mehr darüber hier: http://blog.barrkel.com/2010/01/one-liner-raii-in-delphi.html

Answer 3

Ich sehe nicht, dass der Ansatz, den Sie eintreten, während richtig, eigentlich besser als gute alte try/finally. Sie haben eine klare und eindeutige Lösung gewählt und sie durch eine undurchsichtige und undurchsichtige ersetzt.

Echte Arbeit Delphi-Code ist voll von Try/Endlich und so sollte es ein natürliches Idiom sein. Ich kann den Nachteil des Schreibens nicht sehen: