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

[Zacherl]

Zitat von Thom:

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 von Thom:

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 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 von sx2008:

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 von Zacherl:

"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 von Furtbichler:

Zitat von sx2008:

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 von sx2008:

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

[Furtbichler]

Zitat von sx2008:

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.

[mjustin]

Zitat von Furtbichler:

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