spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Der Algorithmus, nach dem der GC arbeitet, ist sehr wohl deterministisch. Egal wie man es dreht und wendet. Es entsteht natürlich der Eindruck, dass es nicht deterministisch ist, weil es eine Blackbox darstellt, die man selbst nicht durchblickt.

Ninja Antworter.
Also sagst du sozusagen, dass der Wikipedia Eintrag unrecht hat, oder dass dieser was völlig anderes meint? Für mich liest sich das so, als würde er die Aussage von Spieleprogrammierer (und meine eigene) damit untermauern.

Zitat von »BlueCobold«

Nein. Denn es ist per Destruktor gelöst.

Was ist "per Destruktor" gelöst? Einen Destruktor gibt es im engeren Sinn eigentlich nicht, weil der Aufruf nicht deterministisch ist.

Sicher ist, wann der Garbage Collector läuft, lässt sich praktisch betrachtet nicht vorhersagen. Deshalb kann man es als nicht deterministisch betrachten und hängt von der Implementierung und Faktoren, wie zum Beispiel wieviel Leistung oder Speicher anderswo verbraucht wird, ab. Man könnte argumentieren, dass "wieviel Leistung und Speicher verbraucht wird" möglicherweise natürlich in einer Implementierung selbst insgesamt betrachtet(ein Programmierer betrachtet normalerweise bloß einzelne Komponenten) deterministisch sein könnte. Praktisch aber höchst wahrscheinlich nicht mal dann, weil, wann der GC läuft zum Beispiel mit guter Wahrscheinlichkeit auch vom Thread-Scheduling und Nebeneffekten, das selbst ebenfalls nicht deterministisch ist, abhängt.

Auch wenn Microsoft selbst das Konzept "Destruktor" nennt, schreiben sie:

Zitat von »http://msdn.microsoft.com/en-us/library/system.object.finalize(v=vs.110).aspx«

... garbage collection is non-deterministic, you do not know precisely when the garbage collector performs finalization.

Zitat von »http://msdn.microsoft.com/de-de/library/66x5fx1b.aspx«

The programmer has no control over when the destructor is called because this is determined by the garbage collector.

Boar. Jungs, ihr müsst auch lesen. Nochmal schreibe ich es nicht, es steht ja schon alles oben und auf der vorherigen Seite. Ihr müsstet als Programmierer doch wissen wie wichtig es ist verschiedene Dinge korrekt zu analysieren und zu differenzieren. Wenn Ihr das nicht könnt, solltet Ihr es üben.

Ich denke das Topic hat seinen Zenit hiermit auch weit überschritten und was jetzt noch kommen könnte wissen wir alle.

Zitat von »Spiele Programmierer«

Zitat von »http://msdn.microsoft.com/en-us/library/system.object.finalize(v=vs.110).aspx«

... garbage collection is non-deterministic, you do not know precisely when the garbage collector performs finalization.

Zitat von »http://msdn.microsoft.com/de-de/library/66x5fx1b.aspx«

The programmer has no control over when the destructor is called because this is determined by the garbage collector.

Irgendwie widersprechen sich die beiden Abschnitte ein wenig. Der erste sagt, es wäre nicht deterministisch, der zweite sagt, der Garbage Collector bestimmt den Zeitpunkt, wodurch es wieder deterministisch ist.

Ich gehe davon aus, dass "deterministisch" nicht unbedingt heißt, dass man selbst vorhersagen treffen kann, sondern eher, dass es nicht zufällig ist. die Pseudo-Zufallszahlen, die einem ein Rechner ausspuckt, sind bspw. ebenfalls deterministisch. Es ist zwar für einen Programmierer schwer vorherzusagen, zu welchem Zeitpunkt der Seed aus der aktuellen Zeit ausgelesen wird (sofern er daher bezogen wird), dennoch wird die Generierung der Zahlen mit Hilfe eines Algorithmus durchgeführt, der bei gleichen Eingaben (gleicher Seed und gleiche Aufrufe) auch die gleichen Werte liefert.
Andernfalls könnte man auch sagen, dass die Datentypgrößen in C++ nicht deterministisch sind, weil sie sich von Plattform zu Plattform unterscheiden können. (Woher der Compiler dann aber die richtigen Werte erraten kann... )

Abgesehen davon ist für die Ausgangsfrage nicht relevant, ob der Zeitpunkt des Destruktor-/Finalisiereraufrufs deterministisch ist oder nicht. Für ihn ist relevant, dass er den Aufruf weder direkt (in C++ mit delete) noch indirekt (in C++ über Smart Pointer), ohne irgendwelche merkwürdigen Hilfskonstrukte (überschreiben der Referenz und befüllen des Speichers mit vielen Objekten) zu verwenden, auslösen kann. Deshalb gibt es eben, wie bereits beschrieben, dieses Interface.

Danke, Sacaldur, einer hat verstanden, was ich meine.

Zitat

Irgendwie widersprechen sich die beiden Abschnitte ein wenig. Der erste sagt, es wäre nicht deterministisch, der zweite sagt, der Garbage Collector bestimmt den Zeitpunkt, wodurch es wieder deterministisch ist.

Eigentlich nicht: Der Erste sagt aus, dass der Zeitpunkt Garbage Collection nicht deterministisch ist, der Zweite sagt aus, dass der Aufruf des "Finalizer"s vom Garbage Collector durchgeführt wird. Darauf folgt dass der "Finalizer" zu einem nicht deterministischen Zeitpunkt aufgerufen wird.

Man kann davon ausgehen, dass der Garbage Collector tatsächlich nicht deterministisch ist und sich bei jedem Programmlauf sich anders verhält. (Aber ja, die genaue Auslegung wie weit es noch vorhersagbar ist spielt keine Rolle für die ursprüngliche Themenfrage)

Die sowohl im C# Sprachstandard als auch der CLI Spezifikaiton verwendete, offizielle Bezeichnung ist Finalizer und nicht Destruktor, eben um den hier diskutierten, sehr wesentlichen Unterschied widerzuspiegeln und Verwirrung zu vermeiden; in C++/CLI gibt es beispielsweise sowohl Finalizer als auch Destruktoren und bestimmte Arten von Klassen können dort beides haben (was effektiv dazu führt, dass der Compiler den Code für IDisposable schreibt) ...

Der Garbage Collector selbst ist natürlich auch nur ein deterministischer Algorithmus der auf einer deterministischen Maschine ausgeführt wird. Auch wenn ein konkreter PC als Ganzes aus unserer Sicht also selbstverständlich immer ein deterministisches System ist: Aus Sicht des Programmes ist die Lebensdauer von Objekten im Falle von Garbage Collection gewissermaßen tatsächlich nicht deterministisch, denn nach den Regeln der Sprache allein ist sie (per Definition) nicht vorhersehbar...

Anyway, diese Diskussion führt früher oder später unweigerlich an einen Punkt, an dem man nur noch philosophieren kann und ist für die Frage hier völlig irrelevant...

Das eigentliche Problem ist, dass die Lebensdauer von Objekten relativ zueinander in Sprachen mit Garbage Collection in der Regel nicht definiert ist. In jedem C++ Programm z.B. ist dagegen nach den Regeln der Sprache ganz klar definiert, wie die Lebensdauern sämtlicher Objekte sich relativ zueinander verhalten.

Bei der Arbeit mit verschiedensten Arten von Ressourcen, ist es von fundamentaler Bedeutung, eine gewisse Ordnung bei der Allokation, Verwendung und Freigabe der verwendeten Ressourcen einzuhalten. Beispielsweise, weil es sich um knappe Ressourcen handelt, weil anderen Prozessen sonst unnötigerweise der Zugriff auf eigentlich nichtmehr benötigte Ressourcen vorenthalten bliebe oder gar, weil es sonst zu Deadlocks kommen könnte. In Sprachen mit klar definierten Objektlebensdauern, kann die Allokation, Verwendung und Freigabe von Ressourcen einfach an die Lebensdauer von Objekten geknüpft (RAII) und damit automatisch eine bestimmte Ordnung garantiert werden. In Sprachen ohne klar definierte Objektlebensdauern geht das nicht (weil kein Verlass darauf ist, wann genau Objekte zerstört werden, auch wenn die konkrete Entscheidung, ein konkretes Objekt zu zerstören, auf einer konkreten Maschine unter einem konkreten Betriebssystem mit einer konkreten Version der Sprachruntime, je nachdem, wann die Maus zuletzt bewegt wurde, bei gegebener Raumtemperatur, Luftfeuchtigkeit und der jeweiligen momentanen Stärke des Sonnenwindes am entsprechenden Ort deterministisch gefällt wird) und eine passende Ordnung muss manuell (eben z.B. durch Dinge wie IDisposable) sichergestellt werden.

Die Moral von der Geschicht: In den meisten Sprachen mit Garbage Collection wird einem zwar die Verwaltung einer ganz bestimmten Art von Ressource, nämlich von Heap Objekten, abgenommen, gleichzeitig wird man aber zur manuellen Verwaltung von sämtlichen anderen Arten von Ressourcen gezwungen...

q.e.d., dot

Zitat von »Julién«

Ich arbeite gerade mit SharpDX. So ziemlich jedes Objekt, das ich hier habe muss mit IDisposeable aufgeräumt werden. Wieso eigentlich?
Wieso wird das ganze nicht einfach per Destruktor gelöst?

Gruß Julién

Sei froh das die COM Objekte von DirectX free threaded und nicht single apartment threaded sind, sonst käme noch manches mehr zu den bereits genannten Fallstricken hinzu und es IDisposable würde noch wichtiger werden ...