Zitat:
@Hagen: da musst du mir mal erklären warum RecyclerMM sowas nicht können sollte, die anderen jedoch schon ^^
Nö, die Anderen können es genauso wenig wie RecyclerMM, und ohne tiefe
OS Tricks wirds auch keinen MM geben können der es kann, so einfach ist die Sache.
Ich versuch das Problam nochmal zu verdeutlichen:
Du schreibst eine
DLL die RecyclerMM benutzt. Diese
DLL exportiert Funktion XYZ und in dieser führst du umfangreiche Berchnungen druch die sehr viele Speicherblöcke alloziert und dealloziert.
Die
DLL bindest du in einer neuen Anwendung ein und rufst nun die Funktion XYZ innerhalb eines Threads auf.
Was passiert nun in RecyclerMM == R und in einem normalen MM = N ?
1.) Thread wird erzeugt
2.) Funktion XYZ wird aufgerufen
3.) Speicher wird alloziert
- R alloziert viel mehr Speicher als nötig und erzeugt beim ersten Aufruf für diesen Thread einen komplett eigenständigen Memory Manager
- N hat schon einen MM für alle Threads und alloziert Speicher geschützt per
RTL Critical Sections für alle Threda vom selben Pool
4.) Speicher wird freigeben und wieder neu alloziert
- R gibt niemals den freien Speicher zurück ans das
OS, im WorstCase belegt also R immer mehr virtuellen aber real ungenutzen Speicher
- N ging gegebenfalls beim überschreiten gewisser Größen den Speicher mit VirtualFree() wieder an das
OS zurück
5.) alle Speicherbereich in Funktion XYZ werden freigegeben da XYZ terminieren möchte
- R legt diese freien Speicherbereich in seinem Threadeigenen Pool ab, gibt sie aber nicht an das
OS zurück
- N legt diese Speicherbereich in seinen gemeinsammen Pool ab, andere Threads könnensie wiederbenutzen oder beim überschreiten eines Thresholds gibt N sie mit VirtualFree() sofort an das
OS zurück
6.) Funktion XYZ kehrt zurück, Prozess terminiert Thread
- R hat nun einen rießigen Block von Speicherleiche übrig gelassen da R nicht auf die Terminierung des Thread reagieren kann
- N hat ebenfalls ungenutzen virtuellen Speicherliegen, der aber durch andere Thread erneut benutzt werden kann und beim Beenden des Prozesses == entladen der
DLL auch sauber per Vitual Free freigegeben werden kann.
Wiederholt man nun sehr schnell den Prozess des Threads erzeugen, Funktion XYZ ausführen und Thread zerstören so entstehen immer neuere Speicherleichen in R.
Man könnte nun argumentieren das die
DLL in der R, N enthalten ist per Code Hooks auf die Beendigung eines Thread reagieren könnte. Ja das wäre möglich aber ist nur scheinbar eine Lösung. Denn bei eigenen Programmen geht dies noch zu machen aber nicht mehr bei zb.
COM,
ActiveX Servern. Dies können nicht ermitteln ob und wann ein Thread terminiert wird, dies geht einfach nicht da es auf
API Ebene des
OS keinen Signaling Mechanismus dafür gibt.
Ich möchte hier auch nicht weiter darüber diskutieren. Meine Emofehlung lautet RecyclerMM nicht zu benutzen. Der Author ist sich dieses Problemes sehr wohl bewusst da ich mit ihm darüber korrespondiert habe. Desweiteren wurde deises Problem ebenfalls in den Borland NewsGroup diskutiert. Zweitens ist dies schon wieder ein par Jahre her ! und es erfolgte keine Reaktion darauf indem man zumindestens im RecyclerMM darauf hinwies. Ich bin aber nicht für die korekte Funktion andere Sourcen verantwortlich.
Ergo: er ihn nutzen möhcte soll es tuen, sich aber dann nicht wundern wenn er Fehler bekommt die er nicht im mindestens einzuodrnen weis. Denn Fehler in einem Speichermanager führen zu fehlern die man so nicht debuggen geschweige denn einzuordnen weis. Man sucht dann wochenlang in seinen eigenen Sourcen ohne Erfolg.
Gruß Hagen
[edit]
PS: Ich habe keinen eigenen MM programmiert und verkaufe auch kein irgendwie geartetes Produkt in dieser Richtung. Soll heissen ich habe nicht das geringste Interesse RecyclerMM zu diskretitieren noch die Arbeit des Authors schlecht zu machen. Das einzisgte was ich mache ist euch zu warnen das mit RecyclerMM designtechnisch begründete Fehler auftreten müssen !
[/edit]