WO2006131167A2 - Verfahren zur speicherverwaltung von digitalen recheneinrichtungen - Google Patents

Verfahren zur speicherverwaltung von digitalen recheneinrichtungen Download PDF

Info

Publication number
WO2006131167A2
WO2006131167A2 PCT/EP2006/003393 EP2006003393W WO2006131167A2 WO 2006131167 A2 WO2006131167 A2 WO 2006131167A2 EP 2006003393 W EP2006003393 W EP 2006003393W WO 2006131167 A2 WO2006131167 A2 WO 2006131167A2
Authority
WO
WIPO (PCT)
Prior art keywords
memory
stack
bytes
memory object
stacks
Prior art date
Application number
PCT/EP2006/003393
Other languages
English (en)
French (fr)
Other versions
WO2006131167A3 (de
Inventor
Michael Roth
Original Assignee
Rohde & Schwarz Gmbh & Co. Kg
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Rohde & Schwarz Gmbh & Co. Kg filed Critical Rohde & Schwarz Gmbh & Co. Kg
Priority to EP06742576A priority Critical patent/EP1889159A2/de
Priority to JP2008515063A priority patent/JP2008542933A/ja
Priority to US11/916,805 priority patent/US20080209140A1/en
Priority to CA002610738A priority patent/CA2610738A1/en
Priority to CN2006800162391A priority patent/CN101208663B/zh
Publication of WO2006131167A2 publication Critical patent/WO2006131167A2/de
Publication of WO2006131167A3 publication Critical patent/WO2006131167A3/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory

Definitions

  • the invention relates to a method for managing memory of digital computing device.
  • Modern computing facilities allow the use of complex programs due to the large existing memory and the enormous computing power. Through these programs, processes run on the computing device, within which several so-called threads are processed simultaneously. Because many of these threads are not synchronized with each other in time, multiple threads may simultaneously attempt to access memory management, potentially accessing a particular block of available memory. Such concurrent access can lead to system instability. However, intervention of the operating system can prevent such simultaneous access to a particular memory block.
  • the prevention of access to a memory block already in access by another thread is described in DE 679 15 532 T2. In this case, simultaneous access is prevented only if the simultaneous access concerns the same memory block.
  • the object is achieved by the method according to claim 1.
  • a stack management is used for the available memory.
  • at least one such stack is initially created in the available memory area.
  • the inclusion and return of a storage object by a thread is then carried out by one atomic operation.
  • a further blocking of the remaining threads is not required. It is already ensured by the atomic operation that the access to the memory object takes place in only a single step, whereby an overlap with parallel steps of further threads can not occur.
  • Figure 1 is a schematic representation of a known memory management with double-linked lists.
  • Fig. 2 is a memory management means of stacking and atomic recording and return functions
  • Fig. 3 is a schematic representation of the process sequence of the invention
  • the memory is divided into a plurality of memory objects 1, 2, 3 and 4, which are shown schematically in FIG.
  • a first field Ia and a second field Ib are applied.
  • the first field 1a of the first memory object 1 refers to the position of the second memory object 2.
  • the first field 2a of the second memory object 2 refers to the position of the third memory object 3 and so on.
  • the position of the next storage object is not only indicated in the forward direction, but in the second field 2b, 3b and 4b of the storage objects 2, 3 and 4, the position of the respective preceding storage object 1, 2 and 3 indicated. In this way, it is possible to take out a memory object arranged between two memory objects and at the same time to update the fields of the adjacent memory objects.
  • the first memory object 1 in a list can be reached by a special pointer 5 and is also characterized in that a zero vector is stored in the second field Ib instead of the position of a preceding memory object. Accordingly, the memory object 4 is identified last by storing a zero vector instead of the position of a further memory object in the first field 4a of the memory object 4.
  • FIG. 2 shows an example of a memory management according to the invention.
  • an initialization preferably creates a plurality of stacks or stacks. These stacks are a special form of simply linked lists. 2, four such stacks are shown, which are designated by the reference numerals 6, 7, 8 and 9.
  • Each of these stacks 6 to 9 comprises a plurality of memory objects of different sizes.
  • the first stack 6 objects up to a size of 16 bytes
  • the second stack 7 objects up to a size of 32 bytes
  • in the third stack 8 objects up to a size of 64 bytes
  • the fourth stack 9 Objects can be stored up to a size of 128 bytes.
  • the fourth stack 9 consists of a series of memory objects 10.1, 10.2, 10.3 ... to 10.k, which are simply linked together.
  • the last memory object 10.k of the fourth stack 9 is shown slightly offset in FIG. An access to the individual memory objects is possible on all stacks 6 to 9 only for the lowest memory object of the stacks 6 to 9, for example on stack 9 only for the memory object 10. In Fig. 2, therefore, upon request of memory z. B. the last memory object 10 k of the fourth stack 9 are used. If the memory object 10 k is freed again because it is no longer needed by a thread, it will be returned accordingly at the end of the fourth stack 9.
  • this is represented schematically by a number of different threads 11, by which a memory requirement is given in each case.
  • a process in multiple threads 12, 13, and 14 requests storage volumes of the same size.
  • the size of the requested memory results from the data to be stored.
  • the fourth stack 9 is selected as soon as there is a memory requirement of more than 64 bytes up to a maximum size of 128 bytes. If a storage volume of, for example, 75 bytes is required by the first thread 12, then that one of the stacks 6 through 9 is selected, which contains a free storage object of suitable size. In the illustrated embodiment, this is the fourth stack 9.
  • memory objects 10. I having a size of 128 bytes are made available. Since the memory object 10. K is the last memory object in the fourth stack 9, a so-called "pop" operation is processed on the basis of the memory request of the first thread 12 and thus the memory object 10. k is made available to the thread 12.
  • Such a pop routine is atomic or indivisible, i. H. the memory object 10. k is removed from the fourth stack 9 for the thread 12 in a single processing step.
  • This atomic or atomic operation which maps memory object 10.k to thread 12, prevents another thread, such as thread 13, from accessing the same memory object
  • 10. k can access at the same time. Ie. as soon as a new one Processing step can be performed by the system. the processing with regard to the storage object 10 k is completed and the 10 th storage object is no longer part of the fourth stack 9. In the case of a further storage request by the thread 13, then the last storage object of the fourth stack 9 is the storage object 10 k -1. Again, an atomic pop operation is performed to transfer the memory object 10.k-1 to the thread 13.
  • Such atomic operations require appropriate hardware support and can not be formulated directly in normal programming languages, but require the use of machine language.
  • these hardware-implemented, but usually not used for memory management so-called lock-free-pop calls or lock-free push calls are used to manage memory.
  • lock-free-pop calls or lock-free push calls are used to manage memory.
  • a singly linked list is used in which memory objects can only be retrieved or returned at one end of the applied stacks.
  • FIG. 2 it is further shown for a number of threads 15, as after a delete call of a thread, the respective released memory object is given back to the appropriate stack.
  • each of the memory objects 10. I there is a header 10. I head , as shown for the memory object 10. K in FIG. 2, in which the assignment to a particular stack is coded. For example, the assignment to the fourth stack 9 is contained in the header 10.k head .
  • a delete function is now called by a thread 16, which was assigned the memory object 10.k due to a corresponding lock-free-pop operation, then the memory object is activated by a corresponding, likewise atomic lock-free push operation 10. k returned.
  • the storage object 10. k is appended to the last memory element 10 k belonging to the fourth stack 9.
  • the order of the memory objects 10.sub.i in the fourth stack 9 is changed.
  • the stacks 6 required for the process flow 9 are merely initialized, but at this point in time there are no memory objects 10. If a memory object of a certain size is needed for the first time, for example a memory object of the third stack 8 for a 50-byte element to be stored, this first memory request is processed via the slower system memory management and the memory object is made available therefrom. Concurrent access is prevented in the illustrated example of doubly linked lists as system memory management by a slow mutex opertation.
  • the memory object made available in this way to a first thread is not returned again via the slower system memory management after a delete call, instead the third stack 8 is locked onto a corresponding stack, in the exemplary embodiment described by a lock-free push Operation filed. For the next invocation of a storage object of this size, therefore, this storage object can be accessed with a very fast lock-free-pop operation.
  • This procedure has the advantage that it is not necessary to allocate a fixed number of storage objects to the individual stacks 6, 7, 8 and 9 at the start of a process. Rather, the memory requirement can be dynamically adapted to the running process or its threads. For example, if a process runs in the background with few concurrent threads and has little need for memory objects, then resources are significantly reduced in such an approach.
  • step 19 a program is started, thus generating a process on, for example, a computer.
  • multiple stacks 6 through 9 are initialized.
  • the initialization of the stacks 6-9 is shown in step 20.
  • step 20 In the in 3 illustrated embodiment of the process flow initially only individual stacks 6-9 are created, but without filling them with a certain predefined number of memory objects.
  • a corresponding stack is first selected on the basis of the object size defined by the thread.
  • the second stack 7 is selected in the stack selection of FIG. Subsequently, in step 23, the atomic pop operation is performed a query. Part of this atomic operation is a query 26, whether in the second stack 7, a memory object is available.
  • a null vector ("NULL") is returned and a memory object is accessed through a system call in step 24 through slower system memory management Size 32 bytes provided.
  • NULL null vector
  • the size of the provided storage object is not determined directly by the thread in step 21, but via the selection of a particular object size in step 22, taking into account the initialized stack.
  • the memory request is changed to request a memory object of size 32 bytes.
  • step 26 would therefore have to be answered with "yes" and a storage object is immediately delivered.
  • the return of the same on the basis of a delete call is shown in the further course of the method both for a memory object made available by means of a lock-free-pop call and via the system memory management.
  • the process following a thread's delete call is the same for both situations. Ie. In this case, no account is taken of the way in which the storage object was made available.
  • Fig. 3 this is schematically represented by the two parallel paths, wherein on the right side painted reference numerals are used.
  • a thread starts a delete call.
  • the corresponding memory object is assigned to a specific stack by evaluating the information of the header of the memory object. Consequently, in the described embodiment, the memory object of size 32 bytes is assigned to the second stack 7.
  • the return of the memory object to the second stack 7 takes place in both cases via a lock-free-push operation 29 or 29 '.
  • the last method step 30 indicates that the memory object of the second stack 7 returned in this way is thus available for a next call. This next call can then, as already explained, be made available to a thread by a lock-free-pop operation.
  • a reduction in memory waste can be achieved by creating frequency distributions for requested object sizes. This can also be defined during the execution of different processes for the individual processes. Will such a process with his concurrent threads are started once again, the previously determined frequency distribution from the previous process run is used to allow an adapted size distribution of the stacks 6 to 9.
  • the system can be self-learning, ie with each new pass, the knowledge gained about the size distributions of the memory requirement is updated and the updated data are used each time the process is called.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Executing Machine-Instructions (AREA)
  • Memory System (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zur Verwaltung von Speicher. Bei der Durchführung eines Prozesses wird zumindest ein Stapels (6, 7, 8, 9) für Speicherobjekte (10.1, 10.2, ... 10.k) angelegt. Eine Anforderung für ein Speicherobjekt (10.k) aus einem Stapel (6, 7, 8, 9) wird mittels einer atomaren Operation ausgeführt und eine Rückgabe eines Speicherobjekts (10.k) an den Stapel (6, 7, 8, 9) wird ebenfalls mittels einer atomaren Operation ausgeführt.

Description

Verfahren zur Speicherverwaltung von digitalen Recheneinrichtungen
Die Erfindung betrifft ein Verfahren zur Verwaltung von Speicher von digitalen Recheneinrichtung.
Moderne Recheneinrichtungen ermöglichen auf Grund des großen vorhandenen Speichers und der enormen Rechenleistungen die Verwendung komplexer Programme. Durch diese Programme laufen auf der Recheneinrichtung Prozesse ab, innerhalb derer mehrere sogenannte Threads gleichzeitig abgearbeitet werden. Da viele dieser Threads zeitlich nicht unmittelbar aufeinander abgestimmt sind, kann es vorkommen, dass mehrere Threads gleichzeitig auf die Speicherverwaltung und damit potentiell auf einen bestimmten Block des verfügbaren Speichers zuzugreifen versuchen. Ein solcher gleichzeitiger Zugriff kann zu einer Systeminstabilität führen. Durch einen Eingriff des Betriebssystems kann ein solcher gleichzeitiger Zugriff auf einen bestimmten Speicherblock jedoch verhindert werden. Das Verhindern des Zugriffs auf einen bereits im Zugriff befindlichen Speicherblock durch einen weiteren Thread ist in der DE 679 15 532 T2 beschrieben. Dabei wird ein gleichzeitiger Zugriff nur dann verhindert, wenn der gleichzeitige Zugriff denselben Speicherblock betrifft.
In gängigen Speicherverwaltungen werden beispielsweise häufig sogenannte doppelt verkettete Listen zur Verwaltung des gesamten Speichervolumens in einzelnen Speicherobjekten verwendet. Bei diesen doppelt verketteten Listen erfolgt ein Zugriff auf ein bestimmtes Speicherobjekt in mehreren Schritten. Es ist daher erforderlich, mit dem ersten Zugriff auf ein solches Speicherobjekt die übrigen Threads zu sperren, so dass ein gleichzeitiger Zugriff durch einen weiteren Thread nicht möglich ist, bevor die einzelnen Schritte des ersten Zugriffs abgearbeitet sind. Diese Zugriffssperrung erfolgt unter Zuhilfenahme des Betriebssystems durch eine sogenannte Mutex-Routine. Durch das Einbinden des Betriebssystems und das Ausführen der Mutex-Routine geht jedoch kostbare Rechenzeit verloren. In dieser Zeit sind die übrigen Threads blockiert, indem sie durch Mutex- basiertes Locking vom Betriebssystem vorübergehend von der Ausführung abgehalten werden.
Es ist die Aufgabe der Erfindung, ein Verfahren zur Verwaltung von Speicher einer digitalen Recheneinheit zu schaffen, bei dem in einer Multithread-Umgebung der gleichzeitige Zugriff durch nebenläufige Threads auf einen bestimmten Speicherblock unmöglich ist, das aber gleichzeitig kurze Speicherzugriffszeiten erlaubt.
Die Aufgabe wird durch das erfindungsgemäße Verfahren nach Anspruch 1 gelöst.
Anstelle von doppelt verketteten Listen wird erfindungsgemäß eine StapelVerwaltung für den verfügbaren Speicher verwendet. Hierzu wird in dem verfügbaren Speicherbereich zunächst zumindest ein solcher Stapel angelegt. Die Aufnahme und Rückgabe eines Speicherobjekts durch einen Thread erfolgt dann durch jeweils eine atomare Operation. Durch Verwenden einer solchen atomaren Operation für den Speicherzugriff zusammen mit einer Stapelorganisation des Speichers, der lediglich einen Zugriff auf das letzte Objekt des Stapels ermöglicht, ist eine weitergehende Blockierung der übrigen Threads nicht erforderlich. Dabei wird durch die atomare Operation bereits gewährleistet, dass der Zugriff auf das Speicherobjekt in lediglich einem einzigen Schritt erfolgt, wodurch ein Überlapp mit parallel ablaufenden Schritten weiterer Threads nicht auftreten kann.
In den Unteransprüchen sind vorteilhafte Weiterbildungen des erfindungsgemäßen Verfahrens beansprucht .
Ein bevorzugtes Ausführungsbeispiel ist in den Figuren dargestellt und wird in der nachfolgenden Beschreibung näher erläutert. Es zeigen: Fig. 1 eine Schematische Darstellung einer bekannten Speicherverwaltung mit doppel verketteten Listen;
Fig. 2 eine Speicherverwaltung mittels Stapeln und atomarer Aufnahme- und Rückgabefunktionen und
Fig. 3 eine schematische Darstellung über den Verfahrensablauf der erfindungsgemäßen
Speicherverwaltung .
Bei sogenannten doppelt verketteten Listen wird der Speicher in mehrere Speicherobjekte 1, 2, 3 und 4 eingeteilt, die in Fig. 1 schematisch dargestellt sind. Innerhalb eines jeden solchen Speicherobjekts 1 bis 4 sind ein erstes Feld Ia und ein zweites Feld Ib angelegt. Dabei verweist das erste Feld Ia des ersten Speicherobjekts 1 auf die Position des zweiten Speicherobjekts 2. Ebenso verweist das erste Feld 2a des zweiten Speicherobjekts 2 auf die Position des dritten Speicherobjekts 3 u.s.w. . Um die Aufnahme eines beliebigen mittleren Blocks zu ermöglichen, ist nicht nur in Vorwärtsrichtung die Position des jeweils nächsten Speicherobjekts angegeben, sondern es ist in dem zweiten Feld 2b, 3b und 4b der Speicherobjekte 2, 3 und 4 die Position des jeweils vorausgehenden Speicherobjekts 1, 2 und 3 angegeben. Auf diese Weise ist es möglich, einen zwischen zwei Speicherobjekten angeordnetes Speicherobjekt herauszunehmen und gleichzeitig die Felder der benachbarten Speicherobjekte zu aktualisieren.
Solche doppelt verketteten Listen ermöglichen zwar den individuellen Zugriff auf ein beliebiges Speicherobjekt, weisen andererseits aber den Nachteil auf, dass in einer Multithread-Umgebung der gleichzeitige Zugriff mehrere Threads auf ein Speicherobjekt nur mit langsamen Operationen zu verhindern ist. Eine Möglichkeit ist die in der Einleitung bereits beschriebene Verwaltung der Zugriffe über die Mutex-Funktion. Das erste Speicherobjekt 1 in einer Liste ist durch einen speziellen Zeiger 5 erreichbar und außerdem dadurch gekennzeichnet, dass in dem zweiten Feld Ib anstelle der Position eines vorausgehenden Speicherobjekts ein Nullvektor abgelegt ist. Dementsprechend wird das Speicherobjekt 4 als letztes gekennzeichnet, indem anstelle der Position eines weiteren Speicherobjekts in dem ersten Feld 4a des Speicherobjekts 4 ein Nullvektor abgelegt ist.
In der Fig. 2 ist dagegen ein Beispiel einer erfindungsgemäßen Speicherverwaltung dargestellt. Bei der erfindungsgemäßen Speicherverwaltung werden zunächst bei einer Initatialisierung vorzugsweise mehrere Stapel oder Stacks angelegt. Diese Stacks sind eine spezielle Form einfach verketteter Listen. In der Fig. 2 sind vier solcher Stacks dargestellt, die mit den Bezugszeichen 6, 7, 8 und 9 bezeichnet sind. Jeder dieser Stacks 6 bis 9 umfasst mehrere Speicherobjekte unterschiedlicher Größe. So können in dem ersten Stack 6 Objekte bis zu einer Größe von 16 Bytes, in dem zweiten Stack 7 Objekte bis zu einer Größe von 32 Bytes, in dem dritten Stack 8 Objekte bis zu einer Größe von 64 Bytes und schließlich in dem vierten Stack 9 Objekte bis zu einer Größe von 128 Bytes gespeichert werden. Bei Auftreten größerer zu speichernder Elemente können auch Stacks mit größeren Speicherobjekten angelegt werden, wobei vorzugsweise jeweils zum nächsten Stack die Größe der einzelnen Speicherobjekte verdoppelt wird. Die Aufteilung eines solchen Stacks in einzelne Speicherobjekte 10. i ist für den vierten Stack 9 detailliert dargestellt. Der vierte Stack 9 besteht aus einer Reihe einfach miteinander verketteten Speicherobjekten 10.1, 10.2, 10.3 ... bis 10. k. Das letzte Speicherobjekt 10. k des vierten Stacks 9 ist in der Fig. 2 leicht abgesetzt dargestellt. Ein Zugriff auf die einzelnen Speicherobjekte ist auf allen Stapeln 6 bis 9 jeweils nur für das unterste Speicherobjekt der Stapel 6 bis 9 möglich, beispielsweise auf Stapel 9 nur für das Speicherobjekt 10. k. In der Fig. 2 kann folglich bei einer Anforderung von Speicher z. B. das letzte Speicherobjekt 10. k des vierten Stapels 9 verwendet werden. Wird das Speicherobjekt 10. k wieder frei, da es durch einen Thread nicht länger benötigt wird, so wird es entsprechend am Ende des vierten Stacks 9 wieder zurückgegeben.
In der Fig. 2 ist dies schematisch durch eine Anzahl unterschiedlicher Threads 11, durch die jeweils eine Speicheranforderung gegeben ist, dargestellt. Bei dem konkreten Ausführungsbeispiel fordert beispielsweise ein Prozess in mehreren Threads 12, 13 und 14 Speichervolumen derselben Größe an. Die Größe des angeforderten Speichers ergibt sich aus den zu speichernden Daten. In dem dargestellten Ausführungsbeispiel wird der vierte Stack 9 ausgewählt, sobald ein Speicherbedarf von mehr als 64 Bytes bis zu einer Maximalgröße von 128 Bytes vorhanden ist. Wird nun durch den ersten Thread 12 ein Speichervolumen von beispielsweise 75 Bytes benötigt, so wird zunächst derjenige der Stacks 6 bis 9 ausgewählt, der ein freies Speicherobjekt passender Größe enthält. In dem dargestellten Ausführungsbeispiel ist dies der vierte Stack 9. Hier werden Speicherobjekte 10. i mit einer Größe von 128 Bytes zur Verfügung gestellt. Da das Speicherobjekt 10. k das letzte Speicherobjekt in dem vierten Stack 9 ist, wird auf Grund der Speicheranfrage des ersten Threads 12 eine sogenannte "Pop" -Operation abgearbeitet und damit das Speicherobjekt 10.k dem Thread 12 zur Verfügung gestellt.
Eine solche Pop-Routine ist atomar bzw. unteilbar, d. h. das Speicherobjekt 10. k wird für den Thread 12 in einem einzigen Verarbeitungsschritt von dem vierten Stack 9 abgenommen. Durch diese atomare bzw. unteilbare Operation, mit der das Speicherobjekt 10. k dem Thread 12 zugeordnet wird, wird verhindert, dass ein anderer Thread, beispielsweise der Thread 13 auf dasselbe Speicherobjekt
10. k gleichzeitig zugreifen kann. D. h. , sobald ein neuer Verarbeitungsschritt durch das System durchgeführt werden kann. ist die Verarbeitung hinsichtlich des Speicherobjekts 10. k abgeschlossen und das lO.kte Speicherobjekt nicht länger Bestandteil des vierten Stacks 9. Bei einer weiteren Speicheranforderung durch den Thread 13 ist daher das dann letzte Speicherobjekt des vierten Stacks 9 das Speicherobjekt 10. k - 1. Auch hier wird wiederum zur Übergabe des Speicherobjekts 10. k - 1 an den Thread 13 eine atomare Pop-Operation durchgeführt.
Solche atomaren Operationen setzen hardwareseitig entsprechende Unterstützung voraus und können nicht direkt in normalen Programmiersprachen formuliert werden, sondern erfordern den Einsatz von Maschinensprache. Erfindungsgemäß werden diese hardwareseitig implementierten, üblicherweise jedoch nicht zur Speicherverwaltung verwendeten sogenannten Lock-Free-Pop- Aufrufe bzw. Lock-Free-Push-Aufrufe zur Verwaltung von Speicher eingesetzt. Hierzu wird beispielsweise anstelle der doppelt verketteten Listen, wie sie in der Fig. 1 schematisch dargestellt wurden, eine einfach verkettete Liste verwendet, bei der lediglich an einem Ende der angelegten Stacks Speicherobjekte abgerufen bzw. zurückgegeben werden können.
In der Fig. 2 ist es weiterhin für eine Anzahl von Threads 15 dargestellt, wie nach einem Delete-Aufruf eines Threads das jeweilige freiwerdende Speicherobjekt wieder zurück zu dem passenden Stack gegeben wird. In jedem der Speicherobjekte 10. i ist ein Header 10.ihead vorhanden, wie es für das Speicherobjekt 10. k in der Fig. 2 gezeigt ist, in dem die Zuordnung zu einem bestimmten Stack kodiert ist. So ist beispielsweise in dem Header 10.khead die Zuordnung zu dem vierten Stack 9 enthalten. Wird nun durch einen Thread 16, dem auf Grund einer entsprechenden Lock- Free-Pop-Operation das Speicherobjekt 10. k zugeordnet wurde, eine Delete-Funktion aufgerufen, so wird durch eine entsprechende, ebenfalls atomare Lock-Free-Push-Operation das Speicherobjekt 10. k zurückgegeben. Das Speicherobjekt 10. k wird dabei an das letzte zu dem vierten Stack 9 gehörende Speicherelement 10. k - 1 angehängt. Damit wird abhängig von der Reihenfolge in der unterschiedliche Threads 16, 17, 18 die Speicherobjekte 10. i zurückgeben, die Reihenfolge der Speicherobjekte 10. i in dem vierten Stack 9 geändert.
Entscheidend ist es, dass diese sogenannten Lock-Free-Pop- und Lock-Free-Push-Aufrufe atomar sind und daher extrem schnell abgearbeitet werden können. Der Geschwindigkeitsvorteil beruht dabei entscheidend darauf, dass die Verwendung einer Betriebssystemoperation, beispielsweise Mutex, nicht erforderlich ist, um weitere Threads von einem gleichzeitigen Zugriff auf ein bestimmtes Speicherobjekt auszuschließen. Ein solcher Ausschluss für den gleichzeitigen Zugriff durch weitere Threads ist auf Grund der atomaren Eigenschaft der Popbzw. Push-Aufrufe nicht erforderlich. Insbesondere muss das Betriebssystem bei einem tatsächlich gleichzeitigen Zugriff auf die Speicherverwaltung (sog. Contention-Fall) keinen Threadwechsel durchführen, der im Vergleich zur Speicheroperation selbst ungleich mehr Rechenzeit erfordert.
Bei einer solchen Verwaltung von Speicher in Stacks und Zugriffen mittels Lock-Free-Pop- und Lock-Free-Push- Aufrufen ist es unvermeidbar, dass ein Teil des vorhandenen Speichervolumens verschenkt wird. Diese Verschwendung entsteht durch die nicht ideal angepasste Größe der einzelnen Stacks bzw. deren Speicherobjekte. Ist eine bestimmte Größenstruktur der zu speichernden Daten bekannt, so kann jedoch die Verteilung der Speicherobjektgrößen der einzelnen Stacks 6 bis 9 hieran angepasst werden.
Gemäß einer besonders bevorzugten Form der erfindungsgemäßen Speicherverwaltung ist es vorgesehen, dass zu Beginn eines Prozesses, beispielsweise nach einem Programmstart, die zum Prozessablauf benötigten Stacks 6 bis 9 lediglich initialisiert werden, zu diesem Zeitpunkt aber noch keine Speicherobjekte 10. i enthalten. Wird nun ein Speicherobjekt einer bestimmten Größe zum ersten Mal benötigt, beispielsweise für ein zu speicherndes Element der Größe 50 Bytes ein Speicherobjekt des dritten Stacks 8, so wird diese erste Speicheranforderung über die langsamere Systemspeicherverwaltung abgearbeitet und das Speicherobjekt von dort zur Verfügung gestellt. Der gleichzeitige Zugriff wird in dem erläuterten Beispiel doppelt verketteter Listen als Systemspeicherverwaltung durch eine langsame Mutex Opertation verhindert . Das auf diese Art und Weise einem ersten Thread zur Verfügung gestellte Speicherobjekt wird jedoch nach einem Delete- Aufruf nicht wieder über die langsamere Systemspeicherverwaltung zurückgegeben, sondern es wird auf einen entsprechenden Stack, im beschriebenen Ausführungsbeispiel den dritten Stack 8 durch eine Lock- Free-Push-Operation abgelegt. Für den nächsten Aufruf eines Speicherobjekts dieser Größe kann daher auf dieses Speicherobjekt mit einer sehr schnellen Lock-Free-Pop- Operation zugegriffen werden.
Diese Vorgehensweise hat den Vorteil, dass nicht pauschal zu Beginn eines Prozesses bereits eine festgelegte Anzahl von Speicherobjekten den einzelnen Stacks 6, 7, 8 und 9 zugeordnet werden muss. Vielmehr kann dynamisch der Speicherbedarf an den laufenden Prozess bzw. dessen Threads angepasst werden. Läuft beispielsweise ein Prozess im Hintergrund mit wenigen nebenläufigen Threads ab und hat nur geringen Bedarf an Speicherobjekten, so werden bei einer solchen Vorgehensweise entscheidend Resourcen gespart .
Das Verfahren ist schematisch noch einmal in Fig. 3 dargestellt. Zunächst wird in Schritt 19 ein Programm gestartet und somit ein Prozess auf beispielsweise einem Computer generiert. Mit dem Beginn des Prozesses werden mehrere Stacks 6 bis 9 initialisiert. Die Initialisierung der Stacks 6-9 ist in Schritt 20 dargestellt. In dem in der Fig. 3 dargestellten Ausführungsbeispiel des Verfahrensablaufs werden zunächst nur einzelne Stacks 6-9 angelegt, ohne diese jedoch mit einer bestimmten vordefinierten Anzahl von Speicherobjekten zu füllen. Bei einer im Verfahrensschritt 21 auftretenden Speicheranforderung durch einen Thread wird zunächst auf Grund der durch den Thread festgelegten Objektgröße ein entsprechender Stack selektiert.
Wird beispielsweise ein 20 Bytes großes Speicherobjekt benötigt, so wird in der Stack-Auswahl der Fig. 2 der zweite Stack 7 gewählt. Anschließend wird in Schritt 23 die atomare Pop-Operation eine Abfrage durchgeführt . Bestandteil dieser unteilbaren Operation ist eine Abfrage 26, ob in dem zweiten Stack 7 ein Speicherobjekt verfügbar ist. Für den Fall, dass der Stack 7 mit einer Größe von 32 Bytes pro Speicherobjekt lediglich initialisiert ist, jedoch noch kein verfügbares Speicherobjekt enthält, wird ein Nullvektor ("NULL") zurückgegeben und über einen Systemaufruf in Schritt 24 über die langsamere Systemspeicherverwaltung ein Speicherobjekt der Größe 32 Bytes zur Verfügung gestellt. Die Größe des zur Verfügung gestellten Speicherobjekts wird dabei jedoch nicht unmittelbar durch den Thread in Schritt 21 festgelegt, sondern über die Auswahl einer bestimmten Objektgröße in Schritt 22 unter Berücksichtigung der initialisierten Stapel .
In dem beschriebenen Ausführungsbeispiel wird folglich die Speicheranfrage so geändert, dass ein Speicherobjekt mit der Größe 32 Bytes angefordert wird. Um einen gleichzeitigen Zugriff auf dieses Speicherobjekt während der Aufnahme durch den Thread zu verhindern, würde in dem
Beispiel der Systemspeicherverwaltung mittels doppelt verketteter Listen über das Betriebssystem eine Mutex-
Operation gestartet.
Handelt es sich bei dem benötigten Speicherobjekt dagegen um ein bereits im Laufe des Prozesses zurückgegebenes Speicherobjekt, so liegt dieses bereits in dem zweiten Stack 7 vor. Die Abfrage in Schritt 26 wäre daher mit "Ja" zu beantworten und es wird unmittelbar ein Speicherobjekt geliefert. Der Vollständigkeit halber ist im weiteren Verlauf des Verfahrens sowohl für einen mittels Lock-Free- Pop-Aufruf als auch über die Systemspeicherverwaltung zur Verfügung gestellten Speicherobjekt die Rückgabe desselben auf Grund eines Delete-Aufrufs dargestellt. Der Ablauf in Folge eines Delete-Aufrufs eines Threads ist für beide Situationen identisch. D. h. hier wird in keiner Weise Rücksicht darauf genommen, auf welchem Weg das Speicherobjekt zur Verfügung gestellt wurde. In der Fig. 3 ist dies schematisch durch die beiden parallelen Wege dargestellt, wobei auf der rechten Seite gestrichene Bezugszeichen verwendet werden.
Zunächst wird durch einen Thread ein Delete-Aufruf gestartet. Der entsprechende Speicherobjekt wird über ein Auswerten der Informationen des Headers des Speicherobjekts einem bestimmten Stack zugeordnet. In dem beschriebenen Ausführungsbeispiel wird folglich das Speicherobjekt mit der Größe 32 Bytes dem zweiten Stack 7 zugeordnet. Die Rückgabe des Speicherobjekts an den zweiten Stack 7 erfolgt in beiden Fällen über eine Lock- Free-Push-Operation 29 bzw. 29'. Mit dem letzten Verfahrensschritt 30 ist angedeutet, dass das so zurückgegebene Speicherobjekt des zweiten Stacks 7 somit für einen nächsten Aufruf zur Verfügung steht. Dieser nächste Aufruf kann dann, wie es bereits erläutert wurde, durch eine Lock-Free-Pop-Operation einem Thread zur Verfügung gestellt werden.
Wie es bereits beschrieben wurde, kann bei der Initalisierung der Stacks 6 bis 9 eine Verringerung der Speicherverschwendung erreicht werden, indem Häufigkeitsverteilungen für angeforderte Objektgrößen erstellt werden. Dies kann auch während des Abarbeitens verschiedener Prozesse für die einzelnen Prozesse festgelegt werden. Wird ein solcher Prozess mit seinen nebenläufigen Threads ein weiteres Mal gestartet, so wird auf die zuvor ermittelte Häufigkeitsverteilung aus dem vorangegangenen Prozessdurchlauf zurückgegriffen, um eine angepasste Größenverteilung der Stacks 6 bis 9 zu ermöglichen. Das System kann selbstlernend ausgeführt werden, d. h. dass mit jedem neuen Durchlauf die bereits gewonnenen Erkenntnisse über die Größenverteilungen des Speicherbedarfs aktualisiert werden und bei jedem neuen Aufruf des Prozesses die jeweils aktualisierten Daten verwendet werden.
Die Erfindung ist nicht auf das dargestellte Ausführungsbeispiel beschränkt. Vielmehr sind beliebige Kombinationen der einzelnen erläuternden Merkmale möglich.

Claims

Ansprüche
1. Verfahren zur Verwaltung von Speicher mit folgenden Verfahrensschritten: - Anlegen zumindest eines Stapels (6, 7, 8, 9) für Speicherobjekte (10.1, 10.2,... lO.k);
Ausführen einer Anforderung für ein Speicherobjekt (10.k) aus einem Stapel (6, 7, 8, 9) mittels einer atomaren Operation und - Rückgabe eines Speicherobjekts (10.k) an den Stapel (6, 7, 8, 9) mittels einer atomaren Operation
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass mehrere Stapel (6, 7, 8, 9) für jeweils unterschiedliche Speicherobjektgrößen (16 Byte, 32 Byte, 64 Byte, 128 Byte) angelegt werden.
3. Verfahren nach Anspruch 1 oder 2 , dadurch gekennzeichnet, dass vor der Aufnahme eines Speicherobjekts (10.k) der jeweilige Stapel (6, 7, 8, 9) mit der gegenüber einer Speicheranforderung nächstgrößeren Speicherobjektgröße (16 Byte, 32 Byte, 64 Byte, 128 Byte) ausgewählt wird.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass nach einer Initialisierung der Stapel (6, 7, 8,9) in den Stapeln (6, 7, 8, 9) zunächst keine Speicherobjekte (10.i) existieren und jeweils bei einer erstmaligen Speichervolumenanforderung ein Speicherobjekt über eine Systemspeicherverwaltung angefordert wird und dieses Speicherobjekt bei seiner Rückgabe einem Stapel (6, 7, 8, 9) zugeordnet wird.
5. Verfahren nach Anspruch 4 , dadurch gekennzeichnet, dass vor der Anforderung des Speicherobjekts über die
Systemspeicherverwaltung die Größe des Speicherobjekts durch die Größe der initialisierten Stapel (6, 7, 8, 9) und der aktuellen Speichervolumenanforderung festgelegt wird.
6. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass zum Festlegen der Größen der Speicherobjekte (lO.i) der Stapel (6, 7, 8, 9) eine Häfugkeitsverteilung der Speicherobjektgrößen während eines Prozesses aktualisiert wird und bei einer neuerlich Ausführung des Prozesses die jeweils aktualisierte Häufigkeitsverteilung auf der Initialisierung der Stapel (6, 7, 8, 9) zu Grunde gelegt wird.
7. Digitales Speichermedium mit elektronisch auslesbaren Steuersignalen, die so mit einem programmierbaren Computer oder digitalen Signalprozessor eines Telekommunikationsgerätes zusammenwirken können, dass das Verfahren nach einem der Ansprüche 1 bis 6 ausgeführt wird.
8. Computerprogamm-Produkt mit auf einem maschinenlesbaren Träger gespeicherten Programmcode-Mitteln, um alle Schritte gemäß einem der Ansprüche 1 bis 6 durchführen zu können, wenn das Programm auf einem Computer oder einem digitalen Signalprozessor eines Telekommunikationsgerätes ausgeführt wird.
9. Computerprogramm mit Progammcode-Mitteln, um alle Schritte gemäß einem der Ansprüche 1 bis 6 durchführen zu können, wenn das Programm auf einem Computer oder einem digitalen Signalprozessor eines Telekommunikationsgerätes ausgeführt wird.
10. Computerprogramm mit Programmcode-Mitteln, um alle Schritte gemäß einem der Ansprüche 1 bis 6 durchführen zu können, wenn das Programm auf einem maschinenlesbaren Datenträger gespeichert ist.
PCT/EP2006/003393 2005-06-09 2006-04-12 Verfahren zur speicherverwaltung von digitalen recheneinrichtungen WO2006131167A2 (de)

Priority Applications (5)

Application Number Priority Date Filing Date Title
EP06742576A EP1889159A2 (de) 2005-06-09 2006-04-12 Verfahren zur speicherverwaltung von digitalen recheneinrichtungen
JP2008515063A JP2008542933A (ja) 2005-06-09 2006-04-12 ディジタル計算装置のメモリを管理する方法
US11/916,805 US20080209140A1 (en) 2005-06-09 2006-04-12 Method for Managing Memories of Digital Computing Devices
CA002610738A CA2610738A1 (en) 2005-06-09 2006-04-12 Method for managing memories of digital computing devices
CN2006800162391A CN101208663B (zh) 2005-06-09 2006-04-12 对数字计算设备的存储器进行管理的方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102005026721.1 2005-06-09
DE102005026721A DE102005026721A1 (de) 2005-06-09 2005-06-09 Verfahren zur Speicherverwaltung von digitalen Recheneinrichtungen

Publications (2)

Publication Number Publication Date
WO2006131167A2 true WO2006131167A2 (de) 2006-12-14
WO2006131167A3 WO2006131167A3 (de) 2007-03-08

Family

ID=37103066

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2006/003393 WO2006131167A2 (de) 2005-06-09 2006-04-12 Verfahren zur speicherverwaltung von digitalen recheneinrichtungen

Country Status (8)

Country Link
US (1) US20080209140A1 (de)
EP (1) EP1889159A2 (de)
JP (1) JP2008542933A (de)
KR (1) KR20080012901A (de)
CN (1) CN101208663B (de)
CA (1) CA2610738A1 (de)
DE (1) DE102005026721A1 (de)
WO (1) WO2006131167A2 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0808576D0 (en) * 2008-05-12 2008-06-18 Xmos Ltd Compiling and linking
US11243769B2 (en) 2020-03-28 2022-02-08 Intel Corporation Shadow stack ISA extensions to support fast return and event delivery (FRED) architecture

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5784698A (en) * 1995-12-05 1998-07-21 International Business Machines Corporation Dynamic memory allocation that enalbes efficient use of buffer pool memory segments
US6065019A (en) * 1997-10-20 2000-05-16 International Business Machines Corporation Method and apparatus for allocating and freeing storage utilizing multiple tiers of storage organization
WO2001050247A2 (en) * 2000-01-05 2001-07-12 Intel Corporation Memory shared between processing threads
WO2001061471A2 (en) * 2000-02-16 2001-08-23 Sun Microsystems, Inc. An implementation for nonblocking memory allocation
US6539464B1 (en) * 2000-04-08 2003-03-25 Radoslav Nenkov Getov Memory allocator for multithread environment

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6391755A (ja) * 1986-10-06 1988-04-22 Fujitsu Ltd スタツク使用量予測に基づくメモリ分割方式
JPH0713852A (ja) * 1993-06-23 1995-01-17 Matsushita Electric Ind Co Ltd 領域管理装置
US5978893A (en) * 1996-06-19 1999-11-02 Apple Computer, Inc. Method and system for memory management
GB9717715D0 (en) * 1997-08-22 1997-10-29 Philips Electronics Nv Data processor with localised memory reclamation
US6275916B1 (en) * 1997-12-18 2001-08-14 Alcatel Usa Sourcing, L.P. Object oriented program memory management system and method using fixed sized memory pools
US6449709B1 (en) * 1998-06-02 2002-09-10 Adaptec, Inc. Fast stack save and restore system and method

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5784698A (en) * 1995-12-05 1998-07-21 International Business Machines Corporation Dynamic memory allocation that enalbes efficient use of buffer pool memory segments
US6065019A (en) * 1997-10-20 2000-05-16 International Business Machines Corporation Method and apparatus for allocating and freeing storage utilizing multiple tiers of storage organization
WO2001050247A2 (en) * 2000-01-05 2001-07-12 Intel Corporation Memory shared between processing threads
WO2001061471A2 (en) * 2000-02-16 2001-08-23 Sun Microsystems, Inc. An implementation for nonblocking memory allocation
US6539464B1 (en) * 2000-04-08 2003-03-25 Radoslav Nenkov Getov Memory allocator for multithread environment

Also Published As

Publication number Publication date
WO2006131167A3 (de) 2007-03-08
KR20080012901A (ko) 2008-02-12
EP1889159A2 (de) 2008-02-20
CA2610738A1 (en) 2006-12-14
US20080209140A1 (en) 2008-08-28
JP2008542933A (ja) 2008-11-27
DE102005026721A1 (de) 2007-01-11
CN101208663B (zh) 2012-04-25
CN101208663A (zh) 2008-06-25

Similar Documents

Publication Publication Date Title
DE2224537C2 (de) Einrichtung und Verfahren zur Instruktionsauswahl in einem Fließbandprozessor
DE2645537C2 (de)
EP0048767B1 (de) Prioritätsstufengesteuerte Unterbrechungseinrichtung
DE2423194C2 (de) Vorrichtung zum Berechnen einer absoluten Hauptspeicheradresse in einer Datenverarbeitungsanlage
DE69425554T2 (de) System zur dynamischen zuordnung von speicher registern zum herstellen von pseudowarteschlangen
DE2354521C2 (de) Verfahren und Einrichtung zum gleichzeitigen Zugriff zu verschiedenen Speichermoduln
EP1228432B1 (de) Verfahren zur dynamischen speicherverwaltung
DE1499182C3 (de) Datenspeichersystem
DE2346525B2 (de) Virtuelle Speichereinrichtung
DE69936257T2 (de) Erzeugen und uberprüfen von referenz-adresszeigern
EP0635792A2 (de) Verfahren zur Koordination von parallelen Zugriffen mehrerer Prozessoren auf Resourcenkonfigurationen
DE2556617C2 (de) Schiebe- und Rotierschaltung
DE2031040B2 (de) Verfahren zur festlegung des zugangs von mehreren benutzern zu einer einheit einer datenverarbeitungsanlage und anordnung zur durchfuehrung des verfahrens
EP0010570A2 (de) Verfahren und Einrichtung zur selbstadaptiven Zuordnung der Arbeitslast einer Datenverarbeitungsanlage
DE2101949A1 (de) Verfahren zum Schutz von Datengruppen in einer Multiprocessing-Datenverarbeitungsanlage
DE3507584C2 (de)
DE2617485C3 (de) Schaltungsanordnung für Datenverarbeitungsanlagen zur Abarbeitung von Mikrobefehlsfolgen
WO2001040931A2 (de) Verfahren zum synchronisieren von programmabschnitten eines computerprogramms
DE69831282T2 (de) Verwaltung von umbenannten Register in einem superskalaren Rechnersystem
DE2456710A1 (de) Einrichtung zum packen von seitenrahmen eines hauptspeichers mit datensegmenten
WO2006131167A2 (de) Verfahren zur speicherverwaltung von digitalen recheneinrichtungen
EP0655688B1 (de) Programmspeichererweiterung für einen Mikroprozessor
EP2102766A1 (de) Verfahren zum auslesen von daten aus einem speichermedium
DE69815656T2 (de) Rechnersystem mit einem mehrfach Sprungbefehlzeiger und -Verfahren
DE2419522A1 (de) Verfahren und anordnung zur unterteilung eines oder mehrerer nicht benutzter bereiche eines mit einem rechner verbundenen speichers

Legal Events

Date Code Title Description
DPE2 Request for preliminary examination filed before expiration of 19th month from priority date (pct application filed from 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2006742576

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 200680016239.1

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 1020077027590

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 2610738

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 2008515063

Country of ref document: JP

WWP Wipo information: published in national office

Ref document number: 2006742576

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 11916805

Country of ref document: US