KR20060096569A - A apparatus and method for pool resource management by using multi-step allocation - Google Patents

Abstract

The present invention creates an identifier queue by the maximum number of resources that can be created within a predetermined maximum number of groups of memory of the system, and creates an initial idle pool group for managing idle resources initially. Subsequently, if all resources allocated to the initial idle pool group are in use, a next idle pool group is created, and if the number of idle resources is greater than a predetermined threshold, the next pool is returned. By deleting the resources of the group, it is possible to efficiently manage the resources of the memory.

Pool Resource Management, Resource generation / assignment / restoration. idle Pool Group

Description

A Apparatus And Method For Pool Resource Management By Using Multi-Step Allocation}

1 shows a typical pool structure.

Figure 2 shows a multi-stage pool structure according to a preferred embodiment of the present invention.

Figure 3 shows a multi-stage pool structure according to a preferred embodiment of the present invention.

4 is a flowchart of an initial pool resource creation operation according to a preferred embodiment of the present invention.

5 is a flowchart of a pool resource allocation task in accordance with a preferred embodiment of the present invention.

6 is a flowchart illustrating a pool resource return and unnecessary resource deletion operation according to a preferred embodiment of the present invention.

The present invention relates to a resource management method of a mobile communication system, and more particularly, to a resource management method for configuring and managing a large number of objects or data in a pool manner.

In systems that need to manage a large amount of resources in real time, such as mobile communication systems, internally manage a large number of data or objects in a pooled manner, and allocate resources at the request of an external process. When the usage of the used resource is finished, the resource is used to return to the pool. In general, these pools are managed using a Standard Template Library (STL) such as an array, a list, and a map having a maximum size.

1 is a view showing a general pool structure.

Referring to FIG. 1, a resource is generated in the internal memory of the system by a maximum value of index information that can be provided by an external processor, and is allocated a resource which is mapped with arbitrary index information.

As described above, resources composed of pure data or objects have a simple structure that is created and configured to the maximum size required during initial operation of the system or internally. Therefore, when allocating / returning resources existing in the pool, Ease of use

However, the above-described full structure occupies a lot of memory in the system, and in particular, when the data size of each resource is large, there is a problem in that the system memory is inefficiently occupied. In addition, there is a problem of degrading system performance when managing resources by dynamically creating and deleting data or objects rather than a pool method.

Accordingly, an object of the present invention, which is designed to solve the problems of the prior art operating as described above, is a method of effectively managing the total number of resources in the pool by dividing the object or data composed of resources in the pool into a certain number of groups. To provide.

Another object of the present invention is to provide a method of generating resources in increments as many as the number in a designated group, when the resources allocated to the initial group are all in use, and then additionally assigning the pool to the pool.

It is still another object of the present invention to provide a method of deleting resources in a next group that are not needed when the resources used are returned to a pool group and the idle resources of the pool group are equal to or larger than a predetermined threshold number.

In order to achieve the above object, an embodiment of the present invention provides a method for generating an initial resource in a resource management method of managing resources in a pull manner.

Initializing the index (i) of the index identifier queue (IdQueue) and the index (j) of the idle pool group to 0 for indexing directly provided from resource allocation or return request from an external process, and ,

Increasing the i one by one to determine whether i reaches the maximum number of groups MaxGn * that can be created in the system, which is the total number of resources in memory, and the maximum number of resources MaxTn that can be created for each group;

If the i does not reach the total number of resources, the ObjPtr [i] field of the ObjPtr table to which the memory addresses of the resources generated in i are mapped is filled with null,

If i reaches the total number of resources, grouping the i numbers that have reached the total number of resources into a first idle pool group;

After storing the memory addresses of the resources generated in each of the grouped i in the ObjPool for each i, the memory address corresponding to the allocated indexId in the ObjPool [indexId] that maps the memory address of the idle resources generated by the i It is characterized by being configured to include the process of obtaining the information to configure the ObjPtr table.

Another embodiment of the present invention provides a method for allocating initial resources in a resource management method of managing resources in a pull manner.

Receiving a resource allocation request having an 'eventId' from an external processor,

Receiving a random indexId from a first idle pool group managing idle resources with respect to the eventId, and deleting the allocated indexId from the first idle pool group;

Acquiring memory address information of the corresponding indexId from the ObjPool [indexId] mapping the memory addresses of the idle resources generated for each indexId and configuring the ObjPtr table;

And checking whether all the resources of the first idle pool group are allocated, and if all are allocated, generating a next idle pool group.

Another embodiment of the present invention, in the resource management method for managing resources in a pull method, in the method for returning the initial resources,

Receiving a resource release request with 'eventId' from an external process,

When the currently assigned ObjPtr [eventId] for the 'eventId' is activated, the ObjPtr [eventId] field is accessed, transitioned to null, and an indexId corresponding to the 'eventId' is obtained, and then the resource that idles the indexId. Returning to the first children pool that manages their indexId,

Checking whether the number of IndexIds currently idle in the total allocated idle pool group is greater than the maximum number of resources (MaxTn) + MaxTn / Rn that can be created per group determined in the system;

If the IndexId is large, it is configured to include the process of deleting the resources allocated to the next idle pool group for managing idle resources.

Hereinafter, with reference to the accompanying drawings will be described in detail the operating principle of the preferred embodiment of the present invention. Like reference numerals are used to designate like elements even though they are shown in different drawings, and detailed descriptions of related well-known functions or configurations are not required to describe the present invention. If it is determined that it can be blurred, the detailed description thereof will be omitted. Terms to be described later are terms defined in consideration of functions in the present invention, and may be changed according to intentions or customs of users or operators. Therefore, the definition should be made based on the contents throughout the specification.

The present invention creates an identifier queue by the maximum number of resources that can be created within a predetermined maximum number of groups of memory of the system, and creates an initial idle pool group for managing idle resources initially. Subsequently, if all resources allocated to the initial idle pool group are in use, a next idle pool group is created, and if the number of idle resources is greater than a predetermined threshold, the next pool is returned. By deleting the resources of the group, it is possible to efficiently manage the resources of the memory.

2 is a view showing a multi-stage pool structure according to a preferred embodiment of the present invention.

Referring to FIG. 2, the pool 200 structure includes an IdQueue and an ObjPool.

The IdQueue is a queue for index information provided by an external process and an index identifier (indexId) for direct indexing. The index identifier is generated by the total number of resources that can be created in the system, that is, the maximum number of groups MaxGn * and the maximum number of resources MaxTn that can be generated for each group.

The ObjPool is composed of a plurality of pool groups 201, 202... Configured as resources as MaxTn. The plurality of pool groups 201.202 .. are composed of idle resources of the maximum number of groups MaxGn that can be created in the system, and each of the pool groups 201,202 is an index identifier grouped by MaxTn. It stores the memory address of the generated resource. The total size of the system memory 200 is MaxTn * MaxGn 214.

The pool groups 201, 202, ... are thresholds for deleting the next group defined in the system to prevent the instantaneous resource allocation and deletion processing of the next pool group due to resource return operations from the external processor. It has a range of MaxTn / Rn 212 divided by the ratio value Rn. The job return job will be described later in detail with reference to FIG. 6.

3 is a view showing a multi-stage pool structure according to a preferred embodiment of the present invention.

Referring to FIG. 3, the pool structure includes an IdQueue 300 including indexes of MaxGn * MaxTn and an event ID mapped to a table to store address addresses of memories for resources generated by the indexes. indexId].

First, the index identifier of the IdQueue 300 is allocated by MaxTn to form a first idle pool 302 group to generate resources idled by the number of MaxTn. Thereafter, the first group of the ObjPool 304 is configured by mapping the memory address (b) and the grouped index identifier (a) of each of the generated resources. Thereafter, whenever the idle pool group 302 resource allocation requested index identifier is allocated, the corresponding index identifier is deleted from the idle pool group 302, and the pool group having the idle index returned from the external processor is idle. Add to 302 again. Thereafter, the index identifier deleted from the idle pool group 302 is returned to the IdQueue 300 and reused.

ObjPtr 306 is null all of the ObjPtr [indexId] fields of the resources in the idle state, the corresponding memory address address obtained for each index identifier from the Objpool 302 when the random resource allocation request from an external processor It is stored in the ObjPtr [indexId] field. Subsequently, upon requesting any resource return from the external processor, the corresponding ObjPtr [indexId] field is transitioned back to the null state.

Next, an operation of a resource allocation request or resource return request of an external processor through the pool structure of FIG. 3 will be described in detail. Here, an event ID for requesting resource allocation or return from an external processor has a range of '1' and a maximum number of resources (MaxTn * MaxGn).

For example, when a request for allocation of a resource having an event identifier of '2' is received from an external processor, the ObjPool 304 reads & Obj (1), which is the address of memory corresponding to the index identifier 1 of the idle pool 302 group. come. Thereafter, the read & Obj (1) is stored in the ObjPtr field and the requested resource allocation is completed by deleting the index identifier 1 from the idle pool 302 group. Here, the event ID and the index ID may not match due to the allocation and deletion operations of the IdQueue.

Next, when a request for returning a resource having an event identifier of '2' is received from an external processor, the ObjPtr field of event ID 2 of the ObjPtr 306 is checked and the index identifier '1' is determined through the corresponding memory address & Obj (1). Acquire. Thereafter, the ObjPtr field of the event ID 2 is changed to null, and the return operation is completed by returning the obtained index identifier 1 to the idle pool 302 group.

4 is a flowchart illustrating an initial pool resource creation operation according to a preferred embodiment of the present invention.

Referring to FIG. 4, in step 402, the index identifier, i, and j of the IdQueue are initialized to zero. In this case, i is a resource (Tn) index of the IdQueue in the memory, j is an index of the pool group (Gn) in the memory.

In step 404, i is increased by one, and in step 406, it is determined whether i reaches the total number of resources MaxGn * MaxTn of the memory. If i does not reach the total number of resources, in step 408, the ObjPtr [i] field mapped to the i is filled with null and the flow returns to step 404.

If i reaches the total resource number value, since the MaxTn idle resources are grouped, the first pool group (j = 1) is created in step 410. In step 412, the memory receives index identifiers from the IdQueue, maps them to IndexId values of the ObjPool, and stores the memory addresses of resources generated for each indexId in the ObjPool. Subsequently, an ObjPtr [i] table is mapped to the corresponding i which sequentially stores the address address obtained through the ObjPool.

In step 414, the ObjPool determines whether resources in the first pool group are generated by MaxTn. If the resource is generated as much as MaxTn as a result of the checking, the operation ends. If the resource is not generated as much as MaxTn as a result of the checking, the process returns to step 412.

5 is a flowchart illustrating the allocation of pool resources according to a preferred embodiment of the present invention.

Referring to FIG. 5, in step 502, the memory receives a resource allocation request with 'eventId' from an external processor. At this time, the eventId has a range between '1' and 'MaxGn * MaxTn'.

In step 504, the memory is assigned one indexId idle in the first idle pool group with respect to the eventId, and deletes the allocated indexId in the idle pool group. In step 506, the memory indexes ObjPool [indexId] with the allocated indexId, obtains address information on the corresponding indexId resource, and stores the information in the ObjPtr [eventId] to actually access the information inside the resource. .

By performing steps 504 to 506, mapping processing is performed between the eventId designated by the external processor and the IndexId designated inside the pool, so that any number of resources in the currently allocated group can be allocated even if any eventId is specified.

Thereafter, in step 508, the memory checks whether all resources of the idle pool group are allocated by the continuous external processor request. If all resources are allocated to the last resource as a result of the check, in step 510 where j is 0, the memory proceeds to step 512 to add 1 to j to designate a next idle pool group.

In step 514, the memory receives index identifiers from the IdQueue, maps them to the IndexId value of the next idle pool group in the ObjPool, and stores the memory address of the resource generated for each indexId in the ObjPool. Thereafter, an ObjPtr [i] table is mapped to the corresponding i which sequentially stores the address address obtained through the ObjPool.

In step 516, the ObjPool determines whether resources in the first pool group are generated by MaxTn. If the resource is generated as much as MaxTn as a result of the checking, the operation ends. If the resource is not generated as much as MaxTn, the process returns to step 514.

6 is a flowchart illustrating a pool resource return and unnecessary resource deletion according to a preferred embodiment of the present invention. Here, the first idle pool group and the next idle pool group are taken as an example.

Referring to FIG. 6, in step 602, the memory receives a resource release request with 'eventId' from an external process. In step 604, the memory determines whether the currently allocated ObjPtr [eventId] for the 'eventId' is active, that is, whether there is an address address of the memory for the corresponding resource. If the determination result is not activated, the process proceeds to step 608.

If the determination result is activated, in step 606, the memory accesses the ObjPtr [eventId] to obtain an indexId corresponding to the 'eventId'. Thereafter, the indexId is returned to the first idle pool group, and the ObjPtr [eventId] is changed to null to indicate that the corresponding resource has been normally returned.

When the resource return processing for the corresponding eventId is finished, the memory checks the number of currently idle IndexIds in the total allocated idle pool groups, and in step 610, the number of IndexIds idle is greater than the number of (MaxTn + MaxTn / Rn). Make sure it's big. Here, the total allocated children pool group is the first idle pool group and the next idle pool group, and the Rn value is a value appropriately set according to the system.

As a result of the check, when the number of IndexId is less than or equal to the number of (MaxTn + MaxTn / Rn), the return operation is terminated.

If the IndexId is greater than (MaxTn + MaxTn / Rn), the i in the next idle pool group is examined in step 612 to delete resources allocated to the next idle pool group.

In step 614, it is checked whether i is smaller than MaxTn. If the check result is small, in step 616, the resources stored in the ObjPool [indexId] corresponding to i are deleted and returned to idQueue. In step 618, the value 1 is increased to i, and the process returns to step 614.

If the i is greater than or equal to MaxTn, the return operation ends because all resources of the next idle pool group are deleted.

Therefore, as shown in step 610, when the number of indexIds remaining in the idle pool is greater than the MaxTn + MaxTn / Rn value, the resource in the next idle pool group is deleted to limit the rapid allocation and deletion of resources in the pool of memory. Thereafter, the indexIds of the deleted resources are returned to the IdQueue and reused. As described above with reference to FIG. 2, Rn is a threshold ratio value predetermined to delete the next group determined in the system so as to prevent the instantaneous resource allocation and deletion processing of the idle pool group.

For example, suppose that MaxTn is 2000 for each idle pool group, and 2 idle pool groups are allocated. If Rn is set to 4, 2000 resources are allocated to each of the two pools of pools, but the total number of idle resources in the pool of idle pools is increased to 2500 or more due to a request for return from an external processor. .

Then, if the idle resource in the idle pool group is 2500 or more, which is 2000 + 2000/4, 2000 resources of the next idle group can be deleted, thereby preventing instantaneous resource allocation and deletion processing.

Meanwhile, in the detailed description of the present invention, specific embodiments have been described, but various modifications are possible without departing from the scope of the present invention. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be defined not only by the scope of the following claims, but also by those equivalent to the scope of the claims.

In the present invention operating as described in detail above, the effects obtained by the representative ones of the disclosed inventions will be briefly described as follows.

According to the present invention, the resources of the initial memory are divided into groups by a predetermined number so that the resources of the next group are gradually added and allocated to the pool only when the resources of the initially allocated pool are all allocated. If the number of resources in the next group falls below a predetermined threshold due to the return operation of, the system memory that resources can occupy can be efficiently managed by deleting resources in unnecessary groups.

Claims (15)

In the resource management method for managing resources in a pooled manner, In the method for creating an initial resource,  Initializing the index (i) of the index identifier queue (IdQueue) and the index (j) of the idle pool group to 0 for indexing directly provided from resource allocation or return request from an external process, and , Increasing the i one by one to determine whether i reaches the maximum number of groups MaxGn * that can be created in the system, which is the total number of resources in memory, and the maximum number of resources MaxTn that can be created for each group; If the i does not reach the total number of resources, the ObjPtr [i] field of the ObjPtr table to which the memory addresses of the resources generated in i are mapped is filled with null, If i reaches the total number of resources, grouping the i numbers that have reached the total number of resources into a first idle pool group; After storing the memory addresses of the resources generated in each of the grouped i in the ObjPool for each i, the memory address corresponding to the allocated indexId in the ObjPool [indexId] that maps the memory address of the idle resources generated by the i Obtaining information and configuring a corresponding ObjPtr table.  The method of claim 1, wherein the IdQueue, MaxGn * Method consisting of the indexes generated by MaxTn. The method of claim 1, wherein the ObjPtr table, And an ObjPtr [eventId] field for storing the i-specific memory address information, and an eventId indexing the ObjPtr [eventId] field. In the resource management method for managing resources in a pooled manner, in the initial resource allocation method, Receiving a resource allocation request having an 'eventId' from an external processor, Receiving a random indexId from a first idle pool group managing idle resources with respect to the eventId, and deleting the allocated indexId from the first idle pool group; Acquiring memory address information of the corresponding indexId from the ObjPool [indexId] mapping the memory addresses of the idle resources generated for each indexId and configuring the ObjPtr table; Determining whether all of the resources of the first idle pool group are allocated, and if all are allocated, generating a next idle pool group. The method of claim 4, wherein the first group of children pools, The maximum number of resources that can be created for each group defined in the system are the index information (Tn) of the index identifier queue (IdQueue) for direct indexing and the index information provided when requesting resource allocation or return from an external process ( Generated by grouping by MaxTn). The method of claim 5, wherein the IdQueue, Maximum number of groups (MaxGn) that can be created in the system * characterized in that consisting of the index created by the MaxTn. The method of claim 6, wherein the eventId is, And a range from '0' to MaxGn * MaxTn. The method of claim 5, wherein the generating of the next idle pool group comprises: Receiving an index (i) of idle resources equal to MaxTn from the IdQueue, and grouping the index id of the next idle pool group in the ObjPool; And storing memory addresses of idle resources generated for each of the grouped indexIds in the ObjPool, and then obtaining memory address information of the corresponding indexId to construct a corresponding ObjPtr table. The method of claim 8, wherein the grouping process comprises: And IndexIds excluding an IdenxId allocated to the first idle pool group from the IdQueue. The ObjPtr table according to claim 4, wherein And an ObjPtr [eventId] field for storing the memory address information for each indexId, and an eventId for indexing the ObjPtr [eventId] field. In the resource management method for managing resources in a pooled manner, the method for returning initial resources, Receiving a resource release request with 'eventId' from an external process, When the currently assigned ObjPtr [eventId] for the 'eventId' is activated, the ObjPtr [eventId] field is accessed, transitioned to null, and an indexId corresponding to the 'eventId' is obtained, and then the resource that idles the indexId. Returning to the first children pool that manages their indexId, Checking whether the number of IndexIds currently idle in the total allocated idle pool group is greater than the maximum number of resources (MaxTn) + MaxTn / Rn that can be created per group determined in the system; And deleting the resources allocated to the next idle pool group managing idle resources if the IndexId is large. The method of claim 10, wherein Rn, And a threshold ratio determined in advance to delete the next group determined in the system so as to prevent the instantaneous resource allocation and deletion processing of the idle pool group. 11. The method of claim 10 wherein the total assigned idle pool group, And said first idle pool group and said nonnest idle pool group. The ObjPtr [eventId] field is And storing the memory address information for each indexId, and included in an ObjPtr table including an eventId for indexing the ObjPtr [eventId] field. The method of claim 10, wherein the 'eventId' is required to release the resource, A method characterized in that returned to the resource (Tn) index (i) of the index identifier queue (IdQueue) for direct indexing and index information provided when the resource allocation or return request from the external process.

Images