spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich will den ursprünglichen Thread nicht zu sehr aus der Bahn werfen, deshalb sammle und kommentiere ich hier parallel. Ich lade jeden ein, hier mit über den Tellerrand zu schauen. Nachfragen und Mitmachen ausdrücklich erlaubt.

Ressourcenverwaltung in "modernen" Sprachen wie C# und Java

Zitat von »De_Struktor«

ja, dann muss Player aber IDisposable implementieren, denn sonst kann ich die Methode knicken

Zitat von »dot«

Willkommen in der wunderbaren Welt der Garbage Collection, wo jegliches Ressourcenmanagement zum Alptraum wird...

Zitat von »BlueCobold«

Ich wüsste ehrlich gesagt nicht wieso eine Spieler-Klasse disposable sein sollte. Das Teil sollte keine externen unmanaged Ressourcen verwalten.

BlueCobold hat Resource Management (abseits von Memory Management) in Managed-Umgebung auf den Punkt gebracht: Zunächst ist es ist eine Aufgabe, die von Hand erledigt werden muss. In dieser Hinsicht fällt man mit den gängigen "modernen Sprachen" leider weiterhin zurück auf mittelalterliches C-Niveau. Da es aber insbesondere nicht die Aufgabe einer jeden Einzelklasse (-> Spielerklasse) sein kann, bleibt als sinnvolle Lösung letztlich nur die Übertragung dieser Aufgabe an einen verantwortlichen Dritten. Dieser hat dann meist die Gestalt eines "zentralen" (!= globalen) Managers pro Ressourcentyp.

Zitat von »Sylence«

Wobei man vielleicht noch erwähnen sollte: Das sieht ja nach XNA aus und da lädst du deine Texturen ja über den ContentManager. Dieser disposed schon von sich aus alle Objekte, die er geladen hat, wenn er selbst disposed wird.

Ein solcher Manager übernimmt dann die kollektive Verwaltung einer bestimmten Ressourcenart nach bestem Wissen und Gewissen. Wohlgemerkt kann dies ganz analog zu C auch ohne Weiteres in "dangling pointers" oder besser "dangling references" auf freigegebene Ressourcen enden, wenn der Entwickler die Lebensdauer von Ressourcen nicht sorgsam durchdenkt.

Ressourcenverwaltung in C++

C++ ermöglicht über die automatisierte und deterministische Zerstörung von Objekten "auf dem Stack" (automatic storage duration) die Implementierung von automatisierter Referenzzählung und Zerstörung beliebiger Ressourcen. Die aktuelle Standardbibliothek bietet diese Funktionalität analog zu managed Sprachen für die Ressource Speicher fertig implementiert (siehe unique_ptr und shared_ptr); mit etwas C++-Erfahrung lassen sich analoge Klassen für beliebige Ressourcentypen implementieren. Leider ist meine Erfahrung, dass sich die Leute angesichts der großen Vielfalt von speziellen Memberfunktionen (Kopier- und Verschiebungskonstruktor, Zuweisungs- und Verschiebungsoperator) häufig noch schwer tun, solche Klassen auf Anhieb vollständig und korrekt zu implementieren. Prinzipiell bietet C++ im Gegensatz zu oben genannten Sprachen jedoch einen einigermaßen einfachen Mechanismus, Ressourcenverwaltung für beliebige Ressourcentypen lückenlos zu automatisieren.

Ressourcenverwaltung in "modernen" Sprachen 2.0?

Interessant ist nun, dass man nicht zwangsweise den C++-Weg gehen müsste. Wenn oben genannte Sprachen nicht so geschlossen wären, wäre das Anbieten einer umfassenden Schnittstelle zur Erweiterung der Garbage Collection eventuell ebenfalls eine gangbare Lösung. Dann könnten die angesprochenen, ohnehin bereits notwendigen Klassen zur kollektiven Ressourcenverwaltung ("Manager") Gebrauch von GC-Information machen. Insbesondere die Erreichbarkeit von Objekten über Referenzen, die ein GC für Speicherverwaltung ohnehin schon kennt, ließe sich dann mit ressourcenspezifischen Parametern, wie z.B. der aktuellen Verfügbarkeit der verwalteten Ressource, kombinieren, um den entsprechenden Ressourcentyp robust zu verwalten. Auch andere Größen, wie die Zeit seit der letzten Benutzung, wären von Interesse, um analog zu bestehenden Speicher-GCs sinnvolle Eviction-Strategien für andere Ressourcen zu ermöglichen.

Ich kenne im Moment keine Sprache, die diesen Weg geht, und so klafft bei der Entwicklung mit gängigen "modernen" Sprachen eine unbegreifliche Lücke in der Ressourcenverwaltung.

Die Schwierigkeiten einer solchen Schnittstelle liegen auf der Hand: GCs laufen typischerweise asynchron, sie sollten den normalen Programmfluss möglichst wenig beeinträchtigen. Angesichts der programmiertechnischen Schwerigkeiten, die schon bei der Verwaltung einzelner Ressourcen in C++ erkennbar sind, erscheint die Implementierung einer leichtgewichtigen asynchronen Verwaltung eines Ressourcenkollektivs keine Aufgabe, der der durchschnittliche Java-/C#-Programmierer gewachsen sein könnte. Eine interessante Frage wäre nun, ob man die Schnittstelle eines solch erweiterbaren GC-Frameworks so bombensicher hinbekommt, dass der ressourcenspezifische Code nicht mehr allzu viel Spielraum für einen systematischen Fehler abseits der Eigenheiten der jeweils verwalteten Ressourcenart lässt.

Vielleicht hat ja irgendjemand hier irgendwann mal die Gelegenheit, in diese Richtung zu forschen; vielleicht wird sogar bereits Forschung betrieben, Hinweise willkommen.

Kurzer Nachtrag: Ich habe mich gerade erinnert, dass ich in Java schonmal gezwungenermaßen PhantomReferences nutzen musste, um die Unerreichbarkeit von memory-mapped Files zu prüfen (die in ihrer Standardimplementierung offenbar auch nur halbherzigen Gebrauch vom Speicher-GC Gebrauch machen, sehr unangenehm). Damit ist die Erreichbarkeitsinformation tatsächlich verfügbar, beliebige Referenzen (-> Unmanaged Resources) lassen sich an eine Queue binden, die so lange blockiert, bis die jeweiligen Objekte zum Aufräumen eingereiht werden.

Das Starten eines eigenen Threads zu diesem Zweck bietet sicher noch einiges an Fehlerpotential, aber zumindest der Ansatz ist da. Weitaus problematischer erscheint mir im Moment, dass ich keine konkreten Angaben zum Zeitpunkt des Aufräumens finden kann. Dies legt den Verdacht nahe, dass wir es hier mit ganz normalem Speicher-GC-Verhalten zu tun haben, also Einreihung in die Queue NACH Auswahl durch den Speicher-GC. Solange alle Aufräumarbeiten an Speicherverwaltungsheuristiken gebunden sind, können andere Ressourcen nicht zuverlässig entsprechend eigener Constraints verwaltet werden. Das werdet ihr spätestens dann merken, wenn ihr in Java mal mit großen mem-mapped Files arbeitet und euch permanent der Adressraum überläuft, weil der GC eine Freigabe des Mappings in diesem Moment noch nicht in Erwägung zieht.

Eine weitere Anforderung an ein umfassendes GC-Framework wäre wohl die Aktivierbarkeit von deterministischer Zerstörung für bestimmte "wertvolle Ressourcen". Es ist ja nicht so, dass GCs zwangsweise so undeterministisch laufen müssen, wie sie das momentan praktisch immer tun. Analog zu deterministischer Referenzzählung, wie sie sich z.B. leicht in C++ implementieren lässt, ließe sich auch deterministische GC-Auslösung implementieren; im Grunde dann normale deterministische Referenzzählung erweitert um eine robuste Erreichbarkeitsanalyse, welche das Problem von Referenzzykeln löst.

Zitat von »Legend«

Für C# könnte ich mir einen Lösungsansatz vorstellen, der eigentlich sehr leicht für Microsoft zu implementieren scheint, aber leider nicht umgesetzt ist: Man könnte bestimmt viel machen, wenn structs einen Finalizer haben könnten. Dieser sollte sofort aufgerufen werden, wenn die Variable von Typ der Struct den Scope verlässt. Leider gibt es das nicht.

Ja, das wäre eine deterministische Lösung analog zu C++.

Zitat von »Legend«

Ganz so schlimm wie du sehe ich die Situation mit unmanaged Ressourcen in .NET aber auch nicht. Solange jede Klasse, die unmanaged Ressourcen direkt hält, einen Finalizer implementiert hat man wenigstens kein Memory Leak

In C# wird der Aufruf eines Finalizers immerhin zu irgendeinem Zeitpunkt garantiert, in Java hingegen ist der Aufruf von Finalizers optional (dies ist im Grunde konsequenter, weil es anderweitige Ressourcenverwaltung durch den Speicher-GC explizit entwertet; was andere Entwickler nicht davon abhält, es dennoch zu nutzen, inklusive derer der Java-Standard-Bibliothek).

Zitat von »Legend«

im Gegensatz zu einem vergessenen delete in C++. Ganz abgesehen davon, dass man in C++ nicht nur Ressourcen, sondern auch Objekte die nur Speicher benutzen, selber managen muss.

delete solltest du heute in C++ gar nicht mehr von Hand aufrufen sollen. Stattdessen nutzt du "Referenztypen" wie unique_ptr und shared_ptr, welche die Speicherverwaltung automatisieren. Selbes gilt nach einmaliger Implementierung analoger Referenz-Typen auch für jede andere Ressourcenart.

Zitat von »Legend«

[3] Wenn die Resource etwas wie eine Datei oder Netzwerkverbindung ist, bei der mehrfacher Zugriff evtl. unterbunden wird, handelt man sich evtl. trotzdem Bugs ein.
Solange Punkt 3 nicht zutrifft, betrachte ich disposen daher mehr als Optimierung. Klassen, die IDisposable implementieren, sollten eh auch einen Finalizer implementieren.

Nicht nur das, sondern der Speicher-GC kann insbesondere nicht auf Engpässe anderer Ressourcen reagieren. Er sieht zwar, wenn der ihm zugedachte Arbeitsspeicher ausgeschöpft ist, und kann entsprechend unerreichbare Objekte freigeben. Er sieht jedoch nicht, wenn VRAM o.ä. Ressourcen ausgeschöpft sind, in diesem Fall fliegt ggf. bei der nächsten Allokation einfach eine OutOfVRAM-Exception, obwohl sich der fehlende Raum angesichts vieler verwaister Referenzen möglicherweise problemlos schaffen ließe. Dass wir auf dieses Problem einigermaßen selten stoßen, liegt in erster Linie an den unfassbar ressourcenreichen Maschinen, mit denen wir heute arbeiten, und daran, dass sich die Entwickler in professionellen Umgebungen nicht zu schade sind, Ressourcenverwaltung weiterhin in stoischer C-Disziplin immer und immer wieder von Hand durchzuführen. (Nicht umsonst gibt es Firmen, die sich auf Consulting bei Leaks in Managed-Sprachen spezialisiert haben.)

Zitat von »De_Struktor«

Im Bezug auf BC's Aussage, der ja sagt, er würde keine Spielerklasse mit, indem Fall Texture2D, ausstatten. Dot wiederum behauptet, es ist sehr wohl disposable, was trifft nun denn zu?? Ich habe 4 Klassen, die nach Dot's Aussage, alle IDisposable implementieren müssten, aufgrund von kontrollierter Speicherentsorgung.
[...]
Was ich dazu sagen muss, scherzhafterweise, das mit so langsam die Speicherverwaltung komplexer vorkommt als die in C++. Mein Bruder, sagte, er persönlich finde das Ressourcenmanagment in C++ angenehmer, weil er vorher auch mit Java gerarbeitet hatte.
[...]
Was wäre eine logische und angemessene Implementierung??

Nunja, dot denkt hier eher dezentral, wie es in C++ einfach, automatisiert und lückenlos umsetzbar wäre. In C# geht das leider nicht vergleichbar automatisiert. Um dort die Benutzung einzelner Ressourcen mit vergleichbarer Präzision zu verfolgen, musst du tatsächlich händisch Dispose()-Funktionen implementieren, die nichts weiter tun, als die jeweils referenzierten Ressourcen freizugeben. Da Ressourcen in einer Spieleumgebung aber zwangsläufig vielfach geteilt werden, dürftest du hier nicht einfach für alle enthaltenen Ressourcen Dispose() aufrufen, sondern müsstest bei geteilten Ressourcen deine eigenen Ressourcenklassen zusätzlich um eigene Referenzzählung erweitern, die dann bei Erreichen eines 0-Zählstandes ihrerseits die Dispose()-Methode für das eigene Objekt auslöst. Fazit: Bei stringenter feingranularer Ressourcenverwaltung kommst du in C# nicht umhin, Dispose()-Methoden transitiv den ganzen Abhängigkeitsbaum mit Ressourcen arbeitender Objekte hinauf in jede Klasse einzufügen.

Die Alternativlösung, die BC anspricht, sind die hier bereits skizzierten Manager-Klassen. Diese übernehmen Ressourcenverwaltung im Kollektiv, ähnlich der Art wie dies der GC mit Speicher tut. In diesem Fall kümmerst du dich andernorts nicht weiter um Ressourcenverwaltung, sondern legst dir beispielsweise für jeden Level, den du lädst, einen neuen Resource-Manager an, über den du dann am Ende des Levels ALLE geladenen Ressourcen auf einen Schlag wieder freigibst. Hier musst du Acht geben, dass du die Ressourcenfreigabe tatsächlich erst dann auslöst, wenn alle verwalteten Ressourcen im weiteren Programmablauf garantiert nicht mehr referenziert werden. In Umgebungen mit einigermaßen geringer Ressourcenfluktuation, wie sie Spielelevels in der Regel darstellen, ist das eine praktikable Lösung. In anderen veränderlicheren Umgebungen, wie z.B. Leveleditoren, ist das weitaus problematischer, weil hier im Extremfall tatsächlich sehr viele große Ressourcen ge- UND entladen werden können.