AW: Objekt als Rückgabe von Funktion - Wie elegant Freigabe regeln?
Zitat:
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. |
AW: Objekt als Rückgabe von Funktion - Wie elegant Freigabe regeln?
Benutzt Du selbst diesen Cast? Falls nicht, kann man das auch generell für ein Objekt verhindern. Ich probier's gleich mal aus...
|
AW: Objekt als Rückgabe von Funktion - Wie elegant Freigabe regeln?
Zitat:
Momentan hänge ich nur noch an der Frage, ob ich es tatsächlich über Interfaces realisiere oder die von Furtbichler vorgeschlagene Variante (c). |
AW: Objekt als Rückgabe von Funktion - Wie elegant Freigabe regeln?
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:
In FTasks stehen dann eben jeweils die gültigen Tasks. Da könnte man z.B. dann TTask.Abort aufrufen.
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; Ist jetzt bewusst einfach gehalten, man könnte natürlich auch eine ganze Liste von Observern pro Objekt verwalten... |
AW: Objekt als Rückgabe von Funktion - Wie elegant Freigabe regeln?
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:
werden die Daten zwischen den Objekten kopiert.
Assign
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). |
AW: Objekt als Rückgabe von Funktion - Wie elegant Freigabe regeln?
Zitat:
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:
Wenn Du mit solchen Vollpfosten rechnen musst, dann bleibt Dir nur ein Manager und statt Objekten arbeitest Du mit einem Handle. |
AW: Objekt als Rückgabe von Funktion - Wie elegant Freigabe regeln?
Zitat:
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. |
AW: Objekt als Rückgabe von Funktion - Wie elegant Freigabe regeln?
Zitat:
|
AW: Objekt als Rückgabe von Funktion - Wie elegant Freigabe regeln?
Zitat:
Zitat:
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: |
AW: Objekt als Rückgabe von Funktion - Wie elegant Freigabe regeln?
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 18:37 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz