JPH03218539A - Debug method in parallel computer system - Google Patents

Abstract

PURPOSE:To detect the cause of a deadlock state by linking a debug processing control routine to a compiling source program when there is a bug in a sub-program. CONSTITUTION:All processor element 24-0 to 24-n are set to a state where they can be started by the debug processing control routine of a host computer 10, and the processor elements are actually operated one by one. When the processor element which comes to a data waiting state stops and the information on a resuming address and the state are given to the host computer 10, it starts the other processor and the processor element in the data waiting state is registered in a starting table or a queue. For selecting one element to be started, the initialization of the starting table or the queue is variously changed and the starting order of the processor elements is changed as against a processing which is originally executed in parallel. Thus, the bug can easily be removed from trace data of respective conditions.

Description

[Detailed Description of the Invention] [Field of Industrial Application] The present invention relates to parallel computer systems, and in particular to a debug processing control method for eliminating bugs inherent in parallel processing of user programs written for each processor element, and a debug processing control method therefor. Regarding the system.

[Prior art]

In order to improve computer speed, parallel computer systems have been devised that run multiple processor elements simultaneously.

Conventional parallel computer systems include those in which all processor elements are connected to a shared memory and data exchanged via that memory, and those in which each processor element has local memory and data is exchanged via a network. There are types that transfer data directly to other processor elements. In the former, synchronization control is performed to control the shared memory access order during data transfer, and in the latter, synchronization control is used to control the order of data transmission and reception from other processor elements. Control is exercised.

Conventional languages such as FORTRAN are used as user interfaces for parallel computer systems, or dedicated languages are prepared.

When programs are coded using these languages, bugs specific to parallel processing may be introduced into the programs. Bugs specific to parallel processing include those caused by multiple processors defining and using the same address due to incorrect synchronization control (including omissions) for ordering required when accessing shared memory, and bugs caused by distributed memory. On the other hand, there are errors in data transmission and reception (including omissions) and algorithm errors that occur when rewriting programs.

In particular, when parallel processing is performed without synchronization control, the execution order of each process is not guaranteed, and the execution order differs each time the processes are executed, so reproducibility is not guaranteed.

Although there is no established method for debugging such parallel computers, several debugging methods have been considered to remove these bugs. SEQENT COMPUTER is a product that is available in the world.
“Pdbx ParallelDeb” from SYSEMS
There is a product pamphlet “PdbxPa
ralrel Debugger for Balan
ce Computer System IIIs”.This product supports Psst/Wa during parallel execution.
We have prepared a means to recognize the parallel operation status by outputting a trace regarding IT synchronous control. Also,
It has the ability to interrupt processor execution midway through. In order to debug a program that contains a bug due to incorrect synchronization control in a stable and reproducible state, execute it sequentially instead of processing in parallel, and check the state of the data at that time to find out whether the synchronization control is defective or not. It is desirable to detect

JP-1- How to execute processing sequentially during debugging
106234. However, here, all processes are once executed in parallel, and the trace data at that time is used to determine the order of processes to be executed sequentially.

[Problem to be solved by the invention]

This prior art requires parallel execution before serial execution. In addition, in general, in programs for parallel computer systems, executable statements for data transmission and reception and synchronization control are written in the user program. There is a problem in that the program continues to wait for data that will not be sent during execution, resulting in a data waiting state in which calculation cannot proceed, and the execution of the program stops. In other words, the program execution stops even though it is a normal program.

SUMMARY OF THE INVENTION An object of the present invention is to solve the above-mentioned problems and provide a method for sequentially executing programs written for each processor in a simpler manner to execute them in parallel.

Another object of the present invention is to provide a method for sequentially executing such programs without falling into a data waiting state through normal data transmission/reception and synchronous control.

Another object of the present invention is to provide a debug processing control method and a system therefor, which can prepare a normal execution library and a debug execution library and perform debug processing without modifying the main program of a user program. It is about providing.

[Means to solve the problem]

In order to achieve the above object, the present invention sequentially executes a parallel processing program using the following method.

First, an overview of the operation of this embodiment will be described. The debug processing control routine called in the user program for the host computer executes the following processing: (1) As initialization, all processor elements that have been enabled to start are activated so that they are referenced by the host computer. Added to a table or queue.

(2) Any one of the processor elements that can be activated
One processor element is activated, and the processor element is in the "data waiting state" or "processing completed state".
It executes the corresponding program until it reaches , passes its status and restart address to the host computer, and then stops.

(3) While repeating the process in (2), processor elements to be executed at the same time are moved one by one until there are no more executable processor elements.

(4) In order to select one of the processor elements that can be activated in (2), the initial settings of the activation table or queue are changed variously, and the processor elements are used for processing that should originally be executed in parallel. Change the startup order of .

[Effect]

Through process (1), the host computer's debug processing control routine brings all processor elements into a state where they can be activated.

Through processes (2) and (3), the processor elements can actually be moved one by one. "Waiting for data"
The processor element that has become disabled stops and notifies the host computer of its status along with the restart address, and the host computer that receives the notification starts up other processors. In this way, subprograms for each processor element, including synchronization control, are necessary for sending and receiving data required for distributed memory and for ordering shared memory accesses. 1 while following the order specified by synchronous control.
It becomes possible to execute on one processor element at a time. Also, by registering the processor element to which the restart address was passed in the "data waiting state" in the startup table or queue and executing other processor elements, data arrived and it became possible to execute the processor element. In this case, the processor element below can be activated.

Through process (4), the order of processes that should originally be executed in parallel can be varied in various ways within the scope of data transmission/reception and synchronization control described in the user program.

As a result, various execution orders that can occur during parallel execution can be realized while only one processor element is running, and processing can be temporarily performed interactively similar to conventional debugging on one processor element. It is also possible to use methods such as interrupting or outputting data.

These functions make it possible to detect calculations that would result in incorrect results if executed in parallel, and errors in synchronization control (missing Send/Receive, mismatched correspondence relationships) from the trace data of each situation. It is possible to easily remove bugs in user programs that cause abnormal termination of processing or incorrect results.

The details of the embodiment will be described below.

〔Example〕

DESCRIPTION OF THE PREFERRED EMBODIMENTS A debug processing control system according to an embodiment of the present invention will be described below with reference to the accompanying drawings, targeting a distributed parallel computer having local storage.

FIG. 2 shows an overview of a parallel computer system including a debug processing control system.

The host computer 10 has a main memory 12. I/O Process
or 1 4, and has an instruction processor 16. The main memory includes an execution processor queue 12-1, an end determination queue 12-2, and a mainProgram 1
3-1. Two libraries 13-2 and 13-3 are stored, one for normal processing and one for debug processing. I/O device 17 is connected to I/O processor 14 .

Array controller 22 is connected to instruction processor 16. The host computer 10 controls n+1 processor elements 24-0 to 24-n through the array controller 22. Each processor element has local storage and is assigned a processor number.

Each processor element sends and receives data to and from each other via the network 28. Each processor element has local memory 26-O of other processor elements.
26-n, but the main memory 21 in the host computer 10 can be freely accessed via the array controller 22 that connects the processor element group and the host computer.

FIG. 3 shows an example of the main program of the user program for such a parallel computer system. When the main program 13-1 is executed by the host computer, a load routine 33 for loading a subprogram from the main memory 12 to each processor element by a statement 31 in the main program 13-1 is called a load module name, ie, "SUBI". ” is called as an argument.

Next, the statement 32 calls the normal processing control routine 34 for starting the processor element, using the processor element subprogram entry name "SUB 1" as an argument.

As shown in FIG. 8, the present invention includes a library 13-3 containing a normal processing control routine for starting all processor elements at once during normal processing, and a library 13-3 containing a normal processing control routine for starting all processor elements in sequence during debug processing. A library 13-2 containing debug processing control routines is prepared.

The two libraries 13-2 and 13-3 are the same except for both control routines. Both routines are given the same entrance name, and after the main source program 15-1 is compiled, the library 13-2o is
Main program 15-2 with r 13-3 compiled
linked to. Therefore, after the main source program 15-1 is modified for debugging, it is not necessary to compile and link the library 13-2. In addition, after the debugging process is completed, the main source program 15 is
−1 is reverted, compiled, and library 13−
There is no need to link with 3. The user can select a library according to the processing purpose and link it with the compile main program. This allows debugging and the like to be performed easily and in a short time.

FIG. 1 shows an overview of the processing of the debug processing control routine 34. Execution processor queue 12 used here
The configuration of 1 is shown in FIG. Execution processor queue 12-
Each element of 1 includes a processor number 41 indicating the number of the processor to be executed, an execution start address 42 of the subprogram to be executed by that processor, and a pointer 43 for indicating the next queue element.

The outline of the debug processing control routine 34 in FIG.
An example in which each processor element executes the subprogram shown in the figure will be explained.

Fig. 3 is executed, a load routine 33 is executed at statement 31, and each subprogram is transferred from the main memory to the local memory 2 of the corresponding processor element.
6-i (i=o, n).

Statement 53 represents a call to a transmission processing routine for data transmission. In statement 53, the first argument “N + 1
" indicates the processor number of the destination processor element of the data, the second argument "N+1" indicates an identifier for distinguishing the transmitted data, and the third argument "'R" indicates the transmitted data. Statement 54 represents a call to a reception processing routine for receiving data. In the sentence 54, the first argument J' N 77 represents an identifier for distinguishing received data, and the second argument "p I+" represents received data.

When this receive routine is called, the data “P”
If ``P lj'' has not arrived, the processor element does nothing and enters a data waiting state where it waits for the arrival of data ``P lj.'' Statement 56 represents a call to a dump routine to output the calculation result, and the first argument 1 (N lj represents the processor number, the second argument "A" represents the output array, and the third argument "N-1" and the fourth argument IN 3 1F represent the elements and number of the output array.

Formal arguments j(A” and it N of subroutine 50 in FIG.
It can be seen that I+ is in the main memory of the host computer from the declaration 51. 6N" represents a processor number. The case where this subprogram 50 is executed by each processor element when priorities are assigned in order of decreasing or increasing processor number will be explained with reference to FIGS. 6A and 6B. do.

Statement 32 in main program 13-1 is executed and debug processing control routine 34 is called.

In the debug processing control routine 34, first in step 1, the host calculation 1!110 registers the status of all processor elements in the execution processor queue 12-1 with the entry address of the subprogram 50 as the execution start address. 61 in Figure 6A when the processor numbers are in ascending order.
, in descending order, it becomes like 65 in FIG. 6B. The end determination queue 12-2 stores the state of the execution processor queue 12-1 at an appropriate time, for example, at the start, in order to detect a deadlock state during data transmission and reception. The queue 12-2 is used to determine whether each processor element that is not in the termination state is in a deadlock state waiting for data or in a normal execution state. Therefore,
The termination judgment queue 12-2 is also the execution processor queue 12-.
Similar to 1, it has the format shown in Figure 4.

In step 2, an arbitrary processor element is selected from among the processor elements registered in the execution processor queue 12-1, and the corresponding queue element is deleted from the queue.
Activate this processor element.

In ascending order, the processor element with processor number O is selected first, and when it is activated, it waits for data at statement 54. On the other hand, in descending order, the processor element with processor number N is selected and activated first, and the queue element for processor N is deleted from the execution processor queue.

Depending on the initialization of step 1 and the selection of step 2, the execution order among the processor elements can be changed. The elements of the execution processor queue may be simply arranged in ascending or descending order of processor number as in this example, or they may be arranged randomly, or a certain unique processor may be placed at the top.

The activated processor element executes until it waits for data or terminates, while outputting data related to sent and received data necessary to understand the execution status and the values of variables and arrays in the selected local memory as trace data. .

Once the processor element has been activated, in step 3 the processor element waits until the re-execution address is returned after the processor element has "finished execution" or has become "waiting for data".

If "execution completed" is returned, the process proceeds to step 5 via control step 4. In step 5, if the execution processor queue 12-1 is empty, the debugging process is terminated, and if a processor element is still registered in the execution processor queue 12-1, in step 9, the termination judgment queue 12-1 is empty.
After updating step 2, control returns to step 2.

On the other hand, when "waiting for data" is returned, the process proceeds to step 6 via control step 4. In step 6, the processor number of the processor element in question is registered at the end of the execution processor queue 12-1 along with the start address6. , in ascending order, the address of statement 54 is registered at the end of the execution processor queue in step 6, and the execution processor queue becomes as shown at 62 in FIG. 6A.

On the other hand, when lIiJi@, processor N first executes the process, but waits for data at statement 54, and at step 6 the execution processor queue becomes as shown at 66 in FIG. 6B.

Then step 7 is executed.

In step 7 and subsequent step 8, it is determined whether the debugging process is complete. If the processor element registered in the execution process queue 12-2 is equal to the processor element registered in the termination determination queue 12-2, and the start addresses of both queues are the same for each processor element, then all the processor elements Wait”
This indicates a deadlock situation where nothing can be executed. In this case, data indicating that these processor elements are in a deadlock state is output to the I/O device 17. Furthermore, when the processor elements in the execution processor queue 12-1 and the completion determination queue 12-2 are different, the possibility of execution of all processor elements has not been denied, so control returns to step 2 via step 9. Starts the next processor element. If the starting addresses of the processor elements are different or if the execution processor queue is not empty in step 5, step 9 is executed. In step 9, the contents of the execution processor queue are registered in the termination determination queue. Further, in the example of ascending order, the termination determination queue 12-2 is updated to the state of 62, control returns to step 2, and the processor 1 is then activated. When processor 1 is executed, processor 0 has already transmitted the data to be received by processor 1 in statement 53, so the process proceeds to the end without waiting for data in statement 54 and ends the execution. Therefore, processor 1 is not registered and the execution processor queue 12-1 is 6 in FIG. 6A.
If the debugging process proceeds in the manner shown in 3, the debugging process ends with the processor O left in the queue 12-1.

In the case of descending order, processor N-1 is activated in step 2 after processor N terminates. At this time as well, the trace data described above is output in order to understand the parallel execution status. In this case, since the data to be received in statement 54 has not been sent, all processor elements are passed around, and the execution processor queue 12-1 is stored at 67 in FIG. 6B.
become that way. In the second round, processor N is
When starting from , the received data has already been transmitted by statement 53 of processor N-1 in the first round, so the process is executed to the end and ends.

Therefore, the execution processor queue 12-1 is 68 in FIG. 6B.
become that way. In this way, in the second round, the received data is received by the processor elements one after another, and finally only processor O remains in the execution processor queue 12-1.

Regardless of whether the process is performed in ascending order of processor numbers or in descending order, it can be seen that when the processing is completed, the actual suppressed processor queue 12-1 is not empty and processor 0 is still waiting for data. This clearly indicates that there is a bug in the source program, and the error must be corrected by either sending data to another processor element or, in the case of processor 0, not receiving data. I know it won't happen.

Also, the array A that exists in the main memory 12 of the host computer 10 and is defined and referenced by each processor element.
If the trace data related to the above is collected when the statement 56 is executed, it will be as shown in 70 in FIG. 7A in the case of ascending order, and as shown in 71 in FIG. 7B in the case of descending order.

In the case of ascending order, for example, array A(1) referenced by processor 2 is a value defined by processor 1, as shown in FIG. 7A. In this way, the values defined by the most recently activated processor are used. However, when executed in descending order, each processor element executes the subprogram "SU" as shown in FIG.
The value of array A immediately before execution of "BI" is referenced.

After all processor elements finish referencing array A, each processor element defines the value of array A. As a result, even if the order of data transmission and reception is maintained, the calculation results will differ between ascending order and descending order. It can be seen that the reason why the calculation results differ each time when the processor elements are operated in parallel is that the definition reference order of the array A in the main memory is undefined. Therefore, main memory array A
It is possible to detect the need to modify the source program by inserting synchronization control that fixes the definition reference order.

〔Effect of the invention〕

According to the present invention, in the above embodiments, a parallel computer consisting of processor elements having local memory was described, but in a parallel computer consisting of processor elements connected via a shared memory, the above embodiments can be used. "Synchronous control" instead of "data transmission and reception"
Detection of processing failures, including errors, can be detected in the same way.

If there is a bug in a subprogram including data transmission/reception and synchronization control provided for each processor element for multiple processor elements running in parallel, you can run the debug processing control routine without recompiling the source program. By simply linking to a compiled source program, processor elements can be executed one by one in various orders as long as the order specified by data transmission/reception and synchronization control is maintained. As a result, by collecting and analyzing trace data in various execution orders, it is possible to detect defects such as data transmission/reception omissions and synchronization omissions, where calculation results differ depending on the execution order, and causes of deadlock conditions. As described above, various methods can be considered for the order in which processor elements are registered in the execution process queue. Basically, it is up to the user's choice, but the following algorithms can be considered depending on the purpose of debugging and the program to be debugged.

If the process execution order is random, there is a method of determining the execution order by generating random numbers regarding the execution start time. On the other hand, when it is necessary to shorten the debug processing time, it is desirable to determine the execution order so that processes that involve a large amount of data transmission are executed with priority.

In addition, although a termination judgment queue is used in this example,
Even if the queue is not used, it is sufficient to detect that the corresponding subprogram has been executed and completed by each processor element. For example, it is possible to simply store the processor number of the processor element that has finished executing the corresponding subprogram. In this case, if a processor element remains as in the above example, it is sufficient to activate the processor element again, and if the result is the same as the previous time, it may be determined that the process has ended.

Furthermore, although in this embodiment an execution processor queue is used, it is clear that a simple table could also be used. In this case, as shown in FIG. 9, the execution processor table 12-5 and the termination determination table 12-
6, and an address generator 12-7 are provided. Each element of table 12-5 corresponds to each processor element, and stores a flag indicating whether the corresponding processor element is waiting for execution or not, and a restart address. The address generator 12-7 specifies the elements of each table as described above,
It is sufficient to generate an address so that the flag and restart address are updated according to the execution result.

[Brief explanation of drawings]

FIG. 1 is a flowchart for explaining a debug processing control method according to an embodiment of the present invention, FIG. 2 is a configuration diagram of a parallel computer system to which the present invention is applied, and FIG. 3 shows a user program for a host computer. , FIG. 4 is a configuration diagram of an execution processor queue, and FIG. 5 shows subprograms loaded into each processor element. Figures 6A and 6B are diagrams showing the state of the execution processor queue when the user program in Figure 3 is executed, and Figures 7A and 7B are diagrams showing the execution order and main status when the user program in Figure 3 is executed. FIG. 8 is a diagram showing storage access, and is a diagram for explaining how the main program of the user program is compiled and linked. FIG. 9 is a diagram showing the configuration of an embodiment in which a table is used instead of a queue.

Claims (1)

[Scope of Claims] 1. A program execution method for sequentially executing a plurality of programs of the system in a parallel computer system, which comprises the following steps. (a) registering the identifiers of a plurality of processors in a predetermined order in a pending queue;
(c) As a result of executing any program on any processor, when that program reaches the execution completion state, the identifier of that processor is waited for as described above. When the program is removed from the queue and becomes in a data waiting state for data to be given from another processor while the program is running, execution of the program is stopped and the processor's identifier is set as the last element in the pending queue. and (d) repeating steps (b) and (c). 2. The program execution method according to item 1, wherein step (d) comprises repeating steps (b) and (c) until the identifier in the execution queue does not change. 3. The program execution method according to item 2, further comprising the step of outputting the identifier left in the execution queue as the identifier of the processor that executed the program with the bug. 4. The program execution method according to claim 1, wherein the order is arbitrarily determined. 5. The program execution method according to claim 4, wherein the order is determined according to the number of data transmission processes included in each program. 6. The program execution method according to claim 4, wherein the order is determined by generating random numbers based on the execution time of each program. 7. A program execution method according to claim 1, wherein the processors sequentially selected from the execution queue execute the corresponding programs until the processors are in either the data wait state or the processing end state. 8. A program execution method according to claim 1, wherein the executing step includes the following steps. When the executing processor enters the data waiting state, registering the identifier and restart address of the processor in the execution waiting queue as the last element, and corresponding to each processor before and after execution of the corresponding program by the processor. It is determined that there is no executable processor when there is no change in the contents of each element of the execution queue. 9. In claim 1, the step of determining the program containing the bug includes determining a statement that causes the bug in the program. 10. A debugging method for a parallel computer system, which consists of the following steps. (a) registering the identifiers of a plurality of processors in a predetermined first order in an execution queue;
(c) As a result of executing any program on any processor, when that program reaches the execution completion state, the identifier of that processor is executed as described above. When the program is removed from the waiting queue and becomes in a data waiting state for data to be given from another processor while the program is running, execution of the program is stopped and the identifier of that processor is placed at the end of the waiting queue. (d) repeat steps (b) and (c). The step (d) includes the steps (b) and () until the identifier in the pending queue no longer changes.
Repeat c) to send and receive data, synchronization control data,
outputting the values of arrays and variables as trace data; (e) registering the identifiers of the plurality of processors in the execution queue in a predetermined second order after the execution step is completed; , (e) 1 according to the order of the identifiers registered in the queue.
(g) As a result of executing any program on any processor, when that program reaches the execution completion state, the identifier of that processor is executed as described above. When the program is removed from the waiting queue and becomes in a data waiting state for data to be given from another processor while the program is running, execution of the program is stopped and the processor's identifier is placed at the end of the waiting queue. (h) repeat steps (e) and (f); The step (h) repeats the steps (e) and () until the identifier in the pending queue no longer changes.
Repeat f) to send and receive data, synchronization control data,
11. The program execution method according to claim 10, wherein the first and second orders are arbitrarily determined, comprising: outputting values of arrays and variables as trace data. 12. The program execution method according to claim 11, wherein the first and second orders are determined according to the number of data transmission processes included in each program. 13. A program execution method according to claim 11, wherein the first and second orders are determined by generating random numbers based on execution times of each program. 14. The program execution method according to claim 10, wherein the processor executes the corresponding program until the processor enters either the data waiting state or the processing end state. 15. A program execution method according to claim 10, wherein the executing step includes the following steps. When the program enters the data waiting state, registering the identifier and restart address of the processor in the execution queue as the last element; To determine that there is no executable processor when there is no change in the contents of each element in the pending queue. 16. In claim 9, the step of determining the program containing the bug includes the following steps. Determine the statement that causes the bug. 17. A method for controlling debug processing in a parallel computer system, including the following steps. setting a flag and an execution start address for each element of the execution waiting table, each element of the execution waiting table corresponding to one of a plurality of processors, and setting the flag of the corresponding processor and the execution start address; is stored, and the flag indicates whether the corresponding processor is in the execution waiting state. While updating the execution start address of the processor in the data waiting state, the flag corresponding to the executable processor is stored in the execution waiting table. referencing the elements of the execution waiting table in a predetermined order until the flag is no longer set, causing the processors to execute the corresponding program one by one from the execution start address; determining a program having a bug from the elements of the execution waiting table; 18. The program execution method according to claim 17, wherein the order is arbitrarily determined. 19. The program execution method according to claim 18, wherein the program execution method is determined according to the number of data transmission processes included in each program. 20. The program execution method according to claim 18, wherein a random number is generated based on the execution time of each program to determine the order. 21. In claim 17, the executing step includes the following steps. A program execution method in which a processor executing the program executes the program until it enters either a data waiting state or a processing end state. 22. A program execution method according to claim 17, wherein the executing step includes the following steps. To determine that there is no executable processor when there is no change in the contents of table elements corresponding to each processor before and after execution of a corresponding program by a certain processor. 23. In claim 17, the step of executing comprises the following steps. Setting flags and execution start addresses for each element of the execution waiting table, and updating the execution start addresses of the processors in the data waiting state, while setting flags corresponding to executable processors in the execution waiting table. referring to the elements of the execution waiting table according to different predetermined orders until no more programs are executed, causing the processors to execute the corresponding programs one by one from the execution start address; and in the predetermined order. Outputting first and second trace data during execution of the step of executing the program and the step of executing the program in a predetermined different order, respectively; and detecting bugs from the first and second trace data. Determine which programs you have. 24. In claim 17, the step of determining the program containing the bug includes the step of determining a statement that causes the bug. 23 A method for improving the workability of debug processing includes the following steps: providing first and second libraries containing a normal processing control routine and a debug processing control routine, respectively; and both routines having the same routine name. However, the first and second libraries are the same except for the normal processing control routine and the debug processing control routine, and the main program is compiled and the first library is added to the main program compiled during normal processing. linking the second library during debugging; and executing the linked main program.