JPS63245530A - Shared resource pool managing system - Google Patents

Abstract

PURPOSE:To reduce queuing at the time of reserving a shared resource by providing a shared resource management mechanism which permits declaration of the number of shared resources for frequent use at the time of declaring said number by a certain program unless this number exceeds a maximum value. CONSTITUTION:When a user application program (AP) 140 declares the number of shared resources for frequent use, a shared resource management mechanism 130 permits this declaration unless a number 114 of all shared resources for frequent use in a pool management table 110 exceeds a maximum number 115 of shared resources for frequent use, but the mechanism 130 rejects the declaration if the number 114 exceeds the maximum number 115. Permitted and reserved shared resources for frequent use are inhibited from being used by the other APs, and idle shared resources are used as shared resources for frequent use. Queuing at the time of reserving shared resources is suppressed by this management based on the maximum number of shared resources for frequent use.

Description

[Detailed Description of the Invention] [Field of Industrial Application] The present invention relates to a shared resource pool management method, and in particular, to a management program and a user AP (application program).
When managing pools such as inter-process shared resources for exchanging information between groups, if you do not want a specific user AP to wait unnecessarily, you can declare the number of resources required in advance. Even when user APs other than the AP are using a large number of shared resources, it is possible to prevent queuing when securing resources as much as possible, and furthermore, user APs can freely execute procedures for securing and returning resources even if they are not specified in the declaration of necessary resources. Shared resource pool management method % formula % [Prior art] A program that manages online called a management program and multiple user APs that use the online function.
In an information processing system, etc., in which there are two processes, and the user APs are processes that operate independently of each other, but the management program and each user AP operate in relation to each other.
Shared resources for data exchange between the management program and the user AP are managed in a pool.

The conventional pool management method for inter-process shared resources as described above will be explained in detail with reference to FIG.

In FIG. 5, 500 is a free inter-process shared resource on the inter-process shared memory (not shown), 501 is a resource link field for grouping free resources, and 510 is a pool management table for free resources. 51
1. Total number of resources: 512. It manages the number 513 of free resources existing in the resource pool. Further, 520 is a shared resource management mechanism that manages these. On the other hand, 530 is a user AP that actually uses the shared resources, and has a resource pointer 531 for remembering the secured resources. Further, 502 is an allocated shared resource.

The conventional shared resource pool management method was performed as follows.

The inter-process shared memory in which shared resources are stored is a limited resource not only for the online system described below, ie, the management program and user AP group, but also for the entire computer system.

For this reason, the amount of shared memory that can be used in an online system is limited depending on the purpose for which the combiator system is operated. Shared resource management mechanism 5 at startup of this online system
As for the process 20, first, it is determined how much shared memory is required for this online system, and then the shared resources that the online system actually uses are allocated. That is, the total number of resources 512 in the pool management table 510 is determined during the initial setting process, each free shared resource 500 is listed pointing to another resource in the resource link field 501, and the resource pool link 511 is linked to this free shared resource 500. Points to the list of shared resources 500, of course the number of free resources 513 is the total number of resources 51
The same value as 2 is set.

When a user AP 530 occurs and requires a shared resource, the user AP 530 issues a resource reservation request to the shared resource management mechanism 520. At this time, the shared resource management mechanism 520
checks the number of free resources 513 in the pool management table 510, and if this value is greater than O, removes one free shared resource 500 from the resource pool link 511, which is a resource on the list connected to the resource pool link 511. This is accomplished by removing one shared resource from the resource pool list by updating the resource link field 501 and resource pool link 511 of the shared resource. At the same time, the number of free resources 513 is decreased by 1.

The user AP 530 uses the shared resource management mechanism 52 as described above.
As a result of processing 0, a shared resource 502 can be obtained.

The shared resources 502 obtained in this way must be returned after the appropriate online processing has been executed. For this reason, a mechanism is required within the user AP to remember the shared resources that have been secured. , here, as mentioned above, the shared resource 5 secured in the secured resource pointer 531 is
02 pointer is set.

The user AP will utilize the resource pointer 531 and return the resource after the online processing is completed. When a return request is issued to the shared resource management mechanism 520, the shared resource management mechanism 520 adds this shared resource 502 to the list on the resource pool link 511 and increases the number of free resources 513 by one.

In addition to these basic operations, the shared resource management mechanism 520 performs waiting control when there are no free resources. In other words, the user AP 530 uses resources! When the reservation request is issued, if the number of free resources 513 in the pool management table 510 is O, the reservation request is put on hold. Furthermore, when another user AP issues a resource return request, the shared resource management mechanism 520 checks whether there is any pending request, releases the pending request if any, and returns the request to that user AP. Give resources.

Because this kind of waiting control based on waiting for resources works,
When a user AP performs online processing, it is always conceivable that a waiting session will occur. On the other hand, depending on the function of the user AP, it may be a problem if such a waiting occurs.

In order to prevent waits from occurring, resource management is performed such as securing the required number of resources in advance, and using the resources reserved in advance by the user AP itself when performing online processing, that is, when the resources are needed. The need to do so arises.

[Problem that the invention seeks to solve]

In the conventional shared resource management method described above, a user AP that does not want to cause a wait has to manage the resources reserved in advance by itself. In such a case, the processing form in the user AP to avoid waiting due to pending requests when securing resources is to secure resources,
Instead of the usual form of repeating a series of three processes: online processing and resource return, it is necessary to take the form of securing resources, repeating online processing, and returning resources. That is, if the necessary resources are secured in advance, there is no need to worry about waiting for resources each time an actual online process is performed, so the overall execution speed is improved from this point of view.

However, in this case, the two processes of resource return and resource reservation are not executed every time online processing is executed, and the time from resource reservation to resource return becomes extremely long. If an abnormal termination occurs during the process, there is a high possibility that a path will not be returned.

In addition, when a resource other than the one reserved in advance is required, and it is acceptable for a wait to occur, the user AP checks whether the reserved resource is left over or not. Always judge, and if you don't have enough, use funds aW!
Complicated processing such as having to issue a maintenance request becomes necessary.

In addition, if some user APs secure too much shared resource without permission, it will be difficult to return it, and other user APs waiting for the shared resource will be unable to operate at all for a long time.

The present invention aims to solve the drawbacks of such conventional methods.

[Means for solving problems]

In order to solve the above-mentioned conventional drawbacks, the present invention provides a shared resource pool management system for managing a plurality of shared resources when a plurality of shared resources are shared by programs such as a plurality of user APs. When the number of frequently used shared resources is declared by a program, this shared resource management mechanism shall manage the declared number of frequently used shared resources on the condition that the total number of frequently used shared resources does not exceed the predetermined maximum number. The number of frequently used shared resources is reserved for the program that declared it so that it cannot be used by other programs, and the number of frequently used shared resources reserved by the above declaration is used up. In response to a request to secure a shared resource and a request to secure a shared resource issued from a program that does not make the above declaration, the system is configured to allocate a shared resource from among the available shared resources that are not secured as frequently used shared resources. .

[Effect]

The shared resource management mechanism manages the number of frequently used shared resources for each user AP, and when the user AP declares the number of frequently used shared resources, the shared resource is controlled so that this amount of shared resources cannot be secured anywhere else. have.

As a result, when securing resources within the declaration, it is possible to prevent the shared resource management mechanism from having to wait due to pending requests in the securing process.

In this way, by centrally managing the allocated number of shared resources as the number of frequently used shared resources, all frequently used shared resources The shared resource management mechanism can accept or reject declarations based on this number, and this allows user APs that have not made declarations to use vacant shared resources other than those reserved as frequently used shared resources. Resources can be used. Furthermore, even if the resource is on standby, the resource can be secured if another user AP that is securing the resource completes processing such as online processing and returns the resource, and the waiting time for securing the resource does not take a long time. This means that even if you fail to declare the number of frequently used shared resources, or even if you do not declare them at all, you can receive resource management, online processing, online services for resource return, etc. with minimal waiting. This means that the user AP can use the functions of securing and returning resources even in a form that does not depend on declarations.

Further, the user AP can receive online services in the form of resource reservation, online processing, and resource return. This means that it becomes possible for a system such as an online system to provide a means for implementing these three processes to the user AP as one means by macro definition. In this way, the user AP
can be created without having to worry about shared resource management at all, and in addition, as long as the user AP declares the number of frequently used shared resources, it can be created so that it does not have to secure shared resources at all when performing online processing, etc. It becomes possible.

〔Example〕

(1) Next, embodiments of the present invention will be described in detail with reference to the drawings.

Referring to FIG. 1, one embodiment of the present invention includes free interprocess shared resources axoo having a resource link field 101 for grouping free resources into a free resource pool, and resource pool links 111 . Total number of resources: 112. Number of free resources in the resource pool: 113. Total number of frequently used shared resources: 11
4 and a pool management table 110 for free resources having a maximum number of all frequently used shared resources 115, and a user AP identification name 121.
．． Number of shared resources for J: 122. A plurality of user AP management tables 120 having the number of shared resources secured 123 and a secured resource list 124, a shared resource management mechanism 130 that further manages these, and user APs that actually use these resources.
140 and a shared resource 10 allocated to a certain user AP
2 and the allocated shared resources 102 are grouped together in a resource link field 103.

The system determines the number of inter-process shared resources that can be shared, and calculates this number as the total resource number 11 in the pool management table 110.
2 and the number of free resources 113, and this number of shared resources is created and the resource link field 101 is registered in advance.
A list is formed and linked in the pool management table 110 by the following steps. In addition, the maximum allowable total number of frequently used shared resources declared by all user APs is registered in the maximum number of all frequently used shared resources 115 of the pool management table 110, and this number must be greater than or equal to the total number of resources 112. The total number of frequently used shared resources 114 should not be 0. The user AP management table 120 is initialized so that it is all unused. For this reason, all the user AP identification names 121 in each user AP management table 120 are stored with impossible values as user API aliases.

(2) Next, the operation of this embodiment will be explained with reference to the drawings.

(2-1) The operation when the user AP 140 declares the number of frequently used shared resources to the shared resource management mechanism 130 is as follows.
This will be explained using FIG.

When the shared resource management mechanism 130 receives the declaration from the user AP 140, it first searches among the plurality of user AP management tables 120 for the user AP whose user AP identification name 121 indicates the user AP that issued the request (processing). 201), and then determines whether the search was successful or not. 202)
, if successful, the process advances to step 207; if unsuccessful, the user AP management table 120 is selected.
A search is made for a user AP management table in which the identification name 121 has an impossible value, that is, an unused user AP management table (process 2o3). Then, it is determined whether the search was successful or not (process 2o4), and if it is unsuccessful, the request for declaration of the number of frequently used shared resources from user A P 140 is rejected (process 2o5).
. If found, the frequently used shared resource number 122 and shared resource secured number 123 are set to 0 in the found user AP management table (process 206).

In process 207, the shared resource management mechanism 130 adds the number of declarations from the user AP and the total number of frequently used shared resources 114 in the pool management table 110, and from this added value, the resource searched in process 201 or process 203 is performed. A value is calculated by subtracting the number of frequently used shared resources 122 in the user AP management table, and it is determined whether this value is larger than the maximum number of all frequently used shared resources 115 in the pool management table 110. If so, the shared resource management mechanism 130 rejects the user AP 140's request for declaration of the number of frequently used shared resources (processing 20B).

When the conditions of process 207 are satisfied and the request is accepted, the shared resource management mechanism 130 adds the declared number to the total number of frequently used shared resources 114 in the pool management table 110 (process 20
9) At the same time, the number of free resources in the pool management table 110 is 1.
13 (processing 210), and for the found user AP management table 120, the user A specific to the user AP 140 that issued the declaration request.
Set P identification name to user AP11i alias 121 (
Processing 211).

Furthermore, the number of frequently used shared resources 122 in the above user AP management table is subtracted from the total number of frequently used shared resources 114 in the pool management table 110, and the number of free resources 113 is added to the number of frequently used shared resources 1.
After this, the declared number is set in the number of frequently used shared resources 122 of the user AP management table, and the process of declaring the number of frequently used shared resources is completed (process 212).

Note that in order for the user AP to cancel the declaration of the number of frequently used shared resources, it is sufficient to declare that the number of frequently used shared resources is 0.

(2-2> Next, the operation when the user AP 140 issues a shared resource securing request to the shared resource management mechanism 130 will be described using FIG. 3.

When a shared resource reservation request is given from the user AP 140, the shared resource management mechanism 130 first
In the management table 120, the user AP identification name 121
searches for something that indicates the user AP that issued the request (process 301), and then determines whether the search was successful or not (process 302). If successful, the process advances to process 307; if unsuccessful, it is time to manage multiple user APs. A user AP management table 120 in which the user AP identification name 121 has an impossible value is searched for in the table 120 (process 303). Then, it is determined whether the search was successful or not (process 304), and if it is unsuccessful, the shared resource reservation request from the user API 40 is rejected (process 305), and if it is found, the frequently used shared resource is Number 1
22 and the number of reserved shared resources 123, and sets the user AP identification value to the user API III alias 121 (process 306), and then proceeds to process 307.

In process 307, the shared resource management mechanism 130 compares the number of frequently used shared resources 122 and the number of secured shared resources 123 in the user AP management table 120 found in process 301 or process 303. If the number of reserved shared resources 123 does not exceed the number of frequently used shared resources 122, the process advances to process 311, and if it is greater than that, the number of free resources 113 in the pool management table 110 is checked (process 308).
). If the number of free resources 113 is 0, there are currently no resources that satisfy the reservation request, so this request is put on hold (
Processing 309). Note that existing technology can be used for the reservation method.

On the other hand, if the number of free resources 113 is greater than O, 1 is subtracted from it (process 310). Then, the process advances to process 311.

In process 311, the shared resource management mechanism 130 removes one shared resource from the list of free shared resources 1xoo connected to the resource pool link 111 in the pool management table 110, and takes this as the result of the reservation request. This removed shared resource, that is, the shared resource 102 in FIG. 1, is the reserved resource list 12 in the user AP management table 120.
Connect to 4. And user AP management table 120
At this time, the number of shared resources 123 is increased by 1 (processing 31
1).

The above two controls in the shared resource management mechanism 130,
That is, the frequently used shared resource number declaration system i (Figure 2) and the shared resource reservation control (Figure 3) update the number of free resources 113 while taking into account the total number of declarations, that is, the total number of frequently used shared resources 114 at the time of declaration. As a result, when there are few free resources, resource reservation for other user APs and declaration of the number of frequently used shared resources are restricted. As a result, the user AP 140 that has successfully declared the number of frequently used shared resources will not have to wait to secure resources until it declares again.

(2-3) In this example, the above (2-1), (
In addition to the two controls described in 2-2), the shared resource management mechanism 130 is provided with shared resource return request control. Next, this return request control will be explained using FIG. 4.

When the user AP 140 issues a shared resource return request, the shared resource management mechanism 130 first searches among the multiple user AP management tables 120 for the user AP identification name 121 that indicates the user AP 140 that has issued the request. Then, it is determined whether the search was successful or not (process 402), and if it is unsuccessful, the shared resource return request from the user AP 140 is rejected (process 403). On the other hand, when the search is successful, it is checked that the number of shared resources secured 123 is greater than 0 in the searched user AP management table 120, and the secured resource list date 24 is checked to see if the resource requested to be returned is included therein. (Process 404)
. If it is false, the shared resource return request is rejected (process 403).

Next, if it is true in process 404, the found user AP
In the management table 120, the number of frequently used shared resources 122 and the number of secured shared resources 123 are compared (processing 405).

If the number of shared resources secured is 123, then the number of frequently used shared resources is 1.
If the number is greater than 22, the process 406) increases the number of free resources 113 in the pool management table 110 by 1, and the process proceeds to the next process 407; otherwise, the process immediately proceeds to process 407.

In process 407, the shared ff source management mechanism 130
The returned resources are connected as a list to the resource pool link 111 in the pool management table 110, removed from the secured resource list 124 in the user AP management table 120, and the shared resource secured number 123 is decreased by 1 (processing 407).

After this, the number of shared resources secured is 123 and the number of frequently used shared resources is 12.
2 are both 0 (process 408), and if so, the user AP identification name 121 is set to an unused state as an impossible value (process 409).

Finally, if the number of free resources in the pool management table 110 is 1
User A whose 13 is greater than 0 and whose reserved resources are pending
If there is P, retry the securing process in Figure 3 (processing 4
10).

〔Effect of the invention〕

As explained above, in the present invention, the shared resource management mechanism necessary for online processing etc. is provided with a function that can declare in advance the number of shared resources that programs such as user APs will use simultaneously.
By controlling the number of unused shared resources from this number of declarations, the following effects can be obtained.

+11 A program that successfully declares the number of frequently used shared resources can use resources within the range of the declared number! This eliminates the need to wait for other programs to return resources due to no unused resources when making a reservation request.

(2) Programs such as user APs no longer have to separately control online processing and resource securing/return control in order to avoid resource securing, and online processing and resource control are performed together. By eliminating or minimizing the need for securing resources, it becomes possible for the management side for online processing to prepare a macro means that combines online processing and resource control. Therefore, programs such as user APs do not need to consider the resource management function at all except for declaring the number of frequently used shared resources, and the descriptive and maintainability of programming is improved.

(3) Since the shared resource management mechanism performs control in advance to prevent other programs from securing resources as belonging to a program such as a specific user AP, it is no longer possible for a specific program to monopolize all resources. In other words, by limiting the total number of frequently used shared resources, it is possible to define shared resources that will not be monopolized, and even programs that do not declare frequently used shared resources or programs that fail to declare them can have minimal waiting time when securing resources. can be suppressed. That is, a program such as a user AP can be constructed without depending on frequently used shared resource declarations.

[Brief explanation of drawings]

Fig. 1 is a configuration diagram of an embodiment of the present invention, Fig. 2 is a flowchart showing an example of processing by the shared resource management mechanism when a request for declaring the number of frequently used shared resources is received, and Fig. 3 is a request for securing a shared resource. The first part is a flowchart showing an example of processing by the shared resource management mechanism at the time of use. Figure 4 is a flowchart showing an example of processing by the shared resource management mechanism at the time of receipt of a shared resource return request. FIG. In the figure, 100...free shared resource, 101.1
03... Resource link field, 102... Allocated shared resource, 110... Pool management table, 1
20... User AP management table, 130... Shared resource management mechanism, 140... User AP.

Claims (1)

[Scope of Claims] A shared resource pool management method when a plurality of shared resources are shared by a plurality of programs, comprising a shared resource management mechanism for managing the plurality of shared resources, the shared resource management mechanism comprising: When the number of frequently used shared resources is declared by the program, the declared number of frequently used shared resources is sent to the source of the declaration, provided that the total number of frequently used shared resources does not exceed the predetermined maximum number. In addition, requests to secure shared resources from programs that have used up the number of frequently used shared resources secured by the above declaration, and from programs that do not make the above declaration. A shared resource pool management method characterized in that a shared resource reservation request issued is allocated from among the vacant shared resources that are not secured as the frequently used shared resources.