Objekt als Rückgabe von Funktion - Wie elegant Freigabe regeln?

[Zacherl]

Hallo zusammen,

ich habe eine Funktion, welche ein Objekt erstellt, welches im weiteren Verlauf für eine unbestimmte Zeit innerhalb eines zweiten Threads verwendet wird. Die Funktion liefert das Objekt zusätzlich als Rückgabewert an den aufrufenden Benutzer zurück, damit dieser bestimmte Informationen (die der Thread setzt) mitverfolgen und auch per Methodenaufruf z.B. die Verarbeitung abbrechen kann.

Das Problem besteht nun in der Frage, wer das Objekt wieder freigeben soll. Geschieht dies nach seiner Verarbeitung im Thread, kann es sein, dass der Benutzer nachträglich versucht auf das nicht mehr existierende Objekt zuzugreifen. Gibt der Benutzer das Objekt frei, hat man das selbe Problem in umgekehrter Richtung.

Folgende Möglichkeiten sind mir eingefallen:

• :arrow: Ich gebe ein Interface zurück, welches von Delphi automatisch über _Release() freigegeben wird, sobald keine Referenz mehr existiert
• :arrow: Ich gebe in der Funktion ein Wrapper Objekt zurück, welches nach Art des Proxy Patterns auf das eigentliche Datenobjekt zugreift. Der Thread würde dann bei Freigabe des Datenobjekts auch ein Flag im Wrapper Objekt setzen, was dafür sorgt, dass der Benutzer nicht mehr auf bestimmte Werte und Methoden zugreifen kann

Welche dieser Methoden würdet ihr bevorzugen oder fällt euch vielleicht noch eine bessere Alternative ein?

Viele Grüße
Zacherl

[DeddyH]

Ist es denn unbedingt notwendig, dass die Funktion das Objekt erstellt? Ich tendiere eigentlich immer dazu, das Objekt außerhalb zu erstellen und dann als Parameter an die Routine zu übergeben, damit stellt sich das Problem erst gar nicht.

[Blup]

Interface deckt den Fall optimal ab, warum dann etwas neues erfinden.

[Lemmy]

Guten Morgen,

Instanz außerhalb erstellen (wer erstellt gibt frei) oder Interface verwenden, was wegen der geringeren Kopplung der Teile aber wohl der bessere Ansatz wäre.

[Mikkey]

Dass die Funktion hier das Objekt erstellt und zurückgibt, hat mMn mit der Problematik nichts zu tun.

Denkbar sind für die Freigabe beide Varianten, bei der zweiten sehe ich nur einen einigermaßen unüberschaubaren Verwaltungsaufwand und das Problem, dem Benutzer das ulkige Verhalten des Programms zu erklären.

Also ganz klar 1. Variante: wenn zwei oder mehr Threads das Objekt verwenden, darf es erst freigegeben werden, wenn der letzte damit fertig ist.

[mentaltec]

TObject mit Ref-Counter versehen, in einer Class TObjList merken
das Destroy dect den Refcounter und greift erst, wenn Refcounter == 0

oder so ähnlich, mfg

[Zacherl]

Zitat:

Zitat von DeddyH (Beitrag 1225943)

Ist es denn unbedingt notwendig, dass die Funktion das Objekt erstellt? Ich tendiere eigentlich immer dazu, das Objekt außerhalb zu erstellen und dann als Parameter an die Routine zu übergeben, damit stellt sich das Problem erst gar nicht.

In meinem Falle schon, da das Objekt innerhalb eines Threads verarbeitet wird. Ich kann die Instanz also nicht direkt nach Funktionsaufruf wieder freigeben.

Dann werde ich es mal mit der Interface Methode probieren. Dachte mir schon, dass dies die einfachste Lösung ist.

Danke an alle!

[Furtbichler]

Zitat:

Zitat von Zacherl (Beitrag 1226022)

In meinem Falle schon, da das Objekt innerhalb eines Threads verarbeitet wird. Ich kann die Instanz also nicht direkt nach Funktionsaufruf wieder freigeben.

Sollst Du ja nicht
Entweder ...
a)... die Architektur leicht abändern, um dem Paradigma: "Wer Dreck macht, räumt auch auf" gerecht zu werden, oder
b)... das Objekt einfach als Letztes im "Execute" freigeben oder
c)... das Objekt vom Threadersteller freigeben, sobald der Thread 'Fertig' meldet oder
d)... das Objekt gar nicht bzw. zum Programmende freigeben (wenn das sinnvoll ist)

Ich persönlich würde a) prüfen und wenn das nicht passt, c) umsetzen, da dann die Freigabe im Context des Objekterstellers geschieht.

[Zacherl]

Das ist alles leider nicht optimal. Ich versuche mal mein Problem etwas detaillierter darzustellen:
Ich habe einen Thread, welcher permanent von Programmstart bis zum Programmende läuft. Der Thread wartet im Hintergrund darauf, bis er einen oder mehrere Tasks zugewiesen bekommt und arbeitet diese dann ab. Die Tasks habe ich in einer Klasse gekapselt, welche einige Attribute wie z.b. den Progress und einige Methoden z.b. zum Abbrechen des Tasks besitzt.
Das Erstellen des Tasks passiert in der von mir genannten Funktion, welche das Objekt dann intern an den Thread weitergibt und zusätzlich dem aufrufenden Benutzer als Rückgabe liefert, damit man beispielsweise den Status des Tasks in einer Liste anzeigen lassen kann.

(a) scheidet für mich daher aus, weil ich nicht ohne Weiteres sagen kann, wer zuletzt auf das Objekt zugreift. Wenn ich es im Thread freigebe, könnte es sein, dass danach noch ein Zugriff von "außerhalb" erfolgt z.b. um die Daten in der Liste zu aktualiseren. Wenn ich es von Benutzerseite aus freigebe, könnte es passieren, dass der Thread noch nicht mit der Verarbeitung fertig ist.
(b) funktioniert in meinem Falle auch nicht, da der Thread ja zur kompletten Laufzeit des Programms aktiv ist
(d) hier würde mir recht schnell der Speicher vollaufen, da doch eine ganze Menge an Tasks verarbeitet werden

(c) würde funktionieren, allerdings ist das auch nicht wirklich "intuitiv" für den Anwender (Programmierer). Da müsste man in der Dokumentation ziemlich deutlich drauf hinweisen, dass die Freigabe des Objekts wirklich erst im entsprechenden Callback erfolgen darf und nicht direkt nach Funktionsaufruf.

Bin mir momentan unsicher, ob ich Methode (c) implementieren, oder es mit den Interfaces versuchen soll. Letztere haben allerdings auch gewisse Nachteile. Z.b. müsste ich dann auch in allen Callbacks das Interface anstelle des Objekts übergeben und auch hier in der Doku den Hinweis platzieren, dass die Instanz nur als Interface und nicht als konkretes Objekt gespeichert werden darf (weil sonst ja der Ref Counter Mechanismus nicht mehr greift), etc.

[Thom]

Zitat:

Zitat von Zacherl (Beitrag 1226100)

[...] dass die Instanz nur als Interface und nicht als konkretes Objekt gespeichert werden darf [...]

Das kannst Du recht effektiv verhindern, indem Du den Objektkonstruktor durch eine Klassenfunktion verdeckst:

Delphi-Quellcode:

class function Create: IMyInterface;
[...]

Damit bekommt niemand mehr Zugriff auf die eigentliche Objektinstanz (außer bei einem Cast

Delphi-Quellcode:

IInterface as TObject

) und damit den Destruktor.

[Zacherl]

Zitat:

Zitat von Thom (Beitrag 1226101)

Das kannst Du recht effektiv verhindern, indem Du den Objektkonstruktor durch eine Klassenfunktion verdeckst

Das ist jetzt bei mir nicht so das Problem, da die Objektinstanz ja sowieso innerhalb meiner Factory Funktion erzeugt wird. Als Rückgabetyp würde ich dann direkt das Interface angeben.

Probleme gibt es nur, wenn der Anwender auf die Idee kommt: "Hey, ich caste das Interface jetzt mal ganz schnell in die konkrete Klasse und speicher' mir das ganze in einer TList". In diesem Falle wird der Referenzcounter des Interfaces nämlich dekrementiert. Ist der Thread dann mit der Verarbeitung fertig, wird die Objektinstanz automatisch freigegeben und spätere Zugriffe auf das vom Anwender zwischengespeicherte Objekt laufen ins Leere.

[Thom]

Benutzt Du selbst diesen Cast? Falls nicht, kann man das auch generell für ein Objekt verhindern. Ich probier's gleich mal aus...

[Zacherl]

Zitat:

Zitat von Thom (Beitrag 1226103)

Benutzt Du selbst diesen Cast? Falls nicht, kann man das auch generell für ein Objekt verhindern. Ich probier's gleich mal aus...

Ich muss intern vermutlich schon casten, damit ich beispielsweise auf private Felder zugreifen kann. Ich könnte zwar den Cast in die konkrete Klasse verhindern, indem ich diese in meiner Unit im implementation Teil deklariere, aber selbst dann könnte man noch auf die Idee kommen das Interface in ein TObject oder ganz einfach in einen Pointer zu casten. Aber gut, das müsste ich halt entsprechend in meiner Dokumentation erwähnen.

Momentan hänge ich nur noch an der Frage, ob ich es tatsächlich über Interfaces realisiere oder die von Furtbichler vorgeschlagene Variante (c).

[Namenloser]

Wie wäre es mit einem Observer-Pattern? Das Objekt schickt dann bei Freigabe einfach eine entsprechende Nachricht an den Beobachter.

Skizze:

Delphi-Quellcode:

TTask = class;

ITaskObserver = interface
  procedure Observe(Task: TTask);

  procedure OnProgressChanged(Task: TTask; Progress: integer);
  procedure OnTaskDestroyed(Task: TTask);
end;

TTask = class{(TThread?)}
protected
  FObserver: ITaskObserver ;
  {...}
public
  {...}
  procedure Abort;
  constructor Create(Observer: ITaskObserver);
  destructor Destroy; override;
end;

TTaskFactory = class
  procedure CreateTask(Observer: ITaskObserver): TTask;
end;

implementation

constructor TTask.Create(Observer: ITaskObserver);
begin
  FObserver := Observer;
  FObserver.Observe(Self);
end;

destructor TTask.Destroy; override;
begin
  FObserver.OnTaskDestroyed(Self);
  inherited;
end;

procedure TTaskFactory.CreateTask(Observer: ITaskObserver): TTask;
begin
  Result := TTask.Create(Observer);
end;

Delphi-Quellcode:

TTaskController = class(TInterfacedObject, ITaskObserver)
protected
  FTasks: TList<TTask>;

  procedure Observe(Task: TTask);

  procedure OnProgressChanged(Task: TTask; Progress: integer);
  procedure OnTaskDestroyed(Task: TTask);
end;

procedure TTaskController.Observe(Task: TTask);
begin
  FTasks.Add(Task);
end;

procedure TTaskController.OnTaskDestroyed(Task: TTask);
begin
  FTasks.Remove(Task);
end;

In FTasks stehen dann eben jeweils die gültigen Tasks. Da könnte man z.B. dann TTask.Abort aufrufen.

Ist jetzt bewusst einfach gehalten, man könnte natürlich auch eine ganze Liste von Observern pro Objekt verwalten...

[sx2008]

Eigentlich ist es doch recht einfach:
man benötigt mehrere Instanzen des Data-Transfer-Objects.
Eine Instanz bleibt immer beim Threadobjekt; es wird im Konstruktor erzeugt und im Destruktor freigegeben.
(es ist ein Aggregatobjekt)
Weitere Instanzen leben ausserhalb des Threads und werden bei Bedarf erzeugt und wieder zerstört.
Mit der Methode

Delphi-Quellcode:

Assign

werden die Daten zwischen den Objekten kopiert.

Ablauf:
* lokales Data-Transfer-Objekt erzeugen
* besagte Funktion aufrufen (mit dem Objekt als Parameter) das das Objekt befüllt
* Threadobjekt erzeugen
* lokales Data-Transfer-Objekt auf das interne Data-Transfer-Objekt des Thread kopieren
* lokales Data-Transfer-Objekt freigeben
* Thread starten

Kein Stress mit Interfaces, keine Tricks, keine Unsicherheiten wer jetzt für das Objekt zuständig ist (also wer der Owner ist).

[Furtbichler]

Zitat:

Zitat von sx2008 (Beitrag 1226110)

Eigentlich ist es doch recht einfach:
man benötigt mehrere Instanzen des Data-Transfer-Objects.

Bisserl suboptimal bezüglich der Performance, würde ich sagen.

Wenn das Datenobjekt ganz genau weiß, wann es nicht mehr benötigt wird, dann lass es sich doch selbst zerstören. Du hast geschrieben, das das Teil sowohl in einem Thread, als auch von außerhalb angefasst wird. Der Thread weiss ja, wann er das Objekt nicht mehr benötigt. Das kann er dann ja auch sagen.

Und wenn Du 'außerhalb' auch weisst, wann Du das Teil nicht mehr benötigst, dann hat jedes Objekt eben einen 'Required'-Zähler (ähnlich dem Referenzzähler), Im Gegensatz zum RefCount zählst Du hier explizit. Das Objekt weiß, das es von zwei Systemen/Threads verwendet wird: Initial ist der Zähler also bei 2.

Wenn der Thread fertig ist, teilt er das dem Objekt mit (RequiredCount --), und wenn der Hauptthread oder wer auch immer fertig ist, macht er das gleiche.

Der Setter vom Zähler ruft Destroy auf, sobald RequiredCount = 0 ist.

Wer das Objekt behalten möchte, meldet dies per 'Require' an, welches einfach den Zähler hochzählt. Wenn man es nicht mehr benötigt, zählt man den Zähler runter.

Das ist ein einfache Regel, die selbst der dümmste Programmierer versteht.

Wobei ich das Interface verwenden würde, weil Grundkenntnisse sollte man dem Anwender schon zumuten

Zitat:

Zitat von Zacherl (Beitrag 1226102)

"Hey, ich caste das Interface jetzt mal ganz schnell in die konkrete Klasse und speicher' mir das ganze in einer TList".

Wird man ebensowenig abfangen können, wie "Hey, ich bügle mal 20 Nullen über die Instanz (mit MOVE), mal sehen, was passiert".

Wenn Du mit solchen Vollpfosten rechnen musst, dann bleibt Dir nur ein Manager und statt Objekten arbeitest Du mit einem Handle.

[sx2008]

Zitat:

Zitat von Furtbichler (Beitrag 1226117)

Zitat:

Zitat von sx2008 (Beitrag 1226110)

Eigentlich ist es doch recht einfach:
man benötigt mehrere Instanzen des Data-Transfer-Objects.

Bisserl suboptimal bezüglich der Performance, würde ich sagen.

Was kostest es schon mal eben ein Objekt mit 20 String-,Int- und Double-Properties zu kopieren?
So gut wie nichts.
Gerade bei Threads sollte man dessen Arbeitsdaten unabhängig und entkoppelt von allen anderen Threads halten.
Jeder Thread bekommt einfach eine Kopie der Daten die er zum Arbeiten braucht.
Ein Thread, der nur auf eigenen Daten arbeitet ist sicher gegen konkurrierende Zugriffe & Deadlocks.
(siehe Actor-Model)

Delphi hat nun mal keine automatische Speicherverwaltung (Garbage Collection).
Man kann versuchen diese Manko durch Referenzzählung auszugleichen wird dabei aber immer an Grenzen stossen und verschlechtert dabei die Lesbarkeit des Codes.

Ich würde bei Threads immer den Weg gehen die Daten zu kopieren als mich mit Interfaces rumzuschlagen oder gar eine eigene Referenzzählung einzubauen.

[Meflin]

Zitat:

Zitat von sx2008 (Beitrag 1226122)

Was kostest es schon mal eben ein Objekt mit 20 String-,Int- und Double-Properties zu kopieren?
So gut wie nichts.

Völlig richtig, vor allem wenn das ganze - wie es sein sollte - als Copy on Write implementiert ist. Ob Delphi da allerdings was im Angebot hat, weiß ich nicht :stupid:

[Furtbichler]

Zitat:

Zitat von sx2008 (Beitrag 1226122)

Was kostest es schon mal eben ein Objekt mit 20 String-,Int- und Double-Properties zu kopieren?
So gut wie nichts.

Wenn ich das Ganze 3x am Tag mache, dann ist das zu vernachlässigen. In zeitkritischen Anwendungen würde ich nicht so leichtfertig damit umgehen. Zumal ein Objekt bzw. dessen Daten auch mal größer werden können und dann ist so ein Ansatz einfach Quark. Bei kleinen Objekten fällt das aber nicht so sehr ins Gewicht, da hast Du sicherlich Recht. Aber wenn wir uns über 'best practises' unterhalten, dann ignorieren wir Sonderfälle wie 'kleine Datenmengen' mal lieber bzw. listen sie explizit auf.

Zitat:

Ein Thread, der nur auf eigenen Daten arbeitet ist sicher gegen konkurrierende Zugriffe & Deadlocks.

Nun ja, eine Critical Section schafft sichere und robuste Abhilfe.

Grundsätzlich: Wenn die Daten nur in eine Richtung gehen (was sie hier nicht tun, siehe Eingangspost), dann wäre es sicherlich am einfachsten, die Daten zu kopieren.

Aber hier scheinen Daten/Feedback aus dem Thread heraus verarbeitet werden zu müssen.... Hmm, ich mach das eigentlich automatisch immer so, das ich die Parameter des Threads im Konstruktor übergebe (so wie Du das machen würdest, also 'copy') und etwaiges Feedback über synchronisierende Eigenschaften (Critical Sections) oder Synchronize-Aufrufe (Events) der Außenwelt zur Verfügung stelle.

Ich denke, das ist dann wirklich die bessere (=robustere) Vorgehensweise. :thumb:

[mjustin]

Zitat:

Zitat von Furtbichler (Beitrag 1226126)

Hmm, ich mach das eigentlich automatisch immer so, das ich die Parameter des Threads im Konstruktor übergebe (so wie Du das machen würdest, also 'copy') und etwaiges Feedback über synchronisierende Eigenschaften (Critical Sections) oder Synchronize-Aufrufe (Events) der Außenwelt zur Verfügung stelle.

Wobei Synchronize zur Hauptthreadsynchronisation allerdings innerhalb von Nicht-VCL Anwendungen - Diensten, ISAPI Extensions oder Konsolenanwendungen - nicht (oder nur mit entsprechendem Zusatzaufwand) funktioniert, sondern zu Deadlocks führt ... eine Herausforderung für Entwickler von allgemein verwendbaren Bibliotheken. Aber das ist schon fast einen eigenen Thread wert ;)

[Zacherl]

Der Copy Ansatz ist ja in etwa ähnlich zu Methode "2" aus meinem ersten Post. Nur dass ich die Daten in meiner Proxy Klasse nur "on demand" (sobald von außen jemand lesen will) kopieren würde und nicht bei jeder Aktualisierung (der Thread kann durchaus mehrere 1000 Aktualisierungen pro Sekunde und in verschiedenen Tasks erzeugen, da die Tasks nicht strikt nacheinander, sondern jeweils in kleinen Portionen per Round Robin abgearbeitet werden).

Zitat:

Zitat von Furtbichler (Beitrag 1226117)

Wobei ich das Interface verwenden würde, weil Grundkenntnisse sollte man dem Anwender schon zumuten

Bisher tendiere ich auch immer noch zu den Interfaces. Die meisten Daten werden vom Thread geschrieben und können nach außen hin nur gelesen werden, weshalb sich hier die Synchronisierung sowieso erledigt. Bei den wenigen anderen Werten (eigentlich nur ein Wert, der steuert, ob der Task abgebrochen oder angehalten werden soll), die in beide Richtungen auch geschrieben werden können, sichere ich dann einfach den Setter mit einer Critical Section ab. Den Getter brauche ich ja theoretisch nicht schützen, da es fürs Monitoring nicht von Relevanz ist, ob der Wert sich jetzt ein paar Milisekunden später erst aktualisiert.