JP2001256065A - Exclusive control method and computer system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To reduce CPU overhead to be required for an exclusive control processing of shared resources in a computer system to process a small number of threads with high operation frequency and threads with low operation frequency by mixing them. SOLUTION: When release of lock is requested, a delay flag is set without releasing the lock. However, when threads waiting for release exist and when plural threads with high operation frequency exist, the lock is released. When acquisition of the lock is requested from the same thread again, a fact that the lock is acquired is discriminated by the delay flag and a thread identifier and no acquisition processing of the lock is performed. When the acquisition of the lock the release of which is delayed is requested from other thread, the lock is acquired again after releasing the lock by an interruption processing.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

The present invention relates to an exclusive control method and a computer system in a computer system.
The present invention relates to an exclusive control method that reduces the overhead of a CPU on a shared resource between execution control units of a program such as a thread and a task, and a computer system using the method.

[0002]

2. Description of the Related Art Generally, an execution control unit of a program having a context, such as a program counter and a register, and a stack, which is used or controlled by an operating system which is a control program of a computer system, is called a thread. Depending on the operating system, a thread may be called a task or a lightweight process. An execution control unit of a program including an address space and a program code is called a process. Depending on the operating system, a process may be called a task or a job. A process typically has one or more threads.

In some cases, a computer system handles a plurality of processes and threads in parallel by switching at regular intervals during the execution of a process or executing the processes simultaneously on a plurality of CPUs. Usually, a computer system is used in such a case.
An exclusive control process is provided to guarantee consistency of resources shared between processes and threads and to prevent two or more processes or threads from executing a dangerous zone section. As a conventional technique relating to this kind of exclusive control, for example, a technique described in ACShaw, “Logic Design of Operating System” (ISBN4-8222-7077-7), p51-p58, and the like is known. In this conventional technique, a process that has performed a P operation is made to wait until another process executes a V operation using a semaphore. Exclusive control processing using a semaphore is executed by implementing a function such as pthread_mutex_lock () in the operating system.

Further, as a conventional technique relating to exclusive control by a method different from that described above, there is known a technique described in p61-p66 of the above-mentioned document. This prior art relates to a method for realizing a monitor function that permits execution of only one process at a time by using a semaphore.
Then, in this prior art, in both the monitor entrance process for acquiring the lock and the monitor exit process for releasing the lock, mutex_lock () and mutex_unlock () are used to prevent mutual access of the procedures in the monitor. One call at a time, and also for exclusive control of resources m
It uses utex_lock ().

[0005] Further, as a prior art related to the above-mentioned monitor function, there is disclosed in "An Efficient Meta-lock fo" by OleAgesen et al.
r Implementing Ubiquitous Synchronization '', (Sun L
absTR-99-76) The technique described in p11-p12 is known. This conventional technology uses Compar instead of mutex_lock ().
metaLock () using exclusive control instructions such as e-and-Swap and Swap
Is used. Exclusive control of resources is performed by allocating lock records unless resource conflict occurs.

[0006]

In the monitor processing according to the prior art described in the above "Logical design of operating system", since the mutex processing is always called,
There is a problem that CPU overhead becomes large. The reason for this is that the mutex process performs thread sleep and wake-up control, which makes the mutex process more complicated than that using Compare-and-Swap or semaphores.

[0007] Also, the aforementioned "An Efficient Meta-lock"
Another conventional monitor processing described in `` for Implementing Ubiquitous Synchronization '' uses Compare-and-Swap, which has less CPU overhead than when using a mutex, but the instruction is not executed simultaneously by another CPU during instruction execution. Compar with serialization
The e-and-Swap instruction and the Swap instruction always occur once each time, and there is a problem that the processing load is large.

[0008] If the computer system performs multi-thread or multi-process processing, exclusive control of shared resources is indispensable. For example, a specific thread occupies most of the execution time, and another thread is used by other threads. Even if the program runs only when a specific event occurs or after a certain period of time, the thread that occupies most of the execution time does not know when the other thread will run, so it calls the monitor and locks it. Access to shared resources. As described above, even when the contention of the shared resource hardly occurs, each thread needs to acquire or release the lock every time the thread accesses the shared resource. For this reason, a computer system that performs multi-thread or multi-process processing has a large amount of CPU overhead required for exclusive control when the number of shared resources is large or the number of times of accessing the shared resources is large, This causes a problem that the processing performance is reduced.

An object of the present invention is to solve the above-mentioned problems of the prior art, and is particularly effective when a specific thread occupies most of the execution time, thread switching frequency is low, and contention for shared resources hardly occurs. And a computer system using the exclusive control method.

[0010]

According to the present invention, an object of the present invention is to provide a method for exclusive control between threads of a shared resource in a computer system in which a plurality of threads can operate in parallel. The lock is acquired when a lock of the shared resource to be excluded is requested from the storage device, and the thread identifier of the first thread is stored in a monitor management structure provided in the shared resource unit to be excluded, and the lock is acquired. Release of the lock is requested when release of the lock is requested, a release delay flag is set in the monitor management structure, and the lock is stored in the monitor management structure when the acquisition of the lock is requested again by the thread. The thread identifier is compared with the thread identifier of the thread that has issued the lock acquisition request, and the lock acquisition request is from the first thread. Determining whether the lock release is delayed by examining the release delay flag, determining that the lock acquisition request is a lock acquisition request from the first thread, and This is achieved by having the first thread continue to use the lock if the lock release is delayed.

The above object is achieved by applying the above-described exclusive control method to a computer system.

[0012]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, an embodiment of an exclusive control method according to the present invention and a computer system using this method will be described in detail with reference to the drawings.

FIG. 1 is a block diagram showing an example of a hardware configuration of a computer system according to an embodiment of the present invention. FIG. 2 is a block diagram illustrating a processing configuration for implementing an exclusive control method according to an embodiment of the present invention. FIG. 3 is a view for explaining the configuration of the monitor management structure, FIG. 4 is a flowchart for explaining the processing operation of the monitor entrance processing, FIG. 5 is a flowchart for explaining the processing operation of the monitor exit processing, and FIG. 5 is a flowchart for explaining the processing operation of FIG. 1 to 3, 101 is a central processing unit (CPU), 102 is a main storage device, 103 is a thread,
104 is a user program, 105 is a monitor process, 10
6 is an exclusive control process, 107 is a monitor management structure, 108
Is a lock code, 110 is lock acquisition processing, 111 is lock release processing, 300 is monitor entry processing, 400 is monitor exit processing, and 500 is lock release request interruption processing.

As shown in FIG. 1, a computer system according to an embodiment of the present invention includes one or more CPUs 101.
And a main storage device 102. On the main storage device 102, a plurality of threads 103 such as a stack and a context as a thread entity, a thread 1
When exclusive control is performed on the shared resource 109 as an object such as a user program 104 having an instruction code and data shared among the plurality of threads, a memory area and a file which can be shared among a plurality of threads in the user program 104 Monitor process 105 having an instruction code which is a library function called by the monitor process, and exclusive control process 10 having an instruction code of an exclusive control process of the operating system such as mutex_lock which is called from the monitor process 105.
6. A plurality of shared resources 109 are arranged. A monitor management structure 107 and a lock record 108 such as a semaphore are assigned to each of the plurality of shared resources 109 one by one.

The processing for implementing the exclusive control method according to one embodiment of the present invention is performed by the monitor processing 105 as shown in FIG.
, A monitor entry process 300, a monitor lock process 400, a lock release request interrupt process 500, and a lock acquisition process 110 and a lock release process provided in the exclusive control process 106.

The user program 104 stores the shared resources 10
When locking the shared resource 109 to use the resource 9, the monitor entrance process 300 in the monitor process 105 is called by designating the structure 107 corresponding to the shared resource 109. The monitor entry process 300 checks the lock state of the shared resource 109, confirms that the shared resource 109 is not locked by any thread, and determines whether the thread is pointed by the monitor management structure 107 in the monitor management structure 107. By specifying the included lock record 108, a lock acquisition process 110 such as mutex_lock (), semaphore P operation, and ENQ in the operating system is called. Lock acquisition processing 110
Updates the contents of the lock record 108 to the locked state.

When releasing the lock on the shared resource 109, the user program 104 specifies the structure 107 corresponding to the shared resource 109 and calls the monitor exit process 400 in the monitor process 105. Monitor exit processing 400
Indicates that another thread refers to the structure 107 and the shared resource 1
A check is made to see if it is waiting for the release of lock 09. Then, the monitor exit process 400 specifies the lock record 108 when the number of threads other than the thread waiting for release or the thread whose operation frequency is defined in advance is a predetermined number, for example, 2 or more, is specified. And mutex_unlock () in the operating system and semaphore V
The lock is released by calling the lock release processing 111 such as operation and DEQ. At this time, the monitor exit processing 400
If there are no threads waiting to be released,
Without releasing the lock, the lock of the shared resource 109 is held continuously until another thread requests the lock.

In the above-described process of the monitor entrance process 300, when the shared resource is already locked by the thread, the monitor entrance process 300 executes the user program 104 which has called the process 300 by the locked thread.
It checks whether or not it is its own thread, and if it is its own thread, it makes the lock continue to be used. If the thread performing the lock is a thread of a user program other than the user program 104 that called the process 300, the monitor entry process 300 determines whether the shared resource 109 is in use or the monitor exit process. At 400, it is checked with reference to the monitor management structure 107 whether the lock is released and nothing is being done. The monitor entrance process 300 calls the lock acquisition process 110 if the shared resource 109 is used, and waits for the release of the lock.
If not, the thread holding the lock is interrupted to execute the lock release request processing 500. The lock release request processing 500 is a lock release processing 1
Call 11 to release the lock.

An exclusive control method according to an embodiment of the present invention comprises:
As described above, the lock is not released in the monitor exit process 400, and the release of the lock is delayed until another thread uses the resource in the monitor entrance process 300. It is characterized in that whether or not to do so is determined based on the number of waiting threads.

As shown in FIG. 3, the monitor management structure 107 stores information such as an acquisition source thread identifier for identifying the thread that has acquired the lock, a release delay flag, the number of threads waiting for release, and the identifier or address of the lock record 108. It is comprised including. This monitor management structure 107
May include the lock record 108 itself instead of including the identifier of the lock record 108.

An operating system (OS) (not shown) operating in the CPU 101 counts the number of threads when generating a thread. At this time, the OS does not count the number of threads for threads specified in advance that the operation frequency is low or specified by the user program. As a result, only the number of threads whose operation frequency is high is counted. Here, a thread that is specified in advance as having a low operation frequency is a thread that operates when a certain period of time such as garbage collection or the like occurs or an event occurs, and is usually in a waiting state.

Next, the processing operation of the monitor entrance processing 300 will be described with reference to the flow shown in FIG.

(1) When the monitor entry process 300 is called from the user program 104, the thread identifier recorded in the designated monitor management structure 107 is
The identifier of the running thread is compared with the identifier of the running thread, and the thread from which the thread is acquired is the owner of the monitor, that is, the monitor entry process 300
It is checked whether the thread is the self thread of the user program 104 that has called (step 301).

(2) If it is determined in step 301 that the acquisition source thread is the self thread, the structure 10
7, the release delay flag is checked to determine whether or not the lock remains unreleased. If the release delay flag is ON, the thread that acquired the lock continues to use the lock. Since the shared resource 109 can be used, the release delay flag is reset to cause another thread to determine that the lock is being used, and the monitor entrance process ends. In this case, since the lock delayed in release can be used continuously, exclusive control processing 1
06 is not called (steps 302, 30)
3).

(3) If the thread identifiers do not match in step 301, that is, if the acquisition source thread is not the own thread, or if the release delay flag is not ON in step 302, the monitor entry process 300 Specifies the lock record specified in the monitor management structure 107 and calls the lock acquisition processing 109 to acquire a lock. The lock acquisition process at this time is
Pthread_lo which waits when lock is not acquired
This is executed by calling a function such as pthread_trylock () which returns an error when a lock is not acquired, instead of a function such as ck () (step 304).

(4) An error code is used to check whether the lock could not be obtained. If the lock was obtained instead of an error state, the identifier of the self thread is recorded in the monitor management structure 107, and the monitor entry process ends. I do. This case is executed when the lock is acquired for the first time, or when the lock is released by the monitor exit process due to the large number of threads (steps 305 and 306).

(5) If it is determined in step 305 that the lock acquisition has failed, the thread identifier recorded in the monitor management structure 107 is compared with the identifier of the operating thread, and the owner of the monitor determines It is checked whether the acquired thread is a thread, and if the acquisition source thread is a self thread, the acquisition source thread can continue to use the shared resource 109 by using the lock, so the monitor entrance process is terminated as it is (step 307).

(6) If it is determined in step 307 that the acquisition source thread is not the own thread, the number of threads waiting to be released is counted up, and it is checked whether or not the release delay flag is ON. If so, the other thread is still releasing the lock, so that the thread that has delayed the release is interrupted to activate the lock release request interrupt processing 500 to release the lock (steps 308 to 310). .

(7) If the release delay flag is not ON in step 309, or after the other thread releases the lock in the processing of step 310, pthread_lock
A function such as () is called to execute the lock acquisition process 109, and the process waits until another thread releases the lock (step 311).

(8) When the waiting state is released, the lock has been acquired, so that after subtracting the number of threads waiting to be released, the identifier of the self thread is assigned to the monitor management structure 107.
And the monitor entrance process ends (step 31).
2, 313).

Steps 302 and 30 described above
3. The comparison and assignment processing of the release delay flag in step 309 is performed by performing the comparison and assignment simultaneously.
It should be performed at the same time using an instruction such as a Compare & Swap instruction that performs control so that another CPU is not executed during execution of the instruction. The reason is that if step 309 is executed by another thread between step 302 and step 303, the thread executing step 302 performs the processing assuming that the lock can be continuously used. It is executed and the lock is released.

Next, the processing operation of the monitor exit processing 400 will be described with reference to the flow shown in FIG.

(1) The monitor exit process 400 first sets the lock release delay flag of the thread that has requested the lock release, and determines whether or not there is a thread waiting to release the lock. Is checked based on whether is larger than "0" (steps 401 and 402).

(2) If there is no thread waiting to release the lock in step 402, the counter of the number of threads with high operation frequency is referred to, and the number of user threads exceeds a predetermined number, for example, 1. Check whether it is
If not exceeded, the monitor exit process is terminated (step 403).

(3) If there is a thread waiting to release the lock in step 402, or if the number of user threads whose operation frequency is high in step 403 is larger than a predetermined number, the lock release interrupt processing 500
The release delay flag set in step 401 is reset in order to reduce the number of times of activation (step 404).

(4) Thereafter, the monitor exit processing 400
The thread identifier of the thread from which the monitor management structure 107 is obtained is reset to release the lock (step 40).
5, 406).

According to the above-described processing, if there is no thread waiting to release the lock, or if the number of user threads having a high frequency of operation does not reach a predetermined number, the lock may be released. And the release delay flag remains set.

The reason why the release delay flag is set first and then reset in the above-described processing flow is to prevent the lock from being held erroneously. That is, before one thread executes step 308 of the monitor entry process 300, another thread executes step 402 of the monitor exit process 400, and before the release delay flag is set by the monitor exit process 400, the monitor entry process starts. When step 309 is executed in 300,
The lock release request interrupt processing 500 is not activated and the lock is held, and the monitor entry processing 300
The thread that called is forever waiting. Such a situation can be prevented by setting the release delay flag before step 402.

Next, the processing operation of the lock release request interrupt processing 500 will be described with reference to the flow shown in FIG.

(1) Lock release request interrupt processing 500
Is activated, first, it is checked whether or not the lock release delay flag is ON by referring to the lock release delay flag, and if it is not ON, the process is terminated as it is (step 501).

(2) If the lock release delay flag is ON in step 501, the release delay flag is reset, and the lock release processing 110 is called to release the lock (steps 502 and 503).

As described above, only when the release delay flag is ON, by resetting the release delay flag and calling the lock release processing 110, the lock release processing 11 is executed.
0 can be prevented from being called many times.

In the above-described processing, step 5
01 and step 502 correspond to step 30 of process 300.
As in the case of step 2 and step 303, execution is performed by one instruction using an instruction such as Compare & Swap. However, if there is no problem even if the lock release process 110 is called any number of times, steps 501 and 502 need not be performed.

According to the exclusive control method according to the embodiment of the present invention described above, the thread that has acquired the lock keeps holding the lock until a thread other than the thread that has acquired the lock accesses the resource. Even if the monitor entrance process and the lock exit process are repeatedly performed in the same time, the lock acquisition process and the lock release process do not need to be called, so that the number of times of lock acquisition and lock release can be reduced, and the CPU required for the lock process can be reduced. Overhead can be reduced. The embodiment of the present invention is particularly effective when only one thread having a high operation frequency exists and the frequency of occurrence of the thread switch is low.

In the above-described embodiment of the present invention, the threads are classified according to the expected operation frequency, the number of frequently operated threads is counted, and if the number of frequently operated threads is large, the lock is released when a lock release request is made. , It is possible to prevent the lock release request interrupt from occurring frequently.

Further, by applying the exclusive control method according to the embodiment of the present invention to a computer system, a high-performance computer system can be configured.

[0047]

As described above, according to the present invention, the lock processing is particularly effective when a specific thread occupies most of the execution time, the frequency of thread switching is low, and contention for shared resources hardly occurs. , A high-performance exclusive control method capable of reducing the overhead of the CPU required for the above, and a computer system using this method can be provided.

[Brief description of the drawings]

FIG. 1 is a block diagram illustrating an example of a hardware configuration of a computer system according to an embodiment of the present invention.

FIG. 2 is a block diagram illustrating a processing configuration for implementing an exclusive control method according to an embodiment of the present invention.

FIG. 3 is a diagram illustrating a configuration of a monitor management structure.

FIG. 4 is a flowchart illustrating a processing operation of a monitor entrance processing.

FIG. 5 is a flowchart illustrating a processing operation of a monitor exit process.

FIG. 6 is a flowchart illustrating a processing operation of lock release request interrupt processing.

[Explanation of symbols]

 101 Central Processing Unit (CPU) 102 Main Storage Device 103 Thread 104 User Program 105 Monitor Process 106 Exclusive Control Process 107 Monitor Management Structure 108 Lock Code 110 Lock Acquisition Process 111 Lock Release Process 300 Monitor Entrance Process 400 Monitor Exit Process 500 Lock Release Request interrupt processing

Claims (5)

[Claims] An exclusive control method for a shared resource among threads in a computer system in which a plurality of threads can operate in parallel requires a first thread to acquire a lock on a shared resource to be excluded. When the lock is acquired, the thread identifier of the first thread is stored in a monitor management structure provided in a shared resource unit for exclusive use, and the release of the lock is delayed when the release of the lock is requested. Setting a release delay flag in the monitor management structure, and when the acquisition of the lock is again requested from the thread, the thread identifier stored in the monitor management structure and the thread of the thread that issued the lock acquisition request The request for acquisition of the lock is compared with the first
It is determined whether or not the lock release is delayed from the first thread by checking the release delay flag to determine whether or not the lock release is delayed. An exclusive control method characterized by causing the first thread to continue using the lock when the lock acquisition request is issued and the lock release is delayed. 2. The method according to claim 1, wherein the request to acquire the lock again is not a request to acquire a lock from the first thread, but another request to acquire a lock.
2. The exclusive control method according to claim 1, wherein, if the request is issued from the first thread and the lock release is delayed, an interrupt is issued to the first thread that has acquired the lock to release the lock. . 3. The release delay flag set includes distinguishing a thread into a thread with a high operation frequency and a thread with a low operation frequency, counting and holding the number of threads with a high operation frequency, 2. The exclusive control method according to claim 1, wherein the method is performed when the number of threads is equal to or less than a predetermined number. 4. In a computer system in which a plurality of threads can operate in parallel, means for acquiring a lock on a shared resource to be excluded from the first thread when the first thread requests the acquisition of the lock, Means for storing a thread identifier of the first thread in a monitor management structure provided in an exclusive shared resource unit, and delaying the release of the lock when the release of the lock is requested, the monitor management structure Means for setting a release delay flag to the thread, and comparing the thread identifier stored in the monitor management structure with the thread identifier of the thread which has issued the lock acquisition request when the lock is again requested by the thread. Means for determining whether or not the request to acquire the lock is from the first thread; and Means for identifying whether or not the lock release has been delayed; and
Means for causing the first thread to continue using the lock when the lock acquisition request is issued from the other thread and the lock release is delayed. 5. The request for acquiring a lock again is not a request for acquiring a lock from the first thread, but another request for acquiring a lock.
5. The system according to claim 4, further comprising: means for interrupting the first thread that has acquired the lock to release the lock when the request is from the first thread and the lock release is delayed. Computer system.