Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Andreas Wagner Newsgroups: de.sci.informatik.misc Subject: Re: Freispeichermanagement Date: Tue, 13 Dec 2022 20:19:13 +0100 Lines: 31 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: individual.net /4m2qWdalPribRPM3PHiZASp06Hptft/PfOBmV62AGV1nm/xqU Cancel-Lock: sha1:UDTCzvuy2poJqNORRE0jNYQ941c= User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 In-Reply-To: Xref: csiph.com de.sci.informatik.misc:369 Hallo! Ich vermute ja, dass meine Implementierung doch funktionieren könnte, wenn es eine Abbruchbedingung in removeSpaceReservation() gibt. Wenn zum Beispiel ein Block nur neu in der Größe justiert wird, dann muss kein erneutes store() aufgerufen werden. Da reicht ein Update, das keine reserveSpace() benötigt. Ich habe das hete mal eingebaut und der Fehler hat sich deutlich geändert. Da werde ich dann demnächst mal genauer schauen. Am 13.12.2022 um 18:28 schrieb Stefan Reuther: > Ich würde versuchen, die Verwaltungsdaten in den Blöcken selbst zu > speichern. Ein allokierter Block besteht aus Header+Payload, ein > freigegebener Block besteht aus Header+Knoten1+Knoten2, wobei Knoten1/2 > die Knoten in der ersten und zweiten Map sind. Die Basisoperationen sind > dann nicht store() und remove(), sondern insertNode() und unlinkNode(), > die einfach nur den Knoten ein- oder ausketten und dabei keine neuen > Knoten anlegen. Meinst Du bei "Header+Knoten1+Knoten2", dass jeweils Speicherpositionen von Knoten 1 und 2 angegeben werden? Mir stellt sich die Frage, wonach der Baum sortiert sein soll, der mit dem Header organisiert ist. Größe und Position haben ja jeweils schon eine Map. Mir ist auch noch keine Idee gekommen, wie man den Knoten auswählt, der bei insertNode() wiederverwendet werden soll. Gruß Andreas