Intelligente Objekte - automatische Freigabe von Referenzen

[himitsu]

Ich würde das Ding, ganz einfach nur als Strohdoofes und ganz normales Interface auslegen.

Es wird freigegeben wenn alle Referenzen auf nil stehen
und es verändert nicht von innen her seine Referenzen.

Wenn der Punkt nicht mehr sichtbar sein soll, wird er nur aus den Googleobjekten/-listen rausgenommen und maximal in den Punkt-Objekt noch ein Flag gesetzt "ich bin gelöscht", welches man auswerten könnte, wenn doch noch jemand mal auf eine Methode des Objektes zugreifen will, obwohl es "eigentlich" nicht mehr existiert, bzw. nicht mehr angezeigt wird.




Problem: Man markiert eine Speicherposition 'ner lokalen Variable, die Prozedur wurde schon verlassen und Variable existiert nicht mehr.
Oder man markiert ein Feld in einem Objekt, gibt das Objekt frei und vergist die Markierung zu entfernen.
Wird jetzt das Objekt freigegeben und werden dann alle markierten Referenzen auf nil gesetzt, dann würden "falsche" Speicherbereiche überschrieben.

Ich wünsche dem armen Kerl/Mädl schonmal viel Spaß, welche(r) diesen Bug dann suchen darf, wo sich unvorhersehbar irgendwo etwas verändert, welches quasi einem Bufferoverrun ähnelt.

[Stevie]

Sowas passiert halt, wenn man Code aus einer GC Sprache 1 zu 1 in Delphi übersetzt

[himitsu]

In Delphi haben wir ja auch sowas wie einen GC und das nennt sich Interface (String und dyn. Array gehört auch mit dazu).

[Stevie]

Zitat von himitsu:

In Delphi haben wir ja auch sowas wie einen GC und das nennt sich Interface (String und dyn. Array gehört auch mit dazu).

Interfaces und andere managed data types sind referenzgezählt. Da ist noch ein himmelweiter Unterschied zu einem GC.

[Thom]

Vielen Dank für alle Beiträge! Ich muß zugeben: Jeder hat in etwa das geschrieben, was ich von ihm erwartet habe.

Zuerst muß ich Stevie Recht geben: Diese Probleme entstehen, wenn man eine untypisierte GC Sprache nach Delphi umsetzen möchte... Aber bei diesem Ansatz will ich bleiben und deshalb soll und muß aller Verwaltungsaufwand für den Anwender (des Frameworks) hinter den Kulissen bleiben. Der Programmierer soll sich voll und ganz auf die Umsetzung seiner Ideen konzentrieren können. Deshalb sollen auch keine zusätzlichen Aufrufe notwendig sein.


@Furtbichler:

Vielen Dank für Deine Antwort!
Deine Sorge besteht darin, daß irgendwelche fremden Programmteile Deinem eigenen Code "dazwischen pfuschen". Dieses Gefühl ist bei Multithreadanwendungen vollkommen berechtigt. Leider zeugt das aber auch davon, daß Du Dich - höchstwahrscheinlich - kein einziges mal mit dem von mir angesprochenen Framework beschäftigt hat. Das soll kein Vorwurf sein - schließlich ist das auch keine Pflicht. Hättest Du das aber gemacht, wüßtest Du, das es gar nicht threadsave sein muß, da die JScript-Engine von Microsoft nicht multithreadsicher ist.
Spontan auftretende nil-Zeiger der Art

Delphi-Quellcode:

if assigned(FMyMarker) then
begin
  //<- ist hier plötzlich weg
  FMyMarker. ...;
end;

können also gar nicht auftreten. Auch alle asynchronen JScript-Callbacks laufen im Context des Hauptthreads.

Wie threadsicher ein Interface ist, hängt von seiner Implementation ab, nicht von seiner Definition. Wie das INotify.Free umgesetzt wird - ob als direkte, unmittelbare Freigabe in Singlethread-Anwendungen oder "angemeldet" und zeitlich verzögert-, hängt ganz von den Erfordernissen ab.
Ich gebe Dir aber vollkommen Recht: In Multithreadanwendungen muß ein höherer Verwaltungsaufwand betrieben werden, als in einem Programm, in dem nur ein Thread (in der Regel der Hauptthread) auf den Datenbestand zugreift. Das vorgestelle Interface wurde von mir primär für das Framework entworfen, um die automatisch Speicherverwaltung von Delphi über Referenzzähler nutzen zu können ohne die Nachteile eines TInterfacedObject's. Für eine darüber hinausgehende Anwendung sind ganz bestimmt noch weitere Aspekte zu berücksichtigen.


@himitsu:

Das vorgestellte Interface ist von IInterface abgeleitet. Deshalb beinhaltet das implementierende Objekt INotifyObjekt auch eine Referenzzählung mit _AddRef und _Release. Mir geht es aber darum, ein referenzgezähltes Objekt explizit freigeben zu können, ohne daß es zu Zugriffsverletzungen über andere, parallel existierende Referenzen kommt.
Die Registrierung/Deregistrierung lokaler (Interface-)Variablen auf dem Stack erfolgt automatisch. Das bedeutet, daß nach Verlassen der Methode die Referenz wieder entfernt wird. Es kann also nicht vorkommen,

Delphi-Quellcode:

type
  TForm1 = class([...])
    [...]
  private
    FMyNotify: INotify;
  end;

procedure TForm1.Button1Click(Sender: TObject);
var
  o: INotify;
begin
  o:=TNotifyObject.Create;
  FMyNotify:=o;
end;

procedure TForm1.Button2Click(Sender: TObject);
begin
  FMyNotify:=nil;
end;

daß jetzt, bei Freigabe des Objektes in Button2Click, die (Stack-)Variable "o" auf nil gesetzt wird. "o" wird bei der Zuweisung in Button1Click registriert und nach Beendigung der Methode vom Compiler auf nil gesetzt sowie über INotify.RemoveRef(o) abgemeldet. Alles ganz einfach und vollautomatisch. Ich will das mal "managed Reference" nennen.
Anders sieht es natürlich bei einer expliziten Registrierung einer Variablen über AddRef() aus - also einer "unmanaged Reference". Hier muß natürlich dafür gesorgt werden, daß es nicht zu Zugriffsverletzungen kommt. Ich würde es einmal vergleichen mit dem Aufruf eines xxx.Lock: Wird anschließend das xxx.Unlock vergessen, gibt es logischerweise Probleme. Das hat aber nichts mit Fehlern im Konzept, sondern mit der Vergeßlichkeit des Programmieres zu tun. Das von mir vorgestelle Interface kann die Arbeit wesentlich erleichtern - ist aber keine Lizenz zum Abschalten des eigenen Gehirns.

Meine Umsetztung funktioniert in den bisherigen Tests sehr zuverlässig.


@Patito:

Hast Du auch irgend etwas Sachliches zu dem Thema beitragen oder beschränkst Du Dich immer auf platte Statements?

[Patito]

Zitat von Thom:

Meine Umsetztung funktioniert in den bisherigen Tests sehr zuverlässig.

@Patito:

Hast Du auch irgend etwas Sachliches zu dem Thema beitragen oder beschränkst Du Dich immer auf platte Statements?

Meine Aussagen sind folgende:
1. Dass es zumindest fragwürdig ist Dinge auf Design-Fehlern aufzubauen.
2. Dass Interfaces nicht für das Ref-Counting da sind. (Interfaces sind Schnittstellen)

Mag sein, dass Dir das nicht gefällt. Insgesamt hat es mit Deiner Situation aber nur insofern zu
tun, dass ich Deinen Tricks erst mal wenig vertraue.

Ich glaube nicht, dass Du das ganze richtig anpackst. Per Observer ein paar Referenzen zu eleminieren ist zwar
gute Technik, aber in einer Anwendung verteilte Referenzen im User-Code lassen sich nicht so einfach alle auf nil setzen.
Ich vermute mal, dass Du da in Deinen Tests einem Trick des Optimizers aufgesessen bist...

Delphi-Quellcode:

procedure TForm1.Button4Click(Sender: TObject);
var
  o1, o2: INotifyObject;
begin
  o1:=TNotifyObject.Create;
  o2:=o1;
  o1.Free;
  //sowohl o1 als auch o2 sind jetzt nil!!!
end;

Wäre interessant wenn Du die Referenzen etwas weiter weg verteilst.
(Feld in irgendeiner Klasse, auf dem Stack als Rückgabewert einer Funktion, ...).
Ich glaube, dass Du niemals alle auf nil gesetzt bekommen wirst.

So ein zwischen-Interface bringt reichlich wenig. Anstatt auf Interface-Referenzen aufpassen zu müssen
muss man jetzt eben genauso auf die Referenzen auf die INotifyObject-Interfaces aufpassen - damit hat man
praktisch nichts gewonnen.

Das ganze geht mit Objekt-Handles wesentlich einfacher und ohne 360-Grad Pirouette.

[Patito]

Zitat von himitsu:

In Delphi haben wir ja auch sowas wie einen GC und das nennt sich Interface (String und dyn. Array gehört auch mit dazu).

Wobei ich hier anzumerken hätte, dass es sich beim Referen-Zähler von Interfaces hauptsächlich um einen Design-Fehler von Delphi handelt. (Die Designer hatten damals wohl zu viel COM im Kopf).
Für COM mag das zwar einen gewissen Sinn haben, aber Interfaces in einer objektorientierten Sprache immer per Ref-Count zu verwalten ist im allgemeinen grober Unfug.

Auf Design-Fehlern dann irgendwelche Framework-Spezialitäten aufzubauen halte ich für äußerst fragwürdig...

[Iwo Asnet]

Blöde Frage: Woher weiß ein GC, wann ein Objekt nicht mehr benötigt wird?
Nur durch den Scope? Oder wird nicht auch hier eine Art Referenzzähler verwendet?

Außerdem verstehe ich nicht, was an Referenzzählern grober Unfug sein soll. Ich dachte immer, das die Strings genauso verwaltet werden.

In diesem Fall wäre das zumindest eine sichere Alternative.

[himitsu]

Der GC merkt sich nicht nur die Anzahl der Referenzen, sondern auch die Addressen der Referenzen selber ... er weiß also wo alle Referenzen liegen.

In diesem Sinne ist eine "billige" Referenzzählung wesentlich einfacher.
> nur ein Integer, anstatt einer rießigen Liste

Und nein, bei Interfaces müssen die referenzen gezählt werden, sonst weiß man ja nicht wann es keine mehr gibt, um das Interface dann zreitugeben.

Aber ja, auch interfaces kann man ohne Referenzzählung nutzen.
Siehe TComponent. Denn dieses kann man auch über ein Interface ansprechen, allerdings ohne Zählung, da dort das Objekt nicht über die Interfacereferenzen freigegeben wird, sonder über Free, denn sonst würde das Objekt schon gelöscht, wenn die letzte Interfacereferenz weg ist, aber irgendwo könnten dann "ungültige" Objektreferenzen rumliegen.

[neo4a]

Zitat von Patito:

Auf Design-Fehlern dann irgendwelche Framework-Spezialitäten aufzubauen halte ich für äußerst fragwürdig...

Und deshalb machst Du jetzt genau was? Drei Punkte!?

Das Konzept beim Einsatz von Interfaces ist schon etwas vielschichtiger, so dass der Aspekt des RefCounting nur einer von vielen ist.