JPH07120333B2 - Shared data management method - Google Patents

Description

Description: FIELD OF THE INVENTION The present invention relates to a lock system, and more particularly to a lock system for sharing files between CPUs.

[Background of the Invention]

The system that shares files between CPUs tends to increase more and more, and the processing performance of the general lock manager that manages the shared files becomes important. Generally, there is one lock manager that manages a set lock of certain data.
Otherwise, the consistency of the data cannot be maintained, so even if the database is shared between CPUs, there must be one lock manager for the set of data (however, the data to be managed Managers may be different for different sets of). Since a user task group that issues a lock request exists in each of a plurality of CPUs, the lock manager can be used to determine which hardware (a specific CPU (1) or an I / O control device (2). ) Etc.), communication occurs between different hardware (CPU with lock request and hardware with lock manager) (however,
Except when a set of data is accessed only by a user task on one particular CPU, but in this case, since the data is not shared between CPUs, it may be excluded from consideration.) . At this time, the program that accepts the lock request of the user task in each CPU and sends it to the lock manager is called the local lock manager. The lock manager that manages the lock of the shared data described above is the globalized lock manager. Call. The communication costs between the local lock manager and the global lock manager are often much higher than in conventional systems that do not share databases, because the hardware is often different.

In the case of data with high access frequency such as an index, unless the lock unit is made thin, the multiplicity cannot be increased. A normal lock unit is a page (transfer unit between the main memory and the I / O side), so in the case of an n-stage index, lock requests are issued n times, so communication between managers occurs n times. Will be done. Since this communication cost becomes very large, it is necessary to consider some measures.

[Object of the Invention]

The object of the present invention is to solve such conventional problems,
An object of the present invention is to provide a lock method capable of reducing the communication cost between lock managers and reducing the communication cost when the databases are shared.

[Outline of Invention]

In order to achieve the above object, according to the present invention, a general lock manager that centrally manages locks of shared data and a local lock manager provided corresponding to a plurality of user task groups are provided. When a lock mode that allows acquisition of another lock mode for data to which an arbitrary lock mode is applied is selected and a mode lock acquisition and release request for a certain lock resource is made, Lock·
It is characterized by processing the request in the local lock manager that receives it directly from the tasks in the user task group without sending it to the manager.

Example of Invention

Hereinafter, the principle and embodiments of the present invention will be described in detail with reference to the drawings.

First, the principle of the present invention will be described.

Normally, several types of lock modes are prepared to increase concurrency, but the lock mode used is determined by the contents of access (reference, update, add, delete) (lock protocol). At this time,
There is a lock mode that can be applied to certain data with a very high probability, and that mode can coexist with the mode itself (when the lock mode is set to a, a user task locks data in mode a). When you are wearing
If another user task tries to lock the same data in mode a, the access right is granted.) If there is no request to set a mode, it is possible to always lock the mode. This eliminates the need for communication between the global lock manager and the local lock manager when the user task issues a lock request in the default mode, and the number of communication between managers can be reduced.

This locking method is called the default mode locking method in the following.However, this method is effective not only for hardware configurations that support the CPU-to-CPU database method but also for other configurations, so it is considered to have a wide range of applications. To be

In order to maintain data consistency, it is generally necessary to centralize lock management for the same set of data in one place.

FIG. 5 is a block diagram of a computer system that shares data between CPUs.

In this case, a processing request that uses data exists on each CPU 50, and a mechanism for integrally managing shared data is provided in any of them. This may be an existing installation. FIG. 1 is a software configuration diagram of the lock management system in such a case.

In the present invention, it is not necessary to limit the hardware configuration, and hence it is not particularly conscious of a clear hardware configuration.

Global Lock Manager (abbreviated as GLM below) 1
0 centrally manages locks on shared data. on the other hand,
Each local lock manager (hereinafter referred to as LLLM)
11 receives the lock request from the corresponding user task group 12 and transmits this to the GLM 10.

The LLM 11 receives the lock request from the corresponding user task group 12.

As shown in FIG. 1, there are two or more arbitrary pairs of LLM 11 and user task group 12. Communication between the GLM and each LLM is performed by known means. The same applies to the user task group 12 and the LLM 11. In this case, user task group 12 and LLM11
Can be considered to be on the same CPU. The GLM 10 does not limit on which device it is (or a new device may be provided). Further, the GLM 10 and each LLM 11 are generally assumed to be on different devices, but they are not limited to such. However, in order to exert the effect of the present invention, in comparison with the communication cost of the LLM 11 corresponding to the user task group 12, at least one set of GLM 10 in the communication cost between the plurality of pairs of GLM 10 and each LLM 11. And the communication cost of LLM11 needs to be high. For example, if the communication cost between the GLM 10 and one LLM 11 is larger than the communication cost between the user task group 12 and the LLM 11, the communication cost between the GLM 10 and another LLM 11 does not have to be large. However, the effect of the present invention is greater when the communication cost of all pairs of GLM10 and LLM11 is higher.

In general, there are a plurality of lock modes, and the coexistence relationship between these lock modes is defined as a binary logic function. This means whether one user task locks a lock unit in mode a, while another user task attempts to lock in mode b, the latter lock is allowed. It is expressed by binary logic. If the lock is recognized, b is said to be compatible with a. Here, this is expressed as a function as follows.

When compatible: COMPAT (b, a) = true When not compatible: COMPAT (b, a) = false (function of COMPAT (a, a) is also defined) COMPAT (a, b) ≠
COMPAT (b, a) may be used. For example, a function may be defined such that lock mode a is allowed to be applied when lock mode b is applied, but the opposite case is not allowed. When COMPAT (a, b) = COMPAT (b, a) = true, a and b are said to be compatible with each other. Regarding lock mode a and lock mode b, COMPAT (r, b) = (true) (1) for the following two conditional expressions, COMPAT (r, a) = true for all lock modes r , And all lock modes s with COMPAT (a, s) = true
On the other hand, when both COMPAT (b, s) = true (2) are satisfied, lock mode b is said to be less exclusive than lock mode a.

In order to reduce the number of communication between the GLM 10 and each LLM 11 that centrally manages the lock of data, the present invention provides a lock
A mode is defined, and this mode is hereinafter referred to as a lock mode a. However, if there is no lock request to apply a lock mode other than the lock mode a, the lock mode a is always the default mode. As mentioned above, the present invention relates to a method for managing locks. At this time, the following effects can be obtained by the present invention if the following equation is satisfied.

COMPAT (a, a) = true If a lock other than mode a is not applied, it means that lock mode a is applied, and the locks between modes a are compatible. Access will always be granted. Therefore, when the lock acquisition of the lock mode a is received from the user task group, the LLM 11 may grant the access right without communicating with the GLM 10. For the same reason, the release request does not have to be transmitted to GLM10. As a result, the number of times of communication between the LLM11 and GLM10 can be reduced.

Further, it is not only the lock mode a that needs to notify the GLM10 of the lock acquisition / release notification, and the lock mode a is a set of less exclusive modes, that is, the lock mode of all lock modes. The present invention can also be applied to the case of the lock acquisition / release notification of the mode belonging to the set of lock modes that satisfy the expressions (1) and (2) for the mode a. Where X is the set of all lock modes
Let Y be the set of less exclusive lock modes than a. GL for lock mode acquisition / release requests belonging to Y
The reason why it is not necessary to inform M10 is that it is in lock mode a, which is equivalent to or more exclusive of these lock modes, or is in the default mode (a is in Y). Note that it is included).

On the other hand, in the case of the mode belonging to the set XY (the set of all modes excluding the set of modes belonging to Y), among the user task groups issuing the lock request to another LLM Since it is necessary to check the compatibility of the task with the lock request, the lock request notification must be sent to GLM10.

The GLM 10 receives only lock requests in modes belonging to the set XY. In this case, the GLM 10 needs to classify the request according to whether the mode of the received lock request satisfies the following equation. The mode of the received lock request is b.

COMPAT (b, a) = true and COMPAT (a, b) = true (3) The necessity of classification is described below. If the lock mode does not satisfy the expression (3), the lock modes belonging to the set Y
Not compatible with modes. Therefore, in this case, in order to acknowledge this lock request, it is necessary to release all the lock requests in mode a (COMP
AT (b, a) = false), after accepting this lock request, it will not accept the lock request of mode a (when COMPAT (a, b) = false) until it is released. After such a lock request is issued, each LLM cannot unconditionally accept the lock request of the mode belonging to the set Y from the corresponding user task group.

Therefore, when the GLM 10 receives the lock request in the mode that does not satisfy the expression (3), it needs to notify all the LLMs to that effect. Let Z be a set that does not satisfy equation (3). From equations (1), (2), and (3), the following equation holds.

Y∩Z = φ (φ: empty set) (4) When the expressions (3) are satisfied, that is, in the case of the lock request of the mode belonging to XYZ, it is compatible with the lock request of the mode belonging to set Y. Therefore, only the lock requests belonging to the set XY, that is, only the lock requests sent from each LLM11 to the GLM10 are taken into consideration without considering the processing request of the lock request in the set mode accepted by each LLM11. The presence or absence of the access right can be determined in consideration of.

From the above, the lock acquisition and release methods for each set of lock modes are summarized as follows.

In the case of a lock request of a mode belonging to set Y: When the LLM that receives the lock request accepts another lock request having a mode belonging to set Y and all LLs
The acquisition of the lock may be permitted in consideration of the lock request of the mode belonging to the set Z accepted by M. Therefore, all
If the lock acquisition / release request of the mode belonging to the set Z received by the LLM 11 is received via the GLM 10, it is possible to determine whether the lock acquisition request is accepted in the LLM 11 that has received the lock request. Further, the release request can be processed only by the LLM 11 that has accepted the request.

In the case of a lock request in a mode belonging to the set XYZ: In this case, it is sufficient to consider a set of lock requests in a mode belonging to the set XY in the GLM 10.

For lock requests in modes belonging to set Z: In this case all access requests must be considered and the access rights granted. Now, each LLM collects the information of the lock request of the mode belonging to the set Y that the LLM accepts and the information of the lock request of the mode belonging to the set Z accepted by all the LLMs. On the other hand, GLM10 has all LLM
It means that the lock information of the modes belonging to the set XY received from is collected. Therefore, in the case of the lock request of the mode belonging to the set Z, the access right is granted to all the LLMs, and the access information is also granted to the lock information of the mode belonging to the set XY in the GLM10. You just have to acknowledge the right. Therefore, when the GLM10 receives the lock acquisition request and the release request for the modes belonging to the set Z, it sends all the requests.
Notify LLM11.

The above is when a user task in the user task group 12 issues a lock acquisition request from a state in which the resource to be locked is not locked and when the lock is acquired from the lock acquisition state. However, it is a case where the state is not acquired. Other than this, you may change the mode you have already acquired. This means that the release of the lock mode which is conventionally held and the acquisition of the newly requested mode are simultaneously processed. However, in this case, the mode that has been conventionally held is not released until the mode that newly requests the change is acquired. The new mode is acquired when it becomes compatible with the modes of the tasks in all the user task groups 12 other than the user currently having the lock resource. If the mode change is allowed freely, deadlock may occur even when there is only one lock resource. Furthermore, there are multiple sets when serialization abilities (the update of data when a set of processing requests are executed in parallel and the reference results are executed serially in a certain order), which is the purpose of measuring the locking process. There is no guarantee that the result will be the same as the result obtained by executing one of the ordering methods. The former (dead lock in the same resource)
Can be found by a simple check algorithm because only the resource needs to be focused on, but the deadlock elimination processing after the occurrence becomes complicated when the default mode lock method is used. In the present invention, since the resolution processing in this case is not directly targeted, the following discussion will be made on the assumption that deadlock in the same resource due to mode conversion does not occur. Also in the latter case, since it is not directly the subject of the present invention,
No mode changes shall be made that do not guarantee serializability.

Next, in the case of the present invention, it will be described which lock manager allows the mode change. Also in this case, the set of modes is divided into Y, XYZ, and Z groups for consideration. First, regarding the change within the same group, this is similar to the case of granting a lock acquisition request. That is, in the case of the change in the mode belonging to the set Y, in the case of the change in the mode belonging to the LLM11, the set XYZ which directly receives the request, the change in the mode belonging to the GLM10, the set Z , GLM1
When 0 and all LLM11 changes are accepted, mode changes are accepted.

Next, the case where there is a change between groups will be described.

When changing the mode of Y → Z, X−Y−Z → Z, Z → Y, Z → X−Y−Z: In any case, obtain the lock request of the mode Z,
Alternatively, since there is a release process, the mode change is allowed when the change process in the GLM 10 and all LLMs 11 is completed.

In case of mode change of Y → X−Y−Z, X−Y−Z → Y mode: In this case, LLM1 which directly accepted the mode change request
Since the mode change is related only to 1 and GLM10, the mode change process is completed in this part.

Normally, the information of each user task regarding each lock resource is created when a lock is requested and erased when the lock is released, so that creation or deletion does not occur when the mode is changed. However, in the case of the present invention, the set of lock managers holding the lock information differs depending on the mode. Therefore, the set of lock managers holding the lock information before the change, the lock information after the change, and the lock to be held -Managers may be in different groups. In this case, the lock information is created and deleted. During the mode changing process, the lock information is held in both sets.

Normally, the lock manager will FC
Since the access right is recognized by FS (First Come First Serbed) scheduling, the received lock acquisition request is connected to the end of the lock queue shown in FIG. Therefore, the compatible check is performed from the head of the queue, and the range in which the access right is granted is determined.
The case where a lock request that has already been granted the access right changes the mode will be described. In this case, the change may be accepted immediately, or the change may be in a waiting state.
If you are in the waiting state, you are in the waiting state while holding the lock mode you have already acquired. First, when a mode change request is accepted, if another lock request is already in the change waiting state, the state is unconditionally put in the change waiting state. In this case, it is assumed that the lock request is connected at the end of the requests in the change waiting state. If there is no request waiting for change, the changed mode performs compatibility check with all the lock request modes that currently have access rights, and if access rights are granted, it remains as is. Will be recognized. Otherwise, the lock request information will be stored at the end of the lock request for which the access right is currently granted.

The queue operation described above is general.
In the case of the present invention, as described above, depending on the mode,
Since the lock manager that holds the lock information is different, the lock information may be registered in the lock queue during mode conversion. The registration position in this case is registered at the same position as when a general mode change request is received.

Next, regarding the present invention, the format of the lock information registered in the lock queue is shown. FIG. 3 shows information registered in a lock queue (hereinafter referred to as an LLM queue) provided in each LLM 11. The post-queue pointer 30 and the pre-queue pointer 31 are pointers for connecting lock information in a queue. Lock mode 32
Indicates the mode of this lock request. Change lock mode
33 is a mode after the lock mode is changed. The user task iD34 indicates the user task iD in the user task group 12 that issued this lock request. The LLMiD 35 is the iD of the LLM 11 that directly receives this request from the task in the user task group 12. The access state 36 indicates whether it is in a waiting state, a change waiting state, or during access.

Figure 4 shows the lock queue created in GLM10 (hereinafter,
This is called GLM queue) and shows the format of the lock information registered. The post-queue pointer 30, pre-queue pointer 31, lock mode 32, change lock mode 33, user task iD34, and LLMiD35 are the same as those shown in FIG. However, in this case, it is the lock request of the mode belonging to the set XY that is registered in the lock queue as described above. GLM queue access status 4
6 shows the status of this lock request in the GLM queue.
The states that can be taken are the same as the access state 34 in FIG. The fields below store the access states of all LLM queues after the LLM1 queue access state 47.

When the GLM10 and each LLM register these lock information in the queue, which position in the queue should be registered, and the queue operation and release request when the lock mode change request is received. The queue operation at the time of opening is as described above. Next, we will describe when to perform this queue operation.

In the case of the lock request of the mode belonging to the set Y: The LLM that directly receives the lock acquisition request, the mode change request, and the release request from the tasks in the user task group performs the queue operation when the request is received. The same applies to the case of changing modes within the modes belonging to the set Y.

In the case of a lock request of a mode belonging to the set XYZ: The lock request of this mode is not registered in the LLM queue.
When the LM10 receives the request, it operates the GLM queue. Mode change in set XYZ, XYZ → Y,
The same applies to the case of changing the mode from Y to XYZ.

For a lock request of a mode belonging to set Z: The lock request of this mode is also registered in the LLM queue of the LLM that directly receives the request from the user task that issued it, but the LLM does not When a request is received from a task in the group, it will not be registered in the LLM queue. The lock information of the lock request of the mode belonging to the set Z is registered in all the LLM queues and the GLM queue, but if the order relation regarding these lock requests does not match on all the queues, the cause of the deadlock occurs. Becomes Therefore, the lock request is registered in the queue when the GLM 10 receives the lock request and is registered in the GLM queue. The GLM 10 transmits the lock information of the lock request of the mode belonging to the set Z and all the LLMs in the order registered in the GLM queue. Lock information for this mode is L
Registered in the LM queue is the GLM, including the LLM that receives the lock request directly from the task in the user tank group.
This is the stage when the lock information was received from 10. For the same reason, the queue operation regarding the release request is performed at the same stage.
Further, the same applies to a mode change request within Y → Z, Z → Y, XYZ → Z, Z → XYZ, Z.

Next, a processing flow chart of LLM11 and GLM10 is shown. However, as shown in FIG. 6, in the case of the LLM 11, it is divided into a user request receiving unit (a part that receives the lock request from the user tank group 12) 60 and a GLM information receiving unit (a part that receives the lock information from the GLM10) 61. Shows a flow chart. The present invention is
The present invention relates to a lock method for handling a lock unit such that the lock mode a is always applied when there is no lock request for a mode belonging to the mode Z in a certain lock unit. In this case, such a lock method is not applied to all the lock units handled by the GLM10 and LLM11, but is limited to a part of the lock units designated by the user. GLM10, LLM11 is assumed to know the what kind of default mode is applied to a set of pre-which locks unit. The flow diagram shown here shows only the part directly related to the present invention, that is, the part relating to the processing of the lock request to which the default lock mode method is applied (default mode = a). The other parts are publicly known and therefore omitted.

FIG. 7 shows a flow chart of the user request receiving unit 60 of the LLM 11. Step 700 checks if this request is a lock request for a lock unit using the default mode. If not, the process jumps to step 701 to perform a normal lock process. In step 702, this lock request needs to be sent to the GLM 10, that is, it is checked and sent whether the lock mode of this lock request is a mode belonging to the set Y or a mode change request in Y. If necessary, step 703
Then, this lock request is sent to the GLM 10, and in step 704 the user task is instructed to enter the wait state until a response to this is returned, and this processing is ended. Next, the case of acquiring / releasing a lock belonging to Y and requesting a mode change in Y will be described. In this case, LLM
It is necessary to operate the queue. Next, in step 705, the contents of the lock request are separated. In the case of release processing, the release processing is performed in step 706, and the release is performed in step 707. The user task group 12 that issued the request
Notify the tasks in. Further, in step 708, it is checked whether or not the lock request has been released so that the lock can be newly acquired and the mode can be changed. In the case of the mode belonging to the set Y and the mode change in the Y, the task in all the user task groups 12 that has been granted the access right in step 709 is notified of this. On the other hand, the set Z
In the case of a lock request for a mode belonging to the above, and a mode change request related to Z, all of these requests are sent to the GLM 10 in step 710. Further, in step 711, it is checked whether or not there is a request for which the change right in the mode Y is recognized among those newly granted the lock acquisition right and the mode change right. If there is,
Since the lock acquisition right and the change right may be granted by this change, the process goes to step 708 again. If not, the process ends.

Next, in the case of a change / acquisition request, in step 702,
Check whether this change / acquisition is permitted and perform the corresponding queue operation. If not, step 71
In 3, the request issuing task in the user task group 12 is instructed to enter the wait state and the processing is ended. If so, the task in the user task group 12 is notified of this in step 714. Further, it is judged whether the request accepted in step 715 is a lock acquisition request or a mode change request, and if the mode change is accepted, it is checked whether or not there is a request for which the access right is newly granted by this change. , Step 708
Jump to. If not, the process ends. This is the end of the description of the flow chart of the user request receiving unit 60.

Next, a processing flow chart of the GLM request receiving unit 61 is shown. In step 800, a check is made to see if this request is a default mode lock unit. If not, the process jumps to step 801, and normal processing is performed. In the case of the lock unit in the default mode, in step 802, this request is a response to the task in the user task group 12 (access right is granted, mode change request is accepted, release request is completed). Or a request to release a lock belonging to the set Z, and a release request, and within Z, Z →
It is checked whether the request is a mode change request of XYZ, XYZ → Z, Y → Z, Z → Y. In the case of the response of the task in the user task group 12, this is notified in step 803. Otherwise, in step 804 and subsequent steps, the lock request for the mode belonging to the set Z and the mode change request described above are processed. This processing content is basically the same as the processing content when the user request receiving unit 60 receives a lock request for a mode belonging to the set Y and a mode change request within Y. The different point is that, in the case of the user request receiving unit 60, the other party who notifies the result of the received lock request is a task in the user task group 12, whereas in this case it is the GLM 10. further,
Here, if the lock is not acquired or changed, no response is returned to the GLM10, but a response is returned at a later-recognized stage.

Next, a processing flow chart of GLM10 is shown in FIG. Step 9
At 00, this request checks if the lock unit is in default mode. Otherwise, step
Jump to 901 and perform normal processing. In the default mode lock unit, in step 902, the received request is a lock acquisition, release, or change request from a task in the user task group 12 sent via the LLM 11. It is also checked whether the lock acquisition sent from the LLM11 is complete, the mode change request is completed, and the release notification is completed. If the latter, in step 903 all LLMs
In 11, and GLM10, check if this process is completed. If so, in step 904, the user task group 12 that issued the request for completion notification
Issue a completion notice to the appropriate LLM11 to inform the task in. Next, in step 905, it is checked whether or not this completion is a release processing or a mode change processing, and if so, it is checked whether a new lock acquisition or mode change is permitted by this completion.
Jump to step 916.

Next, the case where a request is received from the tasks of the user task group 12 will be described. In step 906, this request is a lock acquisition request of a mode belonging to the set Z, or a Y-> Z, Z-> Y, X-Y-Z-> Y, Y-> X request.
-Check whether the request is for a mode change within YZ, Z. If so, in step 907, pass this request to all LLMs 11. Next, in step 908, it is checked whether this request is a lock acquisition / mode change request notification. If so, in step 909 it is checked if the request is admitted in the GLM queue and the result is stored in the GLM queue. In this case, again, since the completion notice is not returned from the LLM11, the request cannot be accepted as a whole. If it is a release request, the GLM queue is searched in step 910, and the fact that the release process is accepted is stored. (In the case of the release notification, it is not recognized yet for the same reason.) Next, the lock acquisition request, the release request, XYZ → Y, Y → X- of the modes belonging to the set XYZ. A case where a mode change request in YY, XYZ is received will be described.
At step 911, it is checked whether the request is a lock acquisition request or a mode change request. (If it is a release request, jump to step 915. If so, in step 912, it is checked whether or not this request is accepted. If it is not authorized, the processing is ended. If it is accepted, in step 913. In order to notify the task of the user task group 12 that issued the request, this is notified to the corresponding LLM 11. In step 914, it is checked whether the mode change request is accepted, and Steps, if any
Jump to 916. In case of release request, step 915
Then, this process is performed and the LLM 11 is notified of this fact. Then, in step 916, it is checked whether or not there is a new request for lock acquisition and mode change due to the release processing and mode change.
If the GLM 10 alone grants these requests, then if the request is granted, then in step 917 the appropriate LLM is notified that this request was granted. Then G
If all LLM11s, not just LM10s, must accept the request, check in step 918 if they are satisfied with this font, and if so, check that the request has been granted. Notify LLM11. LLM
In step 918, it is confirmed whether or not there is a mode change request among the completion requests sent to 11 and, further, in order to check whether or not there is a request to be newly completed by this completion, the processing jumps to step 916. , If not, the process ends.

As described above, in this embodiment, the effect is issued when the probability of issuing the lock request belonging to the mode Y is higher than the probability of issuing the lock request belonging to the mode Z. In this case, if the number of LLMs is n, G in the case of each mode set
The number of communications between LM and LLM is as follows.

Y: 0 X-Y-Z: 2 Z: 2nT2 Y, Z Probability that a lock request for a mode is issued is P _Y ,
Number of communication C between GLM and LLM in the present invention when P _Z
Is as follows.

_{C: 2 (1-P Y} -P Z) +2 (n + 1) whereas P _Z, in the conventional method, regardless of the mode, always two times signal is produced. Therefore, the reduction ΔC (C′−C) in the number of communications obtained by the present invention is defined as follows.

ΔC = 2 (P _Y −nP _Z ) Therefore, when P _Z > P _Y / n, when this method is applied, the performance may be deteriorated.

〔The invention's effect〕

As described above, according to the present invention, it is possible to realize a locking method that reduces the number of times of communication between lock managers when a database is shared between CPUs, and therefore communication costs are reduced.

[Brief description of drawings]

FIG. 1 is a software configuration diagram of a lock management system which is a target of the present invention, FIG. 2 is a configuration diagram of a lock queue, FIG. 3 is a format diagram of lock information registered in an LLM queue, and FIG. 4 is a GLM. Format of lock information registered in queue, FIG. 5 is a block diagram of a computer system that shares data between CPUs, FIG. 6 is a block diagram of LLM, and FIG. 7 is a processing flow of a user / task request receiving unit. Figures and 8 are GL
FIG. 9 is a processing flow chart of the M information receiving unit, and FIG. 9 is a processing flow chart of GLM. 10: Global Lock Manager, 11: Local Lock Manager.

 ─────────────────────────────────────────────────── ─── Continuation of the front page (72) Inventor Hiroyuki Kitajima 1099, Ozenji, Aso-ku, Kawasaki-shi, Kanagawa Inside the Hitachi, Ltd. Systems Development Laboratory (72) Inventor, Shigeru Yoneda 1099, Ozen-ji, Aso-ku, Kawasaki, Kanagawa Company Hitachi Ltd. System Development Laboratory (72) Inventor Akira Kurano 2880 Kozu, Odawara City, Kanagawa Stock Company Hitachi Ltd. Odawara Factory (72) Inventor Takashi Sumiyoshi 5030 Totsuka-cho, Totsuka-ku, Yokohama, Kanagawa Stock Company Hitachi Factory software factory

Claims (4)

[Claims] 1. A CPU comprising a plurality of CPUs, and a storage device storing shared data commonly used by tasks executed on the CPUs. The storage device is provided in each of the CPUs, and is shared by the tasks. A local lock manager that receives a lock request for data and a global lock manager that is provided in any of the plurality of CPUs and that manages the lock of the shared data according to the lock request received through the local lock manager are provided. Then
In a shared data management method for a computer system, wherein a plurality of modes are prepared as a lock request mode for the shared data, a mode q lock request is permitted for the shared data while being locked in the mode p. In this case, COMPAT (q, p) = true is expressed, and between any mode b and the mode a defined as the default,
C for all modes r for which COMPAT (r, a) = true
When the relation of COMPAT (b, s) = true holds for all modes s of OMPAT (r, b) = true and COMPAT (a, s) = true, the mode b is more exclusive than the mode a. And each local lock manager
The mode of the lock request received from the corresponding task is
If it is determined whether the mode of the lock request is not exclusive than the mode a and it is determined that the mode of the lock request is not exclusive of the mode a, the lock request is notified without notifying the global lock manager. It is determined whether or not to permit the lock request, the result of the determination is notified to the task, and when it is determined that the mode of the lock request is a mode other than the mode not exclusive to the mode a, the lock A shared data management method comprising notifying a request to the global lock manager and entrusting the global lock manager to decide whether to grant the lock request. 2. The global lock manager satisfies the condition that the mode c of the lock request received from the local lock manager is COMPAT (c, a) = true with respect to the mode a and COMPAT (a, c) = true. If the condition is not satisfied, it is determined whether or not to permit the lock request in the mode c based on the lock information about the lock request accepted by the global lock manager. Notifies each local lock manager of the occurrence of the mode c lock request and inquires whether the mode c lock request can be granted. Each of the local lock managers responds to the inquiry by The lock request notified from the global lock manager is more exclusive than the mode a that it has accepted. It is determined whether or not it is permissible in relation to the lock request of a certain mode, and when it is permissible, a response to the inquiry is returned to the global lock manager, and the global lock manager receives the response from each local lock manager. The shared data management method according to claim 1, further comprising receiving the response and determining whether to permit the lock request in the mode c based on the response and the lock information. 3. Each of the local lock managers comprises:
It holds lock information about a lock request in a mode that is less exclusive than the mode a accepted by itself and lock information about a lock request notified from the global lock manager, and based on the held lock information, The shared data management method according to claim 2, wherein the determination is made for the lock request received from the task. 4. COMPAT (a, a) = t for the mode a
The shared data management method according to claim 1 or 2, wherein rue is established.