JPH09223030A - Exclusive control method and equipment therefor - Google Patents

Abstract

PROBLEM TO BE SOLVED: To reduce the overhead loaded on a lock operation. SOLUTION: When requesting the lock of resources, a task issues a lock possession request containing the designation of monitor time. When the permission of lock can not be immediately given to this lock possession request, task information concerning that task is added to a waiting list by a task information register means 210. A wait time monitor means 220 monitors the lapse of time after the task is turned into lock waiting and when that time becomes a monitor time designated by the task, a deadlock check means 230 is called. When this task is set in a lock waiting state, concerning this task, the deadlock check means 230 checks whether deadlock has been generated or not. When the deadlock has been generated, this task is excluded out of the lock waiting list and it is reported to the task of the request source. When this report is received, the task cancels already possessed lock through a task information deleting means 240.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a technology for performing exclusive control of resources in an information processing system, and more particularly to an exclusive control method and apparatus capable of reducing the overhead related to deadlock check.

[0002]

2. Description of the Related Art When a resource is shared by a plurality of tasks, it is necessary to lock the resource in order to use it. In general, when the lock for writing is acquired, other tasks cannot acquire the lock for the same resource.

On the other hand, when trying to acquire a lock for a resource shared by a plurality of tasks, the locks acquired by other tasks may wait for each other and the processing may not proceed. Such a state is called deadlock. When a deadlock occurs, the process does not proceed, and it is necessary to take some action.

Conventionally, when a task that issues a lock acquisition request fails to lock and waits for a lock, it is always checked whether a deadlock has occurred, and a lock acquisition request that causes a deadlock is rejected. Was doing. According to this conventional technique, it is possible to prevent the occurrence of deadlock, but since the frequency of deadlock is generally low, performing a deadlock check every time lock waiting occurs increases overhead. There is a problem.

Therefore, in order to solve the above problems,
A technique has been proposed in which, when a lock wait occurs, a deadlock check is not performed, but a deadlock check is performed for all tasks that are in a lock wait state at a certain fixed time interval (Japanese Patent Laid-Open No. 62-62160). -1776
31 publication). According to this technology, it is not necessary to perform a deadlock check for the tasks for which the lock wait has been resolved between the occurrence of the lock wait and the deadlock check timing, so the number of tasks that perform the deadlock check And the overhead can be reduced.

[0006]

In the above-mentioned conventional technique, the deadlock check is performed at fixed time intervals, but the timing at which the lock wait occurs is independent of the deadlock check timing. Therefore, a lock wait may occur immediately before the deadlock check timing. In such a case, the probability that the task related to the lock wait has been released from the lock wait at the deadlock check timing is as follows. Low.
In other words, there is a high probability that the deadlock check cannot be omitted for the above tasks. Therefore, in the above-described conventional technique, when the lock wait occurs intensively immediately before the deadlock check timing, the number of tasks that can omit the deadlock check becomes small, and the overhead is reduced. There is a problem that it cannot be reduced so much.

Therefore, an object of the present invention is to provide an exclusive control method and an apparatus thereof which can reduce the overhead regardless of the timing of occurrence of the lock wait.

[0008]

In order to achieve the above-mentioned object, the exclusive control method of the present invention includes a lock acquisition request issued by a task including a specification of a monitoring time, and a lock acquisition request including a specification of the monitoring time. If the issued task fails to lock and waits for a lock, the task waits until the monitoring time specified in the lock acquisition request elapses, and when the monitoring time elapses, the task lock wait is released. Only when there is no deadlock, whether or not a deadlock related to the task has occurred is checked, and when the deadlock has occurred, the resource locked by the task is released.

Further, in the exclusive control method of the present invention, when a conflict occurs between tasks having different priorities, a task having a higher priority can preferentially lock the resource. , Increase the monitoring time specified in the lock acquisition request.

Further, in order to achieve the above object, the exclusive control device of the present invention provides the lock acquisition request when the task that has issued the lock acquisition request including the designation of the monitoring time fails to lock and waits for the lock. Waiting time monitoring means for monitoring the elapse of the monitoring time specified by the above, and is related to the task only if the lock wait of the task whose monitoring time has been detected by the waiting time monitoring means is not released. A deadlock check means for checking whether or not a deadlock has occurred and for releasing the resource locked by the task when the deadlock has occurred.

In the above-mentioned configuration, when the task fails to lock and waits for lock, the waiting time monitoring means monitors the elapse of the monitoring time designated by the task. The deadlock check means checks whether or not a deadlock related to the task has occurred only when the lock wait of the task whose elapsed monitoring time has been detected by the wait time monitoring means is not released.

[0012]

Embodiments of the present invention will now be described in detail with reference to the drawings.

Referring to FIG. 1, an exclusive control device 200 according to the present invention includes, for example, a plurality of processors 100,
It is applied to an information processing system such as a loosely coupled system including the shared resource 300 shared by these processors 100. Here, the shared resource 300 is, for example, a partial area or file of the memory. In the following description, the minimum unit subject to lock control is called a block.

FIG. 2 is a block diagram showing a configuration example of the exclusive control device 200. Referring to FIG. 1, the exclusive control device 200 includes a command interface 250 for exchanging commands with each processor 100, and a lock management table 260 in which information about a lock or a task waiting for a lock (hereinafter, task information) is registered. , Task information registration means 21 for registering the task information of the lock or the task waiting for the lock in the lock management table 260.
0 and the waiting time monitoring means 2 for monitoring the elapse of the monitoring time designated by the lock acquisition request issued by the task 2
20, a deadlock check means 230 for checking whether there is a deadlock between tasks, and a lock management table 26.
Task information deleting means 240 for deleting the task information registered in 0.

FIG. 3 is a diagram showing an example of the contents of the lock management table 260. Referring to the figure, the lock management table 260 includes block information 261 for each block,
The task information 262 of the task that locks or waits for the block is registered.

The block information 261 has a block identifier for identifying the block, a lock list pointer which is a pointer to the head of the lock list, and a wait list pointer which is a pointer to the head of the wait list. Here, the lock list is a list in which task information of tasks that lock the block is connected by a linked list. Further, the waiting list is a list in which the task information of the tasks waiting for the lock of the block is connected by the linked list. Further, each task information 262 includes a task identifier for identifying a task, a lock type indicating a lock type such as read or write, and a next task information pointer that points to the next task information forming a linked list. Have In the present embodiment, the block information for each block is registered in advance in the lock management table 260. However, when a task to lock the block occurs, the block information of the block is generated, and When there is no task that locks or waits for the block, the block information of the block may be deleted. By doing so, the lock management table 2
The capacity of 60 can be reduced.

FIG. 4 is a diagram showing an example of the contents of the monitoring entries used by the waiting time monitoring means 220. Referring to the figure, the monitoring entry is a target entry pointer that is a pointer to the task information in the lock management table 260, a registration time indicating the time registered in the lock management table 260, and a lock acquisition request from the task. Including the specified monitoring time.

FIG. 5 is a diagram showing an example of the format of a command issued by a task on each processor 100. Referring to the figure, the command issued by the processor 100 includes a command code indicating a request type, a task identifier indicating a request source task, a block identifier indicating a request target block, and a lock type indicating a lock type. , And the monitoring time when a lock wait occurs.

FIG. 6 is a flow chart showing a processing example of the task information registration means 210, FIG. 7 is a flow chart showing a processing example of the waiting time monitoring means 220, and FIG. 8 is a deadlock check means 230.
9 is a flowchart showing an example of the processing of FIG.
10 is a flowchart showing a processing example of 0, and the operation of the present embodiment will be described below with reference to each drawing.

The command interface 250 in the exclusive control device 200 is shown in FIG.
When the command of the format shown in is received, the command code in the command is analyzed. If the command code indicates a lock acquisition request, the task information registration means 210
Is called to pass the command, and if the unlock request is indicated, the task information deleting means 240 is called to pass the command.

Referring to FIG. 6, task information registration means 2
When the command is passed from the command interface 250, the device 10 first searches the lock management table (S2
11), it is determined whether the block indicated by the “block identifier” included in the command can be locked (S).
212).

Explaining the processing example of S212 in detail, first, the block information 261 having the same “block identifier” as the “block identifier” included in the command is searched from the lock management table 260, It is checked whether or not the "lock list pointer" of this block information 261 is an empty pointer. If it is a free pointer, it is determined that the lock is possible.

If the pointer is not a free pointer, it has already been locked by another task. Therefore, it is possible to lock at the same time by referring to the "lock type" of each task information connected to the lock list. To judge. That is, even if the target block is already locked for reading, if the “lock type” of the command is “read”, it is also determined that this can be locked. This is because no contradiction occurs if they are read from each other. on the other hand,
If the target block is already locked for writing, it is determined that the block cannot be locked regardless of the "lock type" of the command. The above is a detailed processing example of S212.

If it is determined in S212 that the lock is possible,
The task information is generated based on the “task identifier” and the “lock type” included in the command, and the task information is connected to the end of the lock list (S213), and then the “task identifier” of the command is sent via the command interface 250. "
Is notified to the task indicated by (S2).
16).

On the other hand, if it is determined in S212 that the lock cannot be made, the "task identifier" included in the command
And generate task information based on "Lock type",
Connect to the end of the waiting list (S214), and further call the waiting time monitoring means 220 to pass the command (21
5) After that, the fact that the task indicated by the "task identifier" of the command is waiting for lock is notified (S216).

Referring to FIG. 7, the waiting time monitoring means 22
When 0 is called from the task information registration means 210 and a command is passed, first, a monitoring entry of the format shown in FIG. 4 is generated and registered in the lock management table 260 (S
221). Then, the monitoring process is performed until the elapsed time from the registration time in the monitoring entry matches the “monitoring time” of the monitoring entry (S222, S223).

When the elapsed time matches the "monitoring time" in the monitoring entry, the lock management table 260 is searched to see if the task information pointed to by the "target entry pointer" of the monitoring entry has already been deleted. (S2
24, S225). As a result, the lock management table 26
If the task information pointed to by the "target entry pointer" still exists in 0, the deadlock check means 230 is called to pass the "target entry pointer" pointing to the task information in order to perform the deadlock check. (S226). If there is no task information pointed to by the “target entry pointer” in the lock management table 260, it is not necessary to perform the deadlock check, so the deadlock check means 230 is not called.

Referring to FIG. 8, when the deadlock checking means 230 is called from the waiting time monitoring means 220 and the "target entry pointer" is passed, the deadlock check means 230 first starts the task information pointed to by the "target entry pointer". Then, the presence or absence of deadlock between tasks is checked (S231, S232). As a result, when a deadlock has occurred, the task indicated by the “task identifier” in the task information that is the starting point is determined as the task causing the deadlock, and the task information deleting means 2
40, and the above “target entry pointer” is passed (S233), and then the command interface 250
The fact that task information deletion due to deadlock has occurred is notified to the cause task via (S234). The task that received this notification releases all the blocks that it has locked to eliminate the deadlock.
The code that requests unlocking to the "command code",
A command of the format shown in FIG. 5 in which the task identifier of the block is set to the task identifier of itself and the block identifier of the block to be unlocked is issued to each of the locked blocks. This command
It is analyzed by the command interface 250 and passed to the task information deleting means 240.

Referring to FIG. 9, task information deleting means 2
40 is first called when the deadlock check means 230 is called and when a command requesting unlock is passed through the command interface 250.
The task information to be deleted is retrieved from the lock management table 260 (S241). Specifically, when a command requesting unlocking is passed, the block information having the “block identifier” included in the command is searched, and the command is searched from the task information linked to the searched block information. The task information having the "task identifier" included in is retrieved. Also, the deadlock check means 2
When called from 30, and the "target entry pointer" is passed, the task information pointed to by it is searched. Then, the retrieved task information is deleted (S24).
2).

After that, it is checked whether or not other task information exists in the waiting list of the block information from which the task information has been deleted (S243). If there is task information in the waiting list, it is determined whether the task information can be locked by deleting the task information described above (S24).
4). When it is determined that the lock is possible,
The task information is removed from the waiting list and connected to the lock list, and the task indicated by the "task identifier" included in the task information is notified that the lock is permitted (S245). Next, when the command requesting the unlock is passed from the command interface 250, the task indicated by the “task identifier” included in the command is notified that the unlock is completed (S
246). On the other hand, if the waiting task information does not exist or it is not lockable (S243, S24
4) It does not notify that the lock is permitted. If there is a plurality of task information in the waiting list, the same process is performed for all the task information.

Next, the operation when a deadlock occurs between two tasks will be described in detail with reference to FIG. Here, it is assumed that the task T1 locks the blocks A and B in that order and then performs the update processing, and the task T2 locks the blocks B and A in that order and then performs the update processing. Further, both tasks T1 and T2 cannot be updated unless both blocks A and B are locked.

Referring to FIG. 10, when the task T1 issues a command and requests the lock acquisition for the block A, the exclusive control device 200 registers the task information of the task T1 in the lock list of the block A, and thereafter, A lock permission notification is issued to the task T1 (S901). Next, when the task T2 issues a command to request the lock acquisition for the block B, the exclusive control device 200
The task information of the task T2 is registered in the lock list of the block B, and then the lock permission notification is given to the task T2 (S902).

Then, the task T1 issues a command to request the lock acquisition for the block B. However, at this point, block B is already in task T2.
Exclusive control device 200 because it is locked by
Sends a lock wait notification to task T2,
The task information of task T1 is registered in the waiting list of block B (S903). Further, the exclusive control device 200 starts monitoring the "monitoring time" designated by the above command (S904).

Next, task T2 issues a command to request the lock acquisition for block A. However, at this point, since the block A has already been locked by the task T1, the exclusive control device 200 sends a lock wait notification to the task T2 and the block A
The task information of task T2 is registered in the waiting list of (S
905). Further, the exclusive control device 200 starts monitoring the “monitoring time” designated by the above command (S
906).

By the processing up to this point, tasks T1 and T2
Deadlock occurs between. That is, while the tasks T1 and T2 lock the blocks A and B, respectively, the task T
1 and T2 are waiting for the locks of the blocks B and A, respectively, and are in a rigid state after waiting for the lock of the blocks locked by each other. In this case, this state will continue forever unless either one locks and the block is forcibly unlocked. Therefore, in the present invention, when the "monitoring time" of the monitoring entry has passed, it is checked whether or not a deadlock has occurred, and if a deadlock has occurred, the lock waiting state is released and the task is notified to that effect. By doing so, the deadlock is eliminated.

Now, for example, if the task T1 and the task T2 specify the same "monitoring time", the waiting of the task T1 previously registered for waiting will time out quickly. When this timeout is detected (S907), whether or not a deadlock has occurred is checked starting from the task information indicating the lock wait for the block B of the task T1, and it is detected that the deadlock has occurred due to the task T1. To be done. Then, the task information indicating the lock wait for the block B of the task T1 is deleted from the wait list, and the task T1 is notified of this deletion (S90).
8).

In response to this notification, the task T1 recognizes that a deadlock has occurred, and issues a command to request unlocking of the block A locked by itself.
In response to this command, the task information indicating the lock acquisition of the block A by the task T1 is deleted from the lock list, and the task T1 is notified of this deletion (S909). Further, the task T2 waiting for the lock of the block A is notified of the lock permission (S
909). As a result, the task T2 is permitted to lock the block A and the block B, and the update process becomes possible.

In the above example, the tasks T1 and T2 are designed to specify the same "monitoring time", but the task T1
By setting the "monitoring time" specified by the task monitoring time to a value larger than the "monitoring time" specified by the task T2, the waiting of the task T2 can be timed out earlier.
Also, by adjusting the "monitoring time" specified by each task according to the priority of the task such that the higher the priority of the task, the deadlock occurs between the tasks with different priorities. In this case, a task with a low priority can be timed out first, and a task with a high priority can be locked with priority.

[0039]

As described above, according to the exclusive control method of the present invention, when the task that issues the lock acquisition request including the designation of the monitoring time fails in the lock and waits for the lock,
The deadlock check is performed only when the monitoring time specified by the lock acquisition request is waited for and the task lock wait is not released when the monitoring time elapses. The time interval from the occurrence to the deadlock check timing is always the monitoring time specified by the task. Therefore, depending on the timing of occurrence of lock wait, the time interval from the occurrence of lock wait to the deadlock check timing may become very short, compared to the conventional technique, in which the dead time is reached after lock wait. There is a high probability that the lock wait is released before the lock timing is reached. Since it is not necessary to perform the deadlock check for the task whose lock wait is released, the exclusive control method of the present invention reduces the number of tasks that perform the deadlock check as compared with the conventional technique and reduces the overhead. Can be reduced.

Further, in the exclusive control method of the present invention, the higher the priority task is, the longer the designated monitoring time is set. Therefore, when a deadlock occurs between tasks having different priorities, the priority is high. Tasks can be made to lock resources preferentially.

Further, the exclusive control device of the present invention, when the task that issues the lock acquisition request including the specification of the monitoring time fails in the lock and waits for the lock, the exclusive time of the monitoring time specified by the lock acquisition request is set. Only when the waiting time monitoring means for monitoring the progress and the waiting time for the task whose monitoring time has been detected by the waiting time monitoring means are not released, the deadlock related to the task is checked to see if there is a deadlock. When a lock is generated, the task is provided with deadlock check means for releasing the locked resource, so that the deadlock can be released with a simple configuration and with a small overhead.

[Brief description of drawings]

FIG. 1 is a block diagram showing an example of an information processing system in which an exclusive control device of the present invention is used.

FIG. 2 is a block diagram showing a configuration example of an exclusive control device.

FIG. 3 is a diagram showing an example of contents of a lock management table 260.

FIG. 4 is a diagram showing an example of contents of a monitoring entry.

FIG. 5 is a diagram showing a command format.

6 is a flowchart showing a processing example of task information registration means 210. FIG.

7 is a flowchart showing a processing example of the waiting time monitoring means 220. FIG.

FIG. 8 is a flowchart showing a processing example of the deadlock check means 230.

FIG. 9 is a flowchart showing a processing example of task information deleting means 240.

FIG. 10 is a diagram showing an example of an operation of the exclusive control device 200 when a deadlock occurs.

[Explanation of symbols]

 100 ... Processor 200 ... Exclusive control device 210 ... Task information registration means 220 ... Wait time monitoring means 230 ... Deadlock check means 240 ... Task information deleting means 250 ... Command interface 260 ... Lock management table 261 ... Block information 262 ... Task information 300 … Shared resources

Claims (4)

[Claims] 1. A lock acquisition request issued by a task includes a specification of a monitoring time, and when the task that issued the lock acquisition request including the specification of the monitoring time fails to lock and waits for a lock, the lock acquisition is performed. Wait until the monitoring time specified in the request elapses, and only if the task's lock wait is not released when the monitoring time elapses, check whether there is a deadlock related to the task, and An exclusive control method characterized in that when a lock is generated, the resource locked by the task is released. 2. The exclusive control method according to claim 1, wherein the higher the priority of the task, the longer the monitoring time specified in the lock acquisition request. 3. A waiting time monitor for monitoring the elapse of the monitoring time specified by the lock acquisition request when the task that issued the lock acquisition request including the specification of the monitoring time fails to lock and waits for the lock. And means for checking whether or not a deadlock related to the task has occurred only when the lock wait of the task whose elapsed monitoring time has been detected by the wait time monitoring means is not released,
An exclusive control device comprising: deadlock check means for releasing the resource locked by the task when a deadlock occurs. 4. The exclusive control device according to claim 3, wherein a task having a higher priority has a longer monitoring time specified in the lock acquisition request.