JPH06318191A - Multi-thread processing system - Google Patents

Abstract

PURPOSE:To reduce overhead at the time of starting/ending parallel operation by keeping threads at a waiting state without ending them at the time point of end of a parallel processing part, and at the time of starting succeeding parallel processing, restarting the waited threads to execute the parallel processing without generating new threads. CONSTITUTION:This multi-thread processing system is provided with threads 15 and parallel calling processing 13, and when a waiting thread 15 exists, the processing 13 called out at the time of starting parallel processing in a program allocates a parallel execution enabled program part to the thread 15. When there is no waiting thread 15, a new thread 15 is generated, the parallel execution enabled program part is allocated to the newly generated thread 15 to execute the program part, and at the time of ending the processing, the thread is managed as a waiting thread 15.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a multi-thread processing system for performing parallel processing by a plurality of threads.

In recent years, a UNIX system equipped with a parallel operation mechanism called a thread has appeared, and it is desired to efficiently perform parallel processing on a multiprocessor.

[0003]

2. Description of the Related Art In an application program requiring performance such as scientific and technological calculation, execution performance is improved by executing DO loops and subroutines in parallel by a plurality of CPUs. For example, the two CPUs 1 and 2 shown in (a) of FIG. 8 and the four CPUs shown in (b) of FIG.
Programs and data are loaded into an MSU (main storage device) accessible from one CPU1, CPU2, CPU3, and CPU4, and each CPU1, 2, and further CPU3, CPU4
Execute the part of the program they should be in charge of. In these systems, ideally, the time of 1/2 (in the case of (a) of FIG. 8) and 1/4 (in the case of (b) of FIG. 8) when the original program is executed by one CPU Ends the job execution.

In practice, since the execution efficiency is greatly affected by the structure of the program (there are few loops that can be executed in parallel) and the overhead of parallel processing control, rewrite the user program into a structure suitable for parallel processing ( User program tuning) and parallel processing control overhead reduction (system tuning)
By performing, it is possible to approach the ideal performance. Here, the related art will be described below regarding the overhead of parallel processing control.

A job is composed of a plurality of tasks corresponding to the number of CPUs. For UNIX system, Fortra
Execute as a multi-thread program in which n jobs are processes and tasks are threads.

The operating system (OS) is C
Assign PUs and threads. When the thread
The run-time library controls which program parts are processed in parallel.

As a program portion for parallel processing, a subroutine is used as a unit of parallel processing, or 100
The DO loop that makes 0 rotations is divided into four 250 rotations, and the DO loops are executed in parallel.

In any case, from the start of program execution,
There is a sequential processing part up to a certain part, and after performing parallel processing, the program is terminated by returning to the serial processing again. Figure 9
In the example of, the sequential processing is performed up to (a). At the time of (a), the parallel processing of the two program parts (b) and (c) is started. Then, at the time point (d) when the operations of (b) and (c) are both completed, the program again becomes a sequential processing operation. When the operations (a) to (d) are included in the loop, the cost of the start / end processing of the parallel operation is increased by the same as the loop rotation speed. Further, the program parts (b) and (c) operating in parallel may also include the start / end part of the parallel processing.

[0009]

In science and technology calculation, the amount of computation (DO loop, subroutine, etc.) that is a unit of parallel processing is 1/1000 or 1 compared with the amount of computation of input / output processing such as PRINT statement. This is a small value of / 100, and there is a big difference between the conventional parallel processing of input / output processing and calculation.

Therefore, even if the cost of the parallel processing unit is small, in order to perform parallel processing efficiently, it is necessary to make the overhead required for controlling parallel processing relatively smaller than the amount of operations to be executed in parallel. is there.

In order to perform the start / end processing of the parallel operation, it is conceivable to use the system call of the thread generation processing provided in the OS so that the program portion to be executed in parallel and the threads are in one-to-one correspondence. To be That is, at the stage of starting the parallel operation, a thread corresponding to the parallel operation part is generated. In the example of FIG. 9, at the time of (a),
To execute (b) and (c) in parallel, issue a system call (pthread create) for thread creation, and immediately after that, issue a system call (pthread join) that waits for the end of each of (b) and (c). To do. This allows
When the parallel processing of (b) and (c) is completed, the wait for phread join is released, and the process reaches (d). In (d), a system call (phread delate) for erasing the thread is issued.

In this way, the processes such as thread generation, thread waiting, and thread erasing are sequentially performed to perform the parallel processing of FIG. 9. Therefore, the processing time for creating and erasing these threads is the time required for the parallel processing. However, there is a problem that the time becomes too large to be ignored, and especially when repeating in a loop, it takes a long time.

The present invention solves these problems.
Do not terminate the thread at the end of the parallel processing part, put it in the waiting state, restart the thread in the waiting state without generating a new thread when starting the next parallel processing, and perform parallel processing, It aims to reduce the overhead of starting and ending parallel operations.

[0014]

FIG. 1 shows a block diagram of the principle of the present invention. In FIG. 1, the parallel call processing 13 is
It is called from a program at the start of parallel processing, allocates a parallel-executable program part to the thread 15 and executes the same, and manages the waiting thread 15.

The thread 15 takes in a program part which can be executed in parallel and executes a process.

[0016]

According to the present invention, as shown in FIG. 1, when there is a thread 15 waiting for a program portion in which the parallel call processing 13 called from the program can be executed in parallel, the thread 15 can be executed in parallel. On the other hand, if there is no waiting thread 15, a new thread 15 is created, a parallel executable program section is allocated to this thread 15 and executed, and a thread waiting when the processing ends. The number of threads 15 generated / erased at the start / end of parallel processing is reduced.

Therefore, at the end of the parallel processing part, the thread 15 is not terminated but kept in the standby state, and when the next parallel processing is started, a new thread 15 is not generated and the thread 15 in the standby state is not generated. By restarting and performing parallel processing, it is possible to reduce the overhead of starting and ending the parallel operation.

[0018]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Next, the construction and operation of an embodiment of the present invention will be sequentially described in detail with reference to FIGS.

FIG. 1 shows a block diagram of the principle of the present invention.
In FIG. 1, the main storage device 11 includes a plurality of CPUs 1, 2
... A storage device accessible from n, for loading programs, storing data, etc., and storing the OS 12, the parallel call processing 13 and the standby state as shown in the figure. It is a storage device for storing the threads 14, the user program 17, and a subroutine.

The OS 12 is an operating system that controls the entire system, and here creates a thread and deletes a thread.

The parallel call processing 13 is called from the program at the start of the parallel processing, and the parallel executable program portion is assigned to the thread 15 waiting or the thread 15 newly created when there is no thread 15 waiting. And executes the thread 15, and manages the thread 15 for which parallel processing has ended in a standby state.

The waiting thread 14 is for managing the waiting thread 15. Here, the management block 16 is linked or pointed to manage the thread 15 represented by the management block 16. It is a thing.

The thread 15 takes in a program part which can be executed in parallel and executes a process, and is specified by the management block 16. The management block 16 manages information that identifies the thread 15, and here sets and manages the following information.

Thread identifier: This is an identifier of the thread notified from the OS 12 when the OS 12 is requested to create a thread. Address of next management block: Used for chaining management blocks 16.

In-execution flag: a flag for identifying whether it is in a normal operation state or a standby state. Information about calling: The entry address of the subroutine to be executed, the parameters to be passed to the subroutine, and the number of parameters.

The user program 17 is a program for performing business processing, and here, calls the subroutines 1 to n to perform parallel processing. CPU1
To CPUn are a plurality of CPUs and a CPU group that processes the user program 17 in parallel.

FIG. 2 is a diagram for explaining management of waiting threads according to the present invention. FIG. 2A shows a state in which a plurality of management blocks 16 are sequentially managed by a link from the waiting thread 14.

FIG. 2B shows how a plurality of management blocks 16 are managed by pointers from the waiting thread table. As described above, a plurality of management blocks 16 are managed by links from the waiting thread 14 and a plurality of management blocks 1 are managed by pointers from the waiting thread table.
6 is managed, when the parallel call processing 13 allocates a program part that can be processed in parallel to the thread 15, and when there is the waiting thread 15, the parallel call processing 13 allocates it to the parallel processing (parallel processing). Is resumed after the processing is completed, and is returned and managed as a thread 15 in a waiting state. It is possible to reduce the overhead at the start / end. Here, a system call (pthread create) is issued to create the thread 15 and a system call (pthread del is created to delete the thread 15).
ete) is issued. On the other hand, in the present invention, a system call (pthread cond signal) is used to restart the thread 15.
Is issued and a system call (pthread cond wait) is issued to make the thread 15 wait. Here, the latter thread restart / wait processing amount is smaller than that of the former thread creation / erasure, and as a result, the overhead for starting / ending parallel processing can be reduced. The details will be sequentially described below.

The operation of the configuration of FIGS. 1 and 2 will be described in detail in the order shown in the flow charts of FIGS. In FIG. 3, S1 is initialized. This makes various initial settings of the device and makes it operational.

In step S2, it is determined whether or not there is a parallel processing instruction. This is performed by sequentially reading the program (object) of FIG. 6 line by line and determining whether there is a parallel call instruction of (3) of FIG. 6, for example. If YES, the parallel call process 13 is called in S3, and the process proceeds to S4. On the other hand, in the case of NO, it is determined that the instruction is not the parallel processing instruction. Therefore, the next line is read and executed in S10, and S2 is repeated.

In S4, only parallel calls are discriminated. this is,
The parallel call processing 13 called in S2 determines whether the instruction in the line of the program which is currently to be executed is parallel call.
In the case of YES, it is determined in S5 whether or not there is an empty thread in the waiting state, and in the case of YES, the processing of the waiting thread 15 is restarted in the processing of S6 to S9 and the process proceeds to S9. The thread 15 is generated, and the process proceeds to S9. on the other hand,
In the case of NO in S4, instead of calling in parallel, for example EN
Since it was D PARCALL (end of parallel execution), the process proceeds to S15 of FIG.

In S6, since it is determined that there is a waiting thread 15 in YES in S5, the management block is removed (see FIG. 2).
reference). In S7, the information regarding the call is set in the management block removed in S6.

In S8, the execution flag of the management block is set to O.
Set to N. S9 starts parallel execution. When there is a waiting thread 15 by the above S6 to S9,
The management block of this waiting thread 15 is removed, information regarding the call is set in this management block, the execution flag is turned ON, and the actual parallel processing is started. With this, rather than replaying and starting a new thread, processing by the waiting thread is resumed,
The processing amount can be reduced. Then, when the parallel processing ends, the process returns to S4 and becomes NO, and S15 of FIG.
Proceed to the end of parallel processing below.

In S11, since it is determined that there is no waiting thread 15 in NO in S5, the management block area is acquired and initialized (see FIG. 2). In step S12, information regarding calling is set in the management block.

In step S13, the in-execution flag of the management block is turned on. In S14, the OS is requested to create a thread. In S9, the thread newly generated in S14 executes parallel processing.

By the above S11 to S14 and S9,
If there is no thread 15 waiting, a new management block is created, information regarding the call is set in this management block, the running flag is turned ON, and then a new thread 15 is created. Start executing the process. As a result, when there is no waiting thread, the parallel processing that creates a new thread can be started.

In step S15 of FIG. 4, if NO in step S4 of FIG. 3, that is, if the parallel processing is completed, it is determined whether the subroutine has completed the processing. This means that if the in-execution flag of the thread executing the subroutine is OFF, the processing of the subroutine is completed. If YES, S16
Proceed to. If NO, wait for the subroutine to finish processing.

In step S16, the management block is returned to the waiting thread 14. This is YES in S15, and the thread 15 that has executed the parallel processing has completed the processing of the subroutine. Therefore, the thread 15 is returned to the waiting thread 14 in FIG. 2 to prepare for the next parallel processing.

In step S17, it is determined whether or not all the subroutines called in parallel have finished processing. If YES, S1
Post-processing is performed at 8, and the process ends. If NO, S15
Repeat the above.

As described above, parallel execution processing is performed, and when the called subroutine finishes the processing, returning to the waiting thread 14 is repeated, and all the subroutines called in parallel wait until the processing is completed. When the processing ends, post-processing is performed and the processing ends. By these, the thread 15 that has performed parallel processing is linked to the management block and managed, and this thread 15
By retrieving and executing (resuming) parallel processing, there is no need to repeat thread creation / deletion at the start / end of parallel processing, reducing the amount of processing at the start / end of parallel processing and reducing overhead. it can.

Next, by S21 to S24 of FIG.
Parallel execution processing by another thread will be described. Figure 4
In S21, the process waits until another thread starts parallel execution in S9.

In step S22, information regarding the call is retrieved from the management block. S23 calls a user subroutine. In S24, the execution flag of the management block is set to OF.
Set to F.

As described above, another thread waits until the parallel execution of S9 by the other thread is started, and when the parallel execution is started, the information regarding the call is taken out from the management block, and the user subroutine is called based on this information to perform the processing. After the request, the in-execution flag of the management block of its own thread is asynchronously turned off from the caller. Then, the process proceeds to S15, and the management block is returned to the waiting thread when the called subroutine finishes the processing.

FIG. 5 shows an operation conceptual diagram of the parallel processing program of the present invention. Here, (1) to (7) correspond to (1) to (7) in FIG. Here, as shown in the figure, MAIN of the parallel processing program starts the parallel processing at (1), creates the thread 15 and executes the subroutine S1, and creates the thread 15 and starts the execution of the subroutine S2 in parallel. .

In the subroutine S1 in which the parallel execution is started, the parallel processing is further started in (3), the thread 15 is created to execute the subroutine S3, and the thread 15 is created to start the execution of the subroutine S3 in parallel. And
The parallel processing of (7) is executed respectively and the processing is terminated.
In (4), the parallel processing of the subroutine S3 is finished, and the processing returns to the processing of S1 of the subroutine.

Similarly, the subroutine S which has started parallel execution
In (2), the parallel processing is further started, and the thread 15 is created to execute the subroutine S3, and the thread 15 is created to execute the subroutine S3 in parallel. Then, the parallel processing of (7) is executed to end the processing, the parallel processing of the subroutine S3 is ended in (6), and the processing returns to the processing of S2 of the subroutine.

Next, in (2), the parallel processing of the subroutine S1 and the subroutine S2 is completed, and the process returns to MAIN.
At these times, parallel execution is started (1), (3),
When there is no thread 15 waiting in (5), it is created and executed in parallel, and the parallel execution ends (4), (2),
At the time of (6), the thread 15 is managed as a waiting state, and at the time of the next and subsequent repeated loops, (1), (3),
In the present application, by allocating and using the waiting thread 15 at the time of (5), the management and parallel processing are resumed while the thread 15 is waiting, as compared with the conventional case where threads are created and deleted each time. The amount of processing can be reduced, and especially the overhead at the time of parallel call can be reduced.

FIG. 6 shows an example of the program of the present invention. This is a description of the operation conceptual diagram of FIG. 5 in the image of an actual program, and includes (1) to (7) and MAI.
N, S1, S2, and S3 correspond to those in FIG.

In FIG. 6, the parallel call processing 13 is called at the start of parallel execution and returns at the end of parallel execution, and the thread 15 is executed at (1), (3) and (5) in FIG.
Is assigned (if there is a waiting thread 15, this is assigned; if there is no waiting thread 15, the newly created thread 15 is assigned), and the subroutines are executed in parallel.

MAIN is the main program,
The parallel call processing 13 is called to execute the subroutines S1 and S2 in parallel. S1 is a subroutine, which is called from MAIN in parallel here, and calls the parallel calling process 13 to execute two subroutines S3 in parallel.

S2 is a subroutine, which is called in parallel from MAIN in this case, and calls the parallel calling process 13 to execute two subroutines S3 in parallel.

S3 is a subroutine, which is the core of the arithmetic processing, and is called in parallel from each of the subroutines S1 and S2 to perform the parallel execution processing.

FIG. 7 shows a conceptual diagram of threads and subroutines of the present invention. In FIG. 7, the process is a process (job) created by the OS.

T1 is the thread 1 newly created at the beginning
Is. t2 is a thread generated at the time of the system call during execution of the thread 1 of t1. In addition, the thread 2 at t2 is made to disappear here by a system call at the end of parallel execution (when forming a loop and repeating, it is set to the waiting thread 15 described above, and the waiting thread 15 is allocated from next time to parallel processing. Execute (restart)
Let

[0055]

As described above, according to the present invention,
At the end of the parallel processing part, the thread 15 is not terminated but is put in a waiting state, and when the next parallel processing is started, a new thread 15 is not generated and the waiting thread 15 is allocated and restarted. Since the configuration that performs parallel processing is adopted, the overhead of starting and ending parallel operation can be reduced.

[Brief description of drawings]

FIG. 1 is a principle block diagram of the present invention.

FIG. 2 is an explanatory diagram of management of a waiting thread according to the present invention.

FIG. 3 is a flowchart (No. 1) for explaining the operation of the present invention.

FIG. 4 is a flowchart (part 2) for explaining the operation of the present invention.

FIG. 5 is an operation conceptual diagram of a parallel processing program of the present invention.

FIG. 6 is an example of a program of the present invention.

FIG. 7 is a conceptual diagram of threads and subroutines of the present invention.

FIG. 8 is a hardware configuration diagram of parallel processing.

FIG. 9 is a structural example of a parallel program.

[Explanation of symbols]

 11: main memory 12: OS (operating system) 13: parallel call processing 14: waiting thread 15: thread 16: management block 17: user program

Claims (1)

[Claims] 1. In a multi-thread processing method for performing parallel processing by a plurality of threads, a thread (15) that takes in a program portion that can be executed in parallel and executes the processing, and a parallel execution that is called at the start of parallel processing in the program. A parallel call process (13) that allocates a possible program part to the thread (15) and executes the thread (15) and manages the waiting thread (15), and the parallel call that is called at the start of the parallel process in the program When there is a thread (15) waiting for the program part that can be executed in parallel by the process (13), the program part that can be executed in parallel is assigned to this thread (15),
On the other hand, if there is no waiting thread (15), a new thread (15) is generated, a parallel-executable program part is allocated to this thread (15), and the thread is executed. A multi-thread processing system characterized by being configured to be managed as threads (15).