JPH06332689A - Program displaying method and program edition accepting method - Google Patents

Abstract

PURPOSE:To enable a program executing plural processings in parallel to be visually and hierarchically generated by using a graphic. CONSTITUTION:The designations of each processing 421, 422 and 424 composing programs, data accessed by each processing and the synchronization 44 between processings are accepted by the designation of each corresponded graphic, the start of each processing, a relation to be started, a writing and, reading data and synchronizing relation between processings are accepted by the designated of the arrow connecting corresponded graphic. The contents of a processing 423 is hierarchically accepted by the combinations of graphics 4231,...,4234 and 4240 showing further fine processings. The definition of the contents of the processing of the lowest rank hierarchy is accepted by a text form. When the designation of the arrow is accepted, the instruction designating the processing shown by this arrow is inserted in the text defining the processing of the corresponded graphic.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a technique for developing a program capable of executing a plurality of processes in parallel on a computer having a plurality of processors.

[0002]

2. Description of the Related Art A conventional text type program is suitable for expressing a serial program, but not suitable for expressing a program in which processing progresses in parallel. Therefore, recently, a tool for visually creating a program by using a figure is drawing attention. Since the figure has a two-dimensional spread, not only the order of the procedures but also the procedures executed in parallel can be described at the same time.

A technique has also been developed in which execution traces of parallel programs are taken and the results are displayed visually. It is generally difficult to get the performance of a parallel program. Therefore, the performance is tuned by repeating the analysis of the problem on the performance and the change of the program for solving the problem. Analyzing the execution trace is effective in extracting problems.

These techniques are described in, for example, Tutorial Tex.
t: Software Tools for Visualization of Parallel an
d Distributed Programs and Systems, COMPSAC'91, IEEE
It is described in Computer Society and others.

Regarding debugging of a conventional parallel program described in text, etc., Japanese Patent Laid-Open No. 2304/1990
32, JP-A-3-160532, JP-A-6
The technique described in Japanese Laid-Open Patent Publication No. 3-317840 is known.

[0006]

However, the above-mentioned "Softwa
re Tools for Visualization of Parallel and Distrib
The technology described in "uted Programs and Systems" does not consider hierarchical programming with graphics, and is not suitable for describing complex programs. In addition, programming with graphics is not always
In some cases, it is not possible to describe in detail enough about the processing under severe design conditions. Also, in a program that executes processes in parallel, handling of data commonly used between processes becomes a problem, but no special consideration is given to this.

Therefore, an object of the present invention is to make it possible to edit a program using figures in a hierarchical manner. Further, it is an object of the present invention to satisfactorily visually represent data commonly used among processes executed in parallel and an operation for the data.

A further object of the present invention is to guarantee the determinism of the value of the data commonly used between the processes executed in parallel.

[0009]

In order to achieve the above object, the present invention provides, for example, in a computer equipped with a display device, a program for accepting editing of a structure of a program hierarchically composed of a plurality of processing units. An editing method, a plurality of graphics representing a plurality of processing units,
A plurality of the processes constituting the program by hierarchically editing a graphic representing a relationship between the plurality of processing units by connecting a plurality of graphics corresponding to a plurality of processing units to be related to each other. Provided is a program edit acceptance method characterized by accepting the editing of a hierarchical structure of units.

[0010]

According to one embodiment of the present invention, the processing unit is represented by a square graphic and the shared data is represented by a graphic such as an ellipse. A parallel program is created by arranging these figures on the screen and connecting them with arrows. The contents of each processing unit can be described in text, but can also be defined by figures and arrows. In this way, the processing content can be described hierarchically.

Furthermore, when defining access to shared data from a processing unit, the tool examines the relationship between the access and the access from other processing units, and this access makes the value of shared data indeterminate. Determine if it does. If it is determined to be indeterminate, the color of the graphic representing the process and access that cause it is changed to warn the user.

[0012]

DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of a computer according to the present invention will be described below.

First, FIG. 1 shows the configuration of a computer according to this embodiment.

As shown in the figure, the computer according to this embodiment is a parallel computer in which a plurality of processors 141-143 operate in cooperation. In the figure, 13 represents the entire parallel computer system, and 11 represents the cubicle of the computer. The processors 141 to 143 are connected to the bus 63. All processors access the memory 18 through this bus. Disk 15 is also bus 63
Is connected to the processor, the processor can write data in the memory to the disk 15, and
The above data can be read out to the memory 18. Reference numeral 16 denotes a terminal controller, to which a display 17, a keyboard 65, and a mouse 64 are connected. Each of the processors 141 to 143 accesses the terminal controller through the bus 63.

In the figure, the memory 18 is inside the memory 1.
8 shows the stored contents. 19 is an operating system (OS), 20 is a library function, 211
˜213 are processes. The memory 18 also has an area 23 for storing data shared between processes, an area 24 for storing programs shared by the processes, and an area 22 for storing trace data. Here, the parallel computer according to the present embodiment uses a process as a unit of processing execution. The processors 141 to 143 load process information and execute each program based on the loaded information.

FIG. 2 shows details of the process 211.

In the figure, 2611 to 2612 are areas for saving the registers of the processor. Processors 141 to 1
43 performs processing by switching processes in a time division manner. When the processor suspends the processing of one process and transfers the execution to another process, the current register state is set to 2
Save to area 61. When resuming the processing of the suspended process, the contents of this area are read and set in the processor registers. There are a plurality of register save areas so that a plurality of processors can execute a plurality of programs of one process in parallel. 321 to 323 are programs unique to the process, and 271 is an area for storing data unique to the process. Communication between processes is performed by sending a message to the message queue 281 of the other process.

Next, the execution environment of the program in the computer according to this embodiment will be described.

FIG. 3 shows an execution environment of a program realized on this computer.

In the figure, 13 is a parallel computer, which comprises a plurality of processors 14, a display 17, a keyboard 65, and a mouse 64 as described above.

The program development environment 74, compiler 29, and tracer 33 shown in the figure are functions implemented as processes executed on a parallel computer.

The source program 35 is a program created by the program development environment 74. The source program 35 is read by the compiler 29 (91
2), after being compiled, object program 3
It is output as 6 (913). The processor 14 executes the object program 36 to process the calculation data (917, 918). The debugger, which is a program in the program development environment 74, is a program for searching for errors in the source program and controls the processor executing the object program 36 (91
5) The calculation data 37 is read (909) and written (908). The tracer 33 reads the history of execution of the object program 36 by the processor 14 (916) and records it as trace data 34 (91).
1). The parallelism evaluation program, which is a program in the program development environment 74, reads out the trace data (910) and calculates the parallelism of the program, the frequency of communication, and the like.

Next, FIG. 4 shows the details of the program development environment 74 and the source program 35.

As shown, the program development environment 74
Is a program as a program unique to its own process, as described above, the editor 30, the debugger 31,
It has a parallelism evaluation program 32. The editor program 30 creates and changes the source program 35. The debugger 31 and the parallel evaluation program 32 debug and evaluate the source program 35. Also, the program development environment 74 is the source program 35.
Contents are displayed graphically on the display 17, and instructions from the mouse 61 or the keyboard 65 are input to the editor 30,
It has a program GUI 56 that is transmitted to the debugger 31 and the parallelism evaluation program 32.

In the present embodiment, a program is created / edited by describing a combination of processes performed by the program with a combination of figures representing the processes. Therefore, the source program 35 is composed of a table and the like that define graphics. In the figure, 971 is a graphic definition table that defines the type and positional relationship of the graphic, 972 is a graphic internal definition table that defines the details of the process when the graphic is further expressed, and 973 is the text of the detailed process. The text definition tables 974 and 975 that define the contents of the function
A join definition table and a barrier definition table that define n and a barrier, and 973 is a table that defines data used in each process. By combining these tables, it is possible to express the relationship between figures and texts, figures, and texts. That is, the combination of these tables can define the combination of the processes constituting the program, so that the program can be expressed by the combination of these tables.

The relationship between the program description method and each table of the source program 35 in this embodiment will be described below.

FIG. 4 is an example of a parallel program described according to this embodiment.

The program begins at the 40 start symbol in the figure. Each of the figures 421 to 424 represents one process. The arrow pointing to the upper side of the process shows the flow of the process. That is, first 541
The arrow indicates that the process 1 of 421 is activated, and the process 2 (422) and the process 3 (423) are activated in the process 1 (491, 492). That is, the remaining part of the process 1, the process 2 and the process 3 are executed in parallel.

Reference numeral 45 represents data commonly accessed during processing. Arrows 532 and 531 indicate process 2
And Process 3 indicate that the data is written. Reference numeral 44 represents the execution of the function join. The function join functions to combine processes that are divided and operate in parallel as will be described later. Process of origin of arrows (521 to 523) pointing to the upper side of 44 (421
(4) to (423) are completed, the process 4 (424) in which the arrow 542 extending from the lower side is directed is activated. The end symbol 41 indicates that the program ends when the execution comes to the end symbol 41.

Further, the figure 423 representing the process 3 has a double square. This indicates that more detailed processing content is defined by the graphic for this processing. As shown in FIG. 6, detailed processing contents can be hierarchically described by a combination of figures. That is, in FIG. 6, 4231-4234 are processes, 4235-4.
Reference numeral 239 represents a processing flow, and 4240 represents a join, and these notations are the same as those described in FIG. Further, in FIG. 6, the square of 4232 representing the process 3-2 is doubled, which means that a detailed description of this process can be displayed.

On the other hand, in FIG. 5 and FIG. 6, the contents of the process represented by a single square are described in text format as shown in FIG. FIG. 7 illustrates the process 422 of FIG. 5 described by the text 4222.

The description of such a source program is made on the display of the display 17, as will be described later.

Now, each table of the source program 35 is provided corresponding to the description method of such a program.

FIG. 8 shows the graphic definition table 971.

In this table, the source program 35
The contents of all graphics included in are defined.

In FIG. 8, reference numerals 9701 to 9711 respectively denote the codes, which correspond to the graphics constituting the program of FIG. In each record, the member 9601 is the record number of the table, the member 9601.
02 is the name of the figure, members 9603 and 9604 are coordinates for displaying the figure, type member 9605 is the type of the figure, member 9606 is the location where the processing content corresponding to the figure is defined, and member 9608 is the figure Indicates whether to display the contents of the detailed definition when there is a more detailed definition.

For example, the record 9701 is the processing 1 of FIG.
Has been defined. The name is process 1, the coordinates to be displayed are (300, 50), the type is text, and the detailed definition of the process corresponding to this figure is described in text. Member 9606
The position of the text definition table 973 designated by, that is, the first record. Currently, the detailed definition is not open, that is, it is not displayed.

Reference numeral 9703 denotes process 3 (423) in FIG.
Has been defined. The name is process 3, and the displayed coordinates are (100, 75). The type of figure is a figure,
This means that the detailed definition of the process corresponding to this figure is described in the figure,
This detailed definition is written in the record of the graphic internal definition table 972 designated by the member 9606, that is, the second record. Further, as shown in FIG. 6, in the process 3, the detailed definition is currently open.

FIG. 9 shows the figure internal definition table 972, and describes the information of the figure when the detailed definition of the process corresponding to the figure is further performed with the figure.

In the figure, 9610 is the record number of the table, which is the definition number member 96 of the graphic definition table 971.
Specified by 06. In the record 9713, the detailed definition of the process 3 in FIG. 6 is written as shown in the definition number member 9703 in FIG.

Here, as will be described later, each arrow is managed by the terminal list (FIG. 11), and the affiliation relationship of graphics is managed by the graphic list (FIG. 10).

In the figure internal definition table 972, arrows between other figures and figures included in the detailed definition of the corresponding figure are the terminal list (FIG. 11) and the figure list (FIG. 10).
It is defined by specifying the record of.

That is, in FIG. 9, the member 9611
Indicates the head position of the record of the graphic included in this detailed definition in the graphic list. The member 9612 indicates the head position of the record in the terminal list of the arrow that has entered this process from another graphic, and the member 9613 indicates the arrow in the terminal list that extends from this graphic to another graphic. The head position of the record is shown.

FIG. 10 shows a graphic list.

A member 9620 is a record number, and a next member 9622 is a pointer for connecting records. 9621 is the figure number registered in this record, which is the number 9 in the figure definition table record.
Matches 601.

Here, the figure (423 of the processing 3-1 in FIG.
1) is the seventh record 97 of the figure definition table 971.
26, the graphic of process 3-2 (4322) is 9728 in the 8th record, and the graphic of process 3-3 (4233) is in the 9th record 9729 and the graphic 43 corresponding to join
20 is registered in the 10th record 9729, and the graphic (4234) of the process 3-4 is registered in the 11th record 97330.

For example, as shown at 9713 in FIG. 9, 9726 is the head record of the graphic included in the detailed definition of the process 3 (423) in FIG. Record 9726 is for the graphic of process 3-1 registered in the 7th record, and the pointer next to record 9726 is 8 in the graphic list. Th record
Code 9727 is also included in the process 3. Similarly, up to the record 9730 is continued. Record
The next member of code 9730 is 0, which means process 3
Indicates the end of the list for.

FIG. 11 defines the terminal list.

From this list, figures can be associated with each other. 9630 is a record number. The member 9631 is the number of the figure which is the source of the arrow, and the member 9632 is the number of the figure which is the destination. These match the number 9601 of the record of the figure definition table. A member 9633 indicates where the terminals to which the arrow connects are located on the upper, lower, left, and right sides of the figure. Next Member 963
Reference numeral 4 is a pointer for connecting the records, and functions similarly to the pointer 9622 of the graphic list (FIG. 10).

For example, in 9713 of FIG. 9, it is described that the information of the exit of the arrow from the process 3 of FIG. 6 is registered in the record starting from the fourth record 9734 of the terminal list. . There are two exits in the process 3 of FIG. 1
One goes out from process 3-2 (4232) and is in data 1, the other goes out from process 3-4 and join
It's in. Each of these exits has a record 9 connected by a pointer 9634 in FIG.
734 and 9735.

FIG. 12 shows a definition table.

It is noted in 9701 in FIG. 8 that the detailed definition of processing 1 is shown in the record 1 of the text definition table. 9741 is this definition, and indicates that the text content of the process 1 is stored in the file named process 1. Further, the entry information indicated by the arrow of the process 1 is changed from the sixth record in the terminal list (FIG. 11) to
It indicates that the exit information exists from the 7th record.

13 and 14 respectively show the above-mentioned jo.
This is a table that defines in and barrier. These records correspond to the type 960 of the graphic definition table (FIG. 8).
5 and the definition number 9606. These tests
Bull manages both the entrance and exit terminals.

FIG. 15 is a table defining data. This record is designated by the type 9605 and definition number 9606 of the graphic definition table (FIG. 8). This table defines the type of data and the initial value of the lock that performs exclusive control on the data.

Details of the operation of the program development environment 74 will be described below.

First, the operation of the GUI 56 will be described. The GUI 56 plays a role of controlling the entire program development environment 74 such as transmitting instructions from the mouse 64 and the keyboard 65 to the editor 30, the debugger 31, and the parallelism evaluation program 32.

In FIG. 16, the GUI 56 displays the display 1
7 shows a screen to be displayed. As shown, GU
As described above, the I56 graphically displays the content of the source program 35 on the display 17. When the mouse cursor is moved to a place where no figure is displayed and the mouse is clicked, the mode menu 92 is newly displayed. The mode menu has five buttons. When the edit button 921 is clicked, the processing moves to the editor 30 and shifts to the program editing mode. When the compile button 922 is clicked, the compiler 29 is activated and the program is compiled. When you click the 923 run button,
The compiled object program is executed. When the debug button 924 is clicked, the processing moves to the debugger 31 and the mode shifts to the debug mode. 92
When the trace button 5 is clicked, the program is executed, the trace result is recorded, the tracer 33 is activated, and the analysis result of the trace result is displayed.

The GUI 56 performs such processing using the event vector table provided as the process specific data 271 and the window table.

FIG. 17 shows an event vector table.

In this table, what kind of operation should be performed when a certain event occurs in a certain window (including buttons, figures, arrows, etc.) is registered. 9686 is a number for designating a table element,
9687 is a window number, which is an index of the window table. 9688 is the event type. The types of events include a click when a mouse button is pressed, a mouse cursor entering and leaving a window, and keyboard input.

9689 is the address of the function to be executed at birth. Each record from 9784 to 9788 is
The event definition for each button of the mode menu (92). Taking 9748 as an example, the definition of the window is written first in the window table, and it indicates that the function called edit is called when the mouse button is pressed while the mouse cursor is inside the window. The function edit launches the editor.
Events registered in this table can be registered for windows that are not displayed on the screen.
The registration in this table is also performed in the initial setting part of the GUI program, but when a graphic or an arrow representing the process is newly created at the editing stage, the event process for the process is dynamically performed. be registered.

FIG. 18 shows a window table.

Information on windows (including buttons, figures, arrows, etc.) is registered in this table. Information about windows not displayed on the screen is also registered here. 9690 is a number for designating a table element, 9691 is a window name, 9
692 and 9697 are the X and Y coordinates for displaying the window, 9693 and 9694 are the vertical and horizontal sizes of the window, 9695 is the window type, and 9695 is the window type.
96 indicates whether the window is currently displayed. Reference numerals 9790 to 9794 represent information on each button of the mode menu.

FIG. 19 shows a processing procedure of processing performed by the GUI 56.

In the figure, 2510 to 2514 are initial settings, and in 2510, scroll buttons (471 to 474) and scroll bars (481 to 4) on the screen of FIG.
The process for the event 82) is registered in the event vector table of FIG. 17, and the coordinates and the like are registered in the window table of FIG. Also, the window is actually displayed. Similarly, in 2511, the information of each button (921 to 925) of the mode menu (92) of FIG. 16 is registered in the event vector table and the window table, and the window is displayed. 2512, 2513,
Also for 2514, information on each button of the debug menu and each button of the parts menu, which will be described later, is registered. However, 2512 to 2514 are not displayed.

At 2515, it waits for an event to occur. When it occurs, at 2516, the event that occurred is searched in the event vector table of FIG.
At 7, the function corresponding to the event is called.

Further, the GUI 56 displays the source program on the display 17 in response to a request from the editor 30 or the like.

FIG. 20 shows a processing procedure executed by the GUI 56 to display the source program.

As shown, first, step 2412.
Then, the origin of the coordinate system for displaying the figure is set to the origin of the screen. In step 2413, the top record of the figure internal definition table of FIG.
Substitute in 1. In this case, the 9712 record is substituted. In 2714, the record indicated by the entry list member 9612 of n1 is read from the terminal list of FIG.
Substitute for t1. In the case of the example, the value of the entry list member of 9712 is 1, so the record 9731 is read.

In step 2415, terminals are displayed according to the position member of t1. Since the value of the position member 9633 of the record 9731 is above, a lower triangle indicating the start of the program is displayed at the top of the screen. Then, step 2416.
Then, whether t1 is the last record or not is determined by the next member 963.
Judgment is made by examining the value of 4. If there is a next element, the process proceeds to step 2417, the next element is read at t1, and similar processing is repeated, but the value of the next member of 9731 is 0, and it can be seen that there is no next element. If not, the process proceeds to step 2418, and the process similar to the entry list is performed for the exit list member of n1 (steps 2418 to 2421).

In the case of the example, 9732 is used as the outlet terminal.
Therefore, an upper triangle indicating the end of the program is displayed at the bottom of the screen. When this is finished, in step 2422, n1
With the argument as an argument, the program display recursive process is called to draw another graphic forming the screen.

FIG. 21 shows a processing procedure of program display recursive processing.

In this processing, first, the record of the graphic internal definition received as an argument in step 2432 is set to n2. In the example used in FIG. 20, since the record 9712 is passed as an argument, this value is assigned to n2.
In step 2433, the record pointed to by the value of the graphic list 9611 of n2 is read from the graphic list of FIG. 10 and set as f1. Since the value of the graphic list member of the record 9712 is 1, the graphic list record 9720 is substituted for f1. In step 2434, the record pointed to by the figure number member of f1 is read from the figure definition table of FIG. 8 and substituted into d1. The value of the figure number member of 9720 is 1, so
Record 9701 of the figure definition table is substituted for d1. In step 2435, the type member of d1 is checked. Depending on that value, in steps 2436 to 2440,
The figure corresponding to each is displayed. Here, since the value of the type member of the record 9701 is text,
A graphic indicating that the processing content is defined by text is displayed.

Next, in step 2441, it is checked whether f1 is the end of the concatenation of the graphic lists. If it is the last, the process returns to the process that called this process, and if not, the next element of the list is substituted for f1 in step 2442 and the same process is repeated. Since the value of the next member of the record 9720 is 2, the record 9721 is assigned to f1. Since the figure number member of the record 9721 points to 9702 in FIG. 8, the figure of data 1 in FIG. 6 is displayed. Hereinafter, similarly, the processing is repeated until 9725 when the list connection in FIG. 10 is interrupted.

As described above, in this embodiment, when the content of the processing unit represented by the graphic is further represented by the graphic, the processing represented by the graphic is requested in response to the request. The contents of the unit are displayed in more detail as a graphic. Such display is realized by recursively calling the program display recursive process. That is, the program display recursive process calls the graphic display process shown in FIG. 22. By further calling the program display recursive process from the graphic display process, the contents of the processing unit represented by the graphic are displayed. , Display in more detail as a graphic.

FIG. 22 shows a program display recursive process (see FIG.
In the graphic display processing called in step 2438 of 1), if the processing content is further expressed by a graphic,
Display it. Here, the graphic 423 of the process 3 of FIG.
Will be described as an example.

At step 2451, the value of the open member 9608 of the graphic definition record (d1) passed from the program display recursive process is checked. This member indicates whether the processing contents are currently displayed in detail (open) or not displayed in detail (closed). If open, step 245
In step 2, a large frame is displayed as a window for graphically displaying the details of processing. If it is in the closed state, in step 2453, a double-framed quadrangle indicating that the details are defined by the graphic is displayed.

In the case of the process 3 (423) of this example, since the graphic definition record is 9703 in FIG. 8, it can be seen that it is in the open state. Therefore, a large frame is displayed. In step 2454, the record pointed to by the definition number member 9606 of d1 is read from the graphic internal definition table (FIG. 9) and assigned to n3. Record 97
Since the value of the definition number member of 03 is 2, the record 9713 of the figure internal definition table (FIG. 9) is substituted for n3. At step 2455, the record pointed to by the exit list member of n3 is read from the terminal list of FIG.
Is assigned to. Since the value of the exit list member of the record 9713 is 3, the terminal list record 9733 is t3.
Is assigned to. In step 2456, the exit arrow display process is called with t3 as an argument. As a result, the arrow pointing out from the displayed figure is displayed. Step two
In step 457, as in step 2451, it is checked whether the figure is in the open state. If it is in the closed state, the process directly returns to the process that called this process. If it is in the open state, the origin for displaying the graphic is changed to the upper left of the frame displayed in step 2452 in step 2458. In step 2459, the record pointed to by the entry list member of n3 is read from the terminal list of FIG. In step 2460, the entrance arrow display process is called with this t4 as an argument. As a result, of the arrows coming into the displayed figure, those that need to be displayed are displayed. In step 2461, the program display recursive process is recursively called with n3 as an argument. As a result, the detailed definition of the processing to be displayed is displayed as a graphic. In step 2462, the origin changed in step 2458 is restored.

FIG. 23 shows step 24 of the graphic display process.
The processing procedure of the exit arrow display processing called by 56 is shown.

As shown in the figure, in this processing, first, at step 2471, the record at the head of the terminal list passed as an argument is set to t. Then, in step 2472, the position of the position member of t on the display frame of the display figure is set to (x1, y
1). For example, if t is 9734 in FIG. 44, since the position member is left, the coordinates of the terminal on the left side of the display frame 423 in FIG. 6 are substituted. In step 2473, it is checked whether the destination graphic and the displayed graphic are in the same list in the graphic list of FIG. If yes, step 2
At 475, the terminal coordinates of the previous figure are substituted into (x2, y2). If not, in step 2474, from the exit terminal list of the graphic outside the displayed graphic,
Search for an original figure that matches the displayed figure. The one outer graphic has a relationship like the process 3 of 423 with respect to the process 3-2 of 4232 in FIG. Next, the coordinates of the terminal found in step 2476 are set to (x2, y
Substitute in 2). At step 2477, (x1, y1)
An arrow is displayed from to (x2, y2). Step 247
At 8, check if t is the last element in the terminal list, and if so, exit, otherwise step 24.
At 79, the next element is set to t and the same processing is performed again.

FIG. 24 shows step 246 of the graphic display processing.
9 shows a processing procedure of an entrance arrow display processing called 0.

In this processing, in step 2481, the record at the beginning of the terminal list passed as an argument is set to t. At step 2482, it is checked whether the original graphic and the display graphic are in the same list in the graphic list of FIG. If it is included, this arrow is also displayed by the exit arrow display function, so the processing is skipped. If not, step 248
In step 3, a search is made from the entry terminal list of the figure outside of the figure being displayed, that the preceding figure matches the displayed figure. The coordinates of the terminal searched in step 2484 are (x1,
Substitute into y1). In step 2485, the position of the position member of t on the display frame of the display figure is set to (x2, y2). In step 2486, from (x1, y1) to (x2,
Display an arrow to y2). In step 2487, it is checked whether t is the last element in the terminal list, and if so, the process ends, and in step 2479, the next element is set to t and the same processing is performed again.

Through the above processing, the GUI 56 displays the program according to the description method as shown in FIGS.

By the way, in the above processing, there is a case where graphics are overlapped and displayed on the screen. For example, in Figure 2.
5, the process 2 of 422 and the process 3 of 423 overlap. In such a case, the GUI 56 changes the overlapping manner of the figures when the overlapping figures are clicked by the mouse. FIG. 26 shows a procedure of processing for changing the overlapping of the figures.

As shown in the figure, at 910, it is determined whether the figure clicked by the mouse is located at the top of the overlap. If it is located at the top, the figure is moved to the bottom of the overlap. If not, the figure is moved to the top of the overlap.

The operation of the computer according to this embodiment will be described below along with the actual work of creating a program.

First, the editing of the program will be described.

FIG. 27 shows the flow of the operation of each part when the program is edited.

In the figure, 15 is a disk, 16 is a terminal controller, 17 is a display, 18 is a memory, 19 is an operating system, 85 is operating system data, 23 is a shared data area, 24 is a shared program area, and 63 is a shared program area. Bus, 64 mouse, 65 keyboard, 141-142 processor, 1411-14
21 is a register, 214 to 216 are processes, 241 to
Reference numerals 243, 328 to 332, and 844 to 846 are programs.

Reference numeral 213 denotes a debugger 31 realized as a process, and 214 denotes a GUI 5 realized as a process.
6, 215 are editors 30 realized as processes,
216 is a compiler 29 implemented as a process. Processors 141, 142. ． Can execute the process of each process by loading the registers 264 and 265 saved from the process in the memory (645 to 646).

Now, first, the procedure by which the program of the editor process 215 displays the contents of the source program 35 on the display 17 will be described. The program 331 of the editor reads the contents of the source program (89
0), the display request is sent to the message queue of the GUI process 214 (891). GUI program 328
Retrieves the message from the message queue (90
4) The system call is issued according to the contents (893). The operating system displays the contents of the program on the display 17.

Next, the user uses the mouse 64 and the keyboard 6
The operation of rewriting the program by operating 5 will be described.
The GUI program 329 issues a read system call (903) and shifts to the standby state. When an operation is given to the operating system program 846 from the mouse or keyboard, the GUI program 3
29 returns 89 from the system call 903
6 message to editor process 215. The editor program 330 retrieves this message and modifies the source program 35 as instructed 898. The source program 35 is changed by changing the contents of the table and list shown in FIGS.

When the program is created, the user activates the compiler process 216. The compiler program 332 reads the source program 35 (899) and compiles it to generate an object program 36 (900). The object program is finally stored in the disk 15 (901). When executing the program, the object program stored in the disk is loaded into the shared program area 24 and executed.

Details of the program editing operation will be described below.

First, the library functions that can be used for the program to be edited in this embodiment will be described. The library function is a function that is registered in the memory as a library in advance and can be used from any program. FIG. 28 shows a list of library functions.

In the figure, the function mfork creates a process one less than the number specified by the argument. First time mfo
At the time when rk is executed, the number of processes specified by the arguments also exists in the processes that executed mfork. The generated process is the same process as the generated process, and the same program as the generated process starts to be executed from the same position. However, the function mfo
Since the return value of rk is a serial number and is different, it is possible to distinguish each process.

The function getqueue creates a queue in which threads that are ready to run enter. A thread is an execution unit of smaller processing than a process. Compared to the process, there is less overhead such as generation. In this embodiment, a process acts like a virtual processor and executes a thread. That is, when a thread is registered in the queue, the virtual processor takes out the thread from the queue and executes it.

The function thread creates a thread and registers it in the queue. As an argument of the function thread, the address of the function executed by the generated thread,
Describe the argument given to the function. Function msgget
Creates a queue for processes to transfer messages between processes. That is, the queue 281 in FIG. 2 is generated.

The function msgget returns the identifier of the created message queue. The function send sends the message given by the argument to the message queue of the identifier given by the argument. The function rcv takes out a message from the message queue of the identifier given by the argument. If the specified message queue is empty, wait until a message is sent.

The function put writes a value to shared data. The function get reads the value of shared data. Function p
ut and the function get automatically perform exclusive control when accessing shared data.

The function getbrr creates a barrier for barrier synchronization. The barrier provides mutual synchronization of any number of threads. When thread processing reaches the barrier,
Checks if the specified number of threads have already reached the barrier, waits until it has reached it, and if it has, passes it through. The function barrier is a function for performing barrier synchronization.

The function vp processes a virtual processor that executes a thread. It does not return from this function until all threads have finished processing.

The function getjoin creates a structure for join synchronization.

Also in the function join, an arbitrary number of threads perform mutual synchronization. The difference from the barrier synchronization described above is
The barrier is that all threads continue the next processing after synchronization, whereas the join synchronization is that only one thread advances to the next processing after synchronization and the other threads end.

The function join is a function for performing join synchronization.

In FIG. 29, the editor 30 displays the GUI5.
6 is an example of a screen displayed on the display 17 through 6. It is also possible to display a plurality of this screens on the display at the same time.

In FIG. 29, reference numeral 46 is a screen for displaying the program to be edited. Reference numeral 66 denotes a mouse cursor, which can be moved vertically and horizontally by moving the mouse 64 back and forth and left and right. Further, the mouse has a button, and when the mouse cursor is placed on a figure and this button is pressed, the figure is selected. This is called clicking. It is also possible to move the mouse cursor over the target graphic, press the button, and move the mouse cursor while the button is pressed. This is called a drug.

Reference numeral 68 denotes a cursor, and when the keyboard 65 is hit, a character is inserted at the position of this cursor. 47
1 to 474 and 481 and 482 are scroll buttons used when the program 5 is too large to be displayed on the screen 46. The positions of 481 and 482 are
It shows which part of the program 5 is displayed on the screen. If you drag and move these buttons, the displayed area will also change. For example, when 481 is moved to the right, the right side of program 5 is displayed.
Click the buttons 471-474 to select 481 or 4
The button 82 moves up, down, left and right for a certain distance. 55
Is a menu of parts for creating a program. All you have to do is drag the parts of this menu to the required position. 552 is a bar for joins, 55
3 is a bar for barrier synchronization, 554 is a square representing processing, and 553 is an ellipse representing shared data. Further, as described above, the figure 423 representing the process 3 has a double square. This indicates that more detailed processing content is defined by the graphic for this processing.

Now, as shown in FIG. 6, when one process in the program is to be displayed in more detail, in the edit screen of FIG. By clicking, detailed processing contents can be displayed. FIG. 6 shows the state, and the square 423 representing the process 3 is enlarged, and the detailed process is displayed therein. 4231 to 4234 are processing, 4235 to 42
Reference numeral 39 represents a processing flow, and 4240 represents a join.
The double square in 4232 indicates that a detailed description of this process can be displayed.

Further, as shown in FIG. 7, in order to display the processing content in the text 4222, the processing content is displayed in the text by clicking the square of the processing 2 displayed in the single square. Can be made. Also, the displayed contents can be edited. In FIG. 7, 422
4, the square of 422 in FIG. 4 is enlarged to become 4221, and the processing content is displayed in the text 4222 therein. In such a display state, the user can edit the content of the text 4222.

Next, FIG. 30 shows the initial state of the screen at the start of program creation. In the figure, 40 is a start figure,
Reference numerals 541 and 542 are arrows representing the flow of processing, 421 is a square representing processing, 41 is an end figure, 66 is a mouse cursor, and 55 is a parts menu. In the initial state, the program consists of one process 421, which has no content. You can give a name to the graphic of the process by moving the mouse cursor inside the box representing the process and then entering a character with the keyboard.

Next, FIG. 31 shows a method of arranging figures. If you want to place a new graphic representing the process,
Move the mouse cursor 6 to the graphic 554 showing the processing in the menu.
Drag it in 6 (671) and place it in your favorite location (422).

FIG. 32 shows a method of describing the start of processing by an arrow. Reference numeral 464 is an edit screen. When the process 422 is activated in the process 421, the process 421 is executed.
Move the mouse cursor 66 over the side 4251 next to
Drag to the top of the square that represents the desired process. Then, the arrow 491 is drawn.

FIG. 33 shows a method of drawing an arrow indicating the start of processing when the processing content is displayed in text. Reference numeral 465 is an edit screen. In this case as well, an arrow is drawn as in FIG. 32, but when the side of the process 421 is dragged, it is dragged just beside the place in the text where the process is to be activated. Then, a call of the library function thread for thread activation is automatically inserted in that portion (681), and the arrow 491 is also displayed. Conversely, from the keyboard, move to the position of the cursor 68
If you type a call to the read function, arrow 4
91 is displayed.

FIG. 34 shows a method of describing message communication between processes by arrows. When sending a message from the process 421 to the process 422, the mouse cursor is moved to the side of the process 421 and dragged to the side of the square representing the process of the destination. Then, the arrow 533 is drawn. In the illustrated case, the message 533 is sent from the process 421 to the process 422.

FIG. 35 is a detailed display of the message communication of FIG. 16 in text. Send to the sender
Call 682 has been inserted, and the receiving side has rcv
683 is inserted. The method of describing the message communication by the user is the same as the activation of the processing in FIGS. 32 and 33.

FIG. 36 shows a method of writing the shared data from the process by using arrows. The mouse cursor is moved to the horizontal side of the process 421 and dragged to the upper side of the square representing the data 1 of the writing destination.
Then, the arrow 533 is drawn. In this case, the process 42
Data is written from 1 to the shared data 45 (53
1).

FIG. 37 is a detailed text representation of the writing to the shared data of FIG. 336. Library function pu for writing to shared data in text
A call 684 of t has been inserted. The method for the user to write the shared data is the same as the activation of the processing in FIGS. 32 and 33.

FIG. 38 shows a method of describing the reading of shared data from the process by an arrow. The mouse cursor is moved to the upper side of the data 1 and dragged to the upper side of the square 421 representing the process 1. Then, the arrow 534 is drawn. The data of the shared data 45 is read from the process 421 (534).

FIG. 39 is a detailed display of the reading of the shared data of FIG. 20 in text. A call 685 of a library function get for reading shared data is inserted in the text. The method by which the user describes the reading from the shared data is the same as the activation of the processing in FIGS.

FIG. 40 shows a process of waiting for a job (joy).
n) is described.

In the illustrated example, the graphic 44 representing join is shown.
Is placed, and the process 441, which waits for this figure 44,
Processing 423 of drawing an arrow from 422 and executing after waiting
An arrow is drawn from the figure 44. The program thus drawn indicates that the processing 423 is started only after the processing of both 421 and 422 is completed. 5
35 to 537 are arrows indicating the flow of processing, and the symbol 44 indicates that both 535 and 536 come and then proceeds to 537.

FIG. 40 is a detailed display in text of the meeting of the processing partners of FIG. The waiting is realized by the library function join. Process 4
When both 21 and process 422 call the function join, process 3 is activated. The method by which the user describes waiting for processing is the same as the activation of processing in FIGS.

FIG. 41 shows a method of describing the barrier synchronization between the processes.

A graphic 69 representing a barrier is arranged, an arrow is drawn from the waiting process 421, 422 on this graphic 44, and the graphic 6 is written in the process 423, 424 executed after the waiting.
The arrow is drawn from 9. In the program thus drawn, the processing 423 and the processing 424 are started only after the processing of both 421 and 422 is completed. Reference numerals 538 to 544 are arrows representing the flow of processing, and the barrier of 69 indicates that the flow of both 538 and 539 comes and then proceeds to 543 and 544.

FIG. 42 is a detailed display of the barrier synchronization shown in FIG. 41 as text. In the text, call the function barrier that represents the waiting for processing (68
9, 692) has been inserted. When returning from the function barrier, the function thread of 691 and 693
Then, process 3 (423) and process 4 (424) are activated.
The method for the user to describe the barrier synchronization is shown in FIGS.
This is the same as the start of the process of

Now, the editing of the above program is
The GUI 56 sends a message according to the user's operation obtained through the operating system to the process 215 of the editor, and the editor takes out this message and outputs the message shown in FIGS. -It is done by changing the contents of the bull list. For example, in FIG.
The detailed display of the processing contents as shown in 7
This is accomplished by changing the value of the open member 9608 of the clicked graphic definition table (FIG. 8) and requesting the GUI 56 to display it. In addition, movements and additions of figures and arrows are achieved by adding records to each table and list, changing record contents, and requesting display on the GUI, according to the operation contents. . The contents of the file corresponding to the graphic defined in the text definition table (Fig. 12) can be used to insert a library function associated with the setting of the arrow and to add, delete, or change the text according to the user's description. Is achieved by updating.

If the program created in this way is as shown in FIG. 45, the shared data becomes indeterminate.

In FIG. 45, 421 to 427 are processes,
493 to 499 are processing flows, 45 is shared data, 54
5 and 546 are writing to shared data, and 441 is joi
Reference numerals n and 701 to 703 indicate the history of writing to the shared data.

That is, the process 4 (425) and the process 5 (424) started from the process 1 (421) are job 441.
In 701 and 70, the process of waiting for in and proceeding to process 6 (426), in which the shared data 45 is written
It is 3. On the other hand, as for the history of 702, writing 545 is performed in the shared data 45 in the processing 2 (422) started from the processing 1 (421). There is no synchronization between the former process and the latter process, and it is uncertain which of writing 546 and 545 is executed first. This is not preferable because the value of the shared data is different each time it is executed.

Therefore, at the stage of creating the program, it is preferable to confirm whether the value of the shared data becomes indefinite every time the access to the shared data is newly defined.

FIG. 45 shows an algorithm capable of confirming that the value of shared data is fixed.

In this embodiment, at the stage of creating a program, every time access to shared data is newly defined, processing according to this algorithm is executed to check whether the value of shared data becomes indeterminate. To do.

That is, first, the access to the newly defined shared data is set to N (step 711). Next, the other processes accessing the shared data are sequentially examined. In step 712, it is determined whether there is any unprocessed processing. If not, the process ends. If there is, one of the processes is set to R (step 713). B is the set of processes executed before process N
n (step 715). The processes are taken one by one from the set Bn, and it is checked whether the process can be reached to R. If the process is reachable, the process on the route is put into the set Br (step 716). The set of processes after the process N is An (step 717), and the set of processes after the process R is Ar (step 718). Step 719
In 721, it is checked whether the elements such as Ar and Bn and An and Br are synchronized with each other such as message, barrier, join and the like. If synchronization is not performed between the elements of either set, the value of the shared data becomes uncertain, and a warning is displayed (step 722). If the elements of either set are synchronized, the value of the shared data is fixed (steps 723 and 724). If the elements of both sets are synchronized, a warning is issued because there is a possibility of deadlock (step 725).

Now, actually applying the algorithm of FIG. 45 to the program of FIG. 44 gives the following.

First, process 2 for newly accessing is processed 2
(422). Since the process 6 (426) is the only process selected in step 713, R is this process.
In step 715, the set Bn of processes before N is obtained, but the process executed before process 2 which is N is process 1
Only (421). Therefore, Bn = {Process 1}. In step 716, the route from each element of Bn to R is searched. The element of Bn is only the process 1. Processing 1
The route from R to Process 6 is through Process 4,
There are two routes: a route to process 6 via in (441) and a route to process 6 via process 5 and join. Set of processes in route Br = {process 4, process 5}
Becomes In step 717, a set An of processes to be executed after the process 2, which is N, is obtained. This is An = {process 3, process 7}. Similarly, in step 718, A
r = {Process 7}. In step 719, messages from the elements of the set Ar to the elements of the set Bn, barriers,
Checking if there is a join. The element of Ar is only the processing 7, and the element of Bn is only the processing 1. Since there is no synchronization between the two, the determination in step 719 is N. In step 720, the set An and the set Br are similarly set.
Are investigating the relationship. The elements of An are processing 3 and processing 7, and the elements of Br are processing 4 and processing 5. There is no synchronization between them either. Therefore, the determination in step 720 is also N. Therefore, in step 722, it is determined that the value of the shared data is indeterminate, and a warning is issued.

In the present embodiment, the warning is issued by changing the process causing the indetermination, the flow of the process, and the display color of writing to the indeterminate shared data. For example, when the writing 545 to the shared data 45 of FIG. 44 is defined, the warning issued when it is detected that the shared data becomes indefinite causes the indefinite as shown in FIG. 46. Processing 421, 422, 4
24, 425, 426, and process flows 493 to 495,
500, 501 and writing to shared data 545, 5
This is performed by changing the display color of 46.

The editing of the program has been described above.
Next, the execution of the program thus created / edited will be described.

After editing, the above-mentioned mode menu (see FIG.
6) is displayed and the run button is clicked, the source program 35 is compiled by the compiler 29, and the object program 36 is generated and executed. The source program 35 is compiled by compiling the text of each file registered in the text definition table of FIG. This is because all the processes are finally defined by the text, and the relation between the processes, the data access, etc. are reflected in these texts when the arrow indicating this is arranged.

Now, FIG. 47 shows the processing contents of the process first generated when the program is executed. Reference numeral 58 represents the entire process. In step 581, as shown in FIG.
The shared data area 22 is secured and then initialized.
In step 582, a thread queue is created in the shared data area. In step 583, the thread to be executed first is put in the thread queue. In the case of the program shown in FIG. 5, the thread executing the process 1 is queued. In step 584, it is checked whether the user has specified the number of processors used for executing the program. If specified, the number of processors to be used, nproc, is set to the number of specified processes (step 586). If not specified, it will use as many processes as there are processors in the system (step 585). Step 587
The process is actually created in. Since the created processes start executing the same program as the process that created them from the same place, the subsequent processing also executes the created process. Steps 588-589
Then, a trace area is secured when tracing is performed. Each process also reserves its own location in the trace area. In step 590, the processing of the virtual processor is started. That is, the thread in the queue is taken out and executed.

On the other hand, the operation of mfork for generating a process is performed as shown in FIG.

In the figure, 18 is a memory, and a process 21
1, operating system 19, library 20,
There are a shared data area 23, a shared program area 24, and a trace data area 22. It is assumed that the process 211 executes mfork in the library 20 (60). Process creation must be done in privileged mode. Therefore, the library 20 requests the operating system 19 to perform process generation processing by a system call (61). Operating system is process 2
12, 213 are generated.

The relationship between the above virtual processor (vp) and the library function thread is as shown in FIG.

In the figure, 15 is a disk, 16 is a terminal controller, 17 is a display, 18 is a memory, 2
0 is a library, 23 is a shared data area, 24 is a shared program area, 63 is a bus, 64 is a mouse, 65 is a keyboard, 141 to 142 are processors, 1411 to 14
21 is a register, 211-212 are processes, 201-
Reference numerals 202, 241-243, 321, 324 are programs.

The processor uses the saved register 2
The processing of the process is executed by loading 61 to 262 from the processes 211 to 212 (641 to 642). The processor 142 is executing the process 211, but the program counter (PC) in its register 1421 points to the address of the library function 202 (652). This indicates that the processor 142 is executing the function vp. Here, another process 212
The processor 141 executing the function executes the function thread of the library (651), and put_queue
The thread is registered in the thread queue 231 by e (203) (661). However, the function threea
The execution of d may also be done by the virtual processor executing the thread. The address 2311 of the function executed by the thread and the argument 2312 of the function are registered in the thread queue 231. Library function vp
(202) fetches the address 2313 and the argument 2314 of the function by get_queue of 204, and calls the function 243 with 205 (671). In this function, the library function thread (201) is called again (673), and a thread may be generated.

The execution of the program has been described above.

Now, the trace operation will be described.

When the above-mentioned mode menu (FIG. 16) is displayed and the trace button 925 is clicked, the tracer 33 executes the program based on the trace data which is the history of the program execution. Reproduce and display.

First, the trace data will be described.
The trace data is created by the executed program itself.

For example, for each library function shown in FIG. 28, as shown in FIG. 50, step 73 for creating trace data during processing of each library function.
1, 734 are provided in advance.

In FIG. 50, in step 731, a trace process for recording the start of the library process is performed. In step 732, when the parallel program is debugged, a process for breaking at the library function portion and displaying that the library function is being executed is performed. At step 733, the library function performs the original processing. At step 734, a trace process for recording the end of the process of the library function is performed.

FIG. 51 describes the trace processing of steps 731 and 734 in FIG. 50 in more detail. In step 735, it is determined whether the trace is being executed, and if the trace is not being executed,
The process ends. In step 736, it is determined whether the trace buffer is full. The trace buffer is a buffer in which trace information is recorded.
Existing in the trace data area (24). If the trace buffer is full, then in step 737 the existing contents of the trace buffer are written to disk 15 (FIG. 1). In step 738, the trace data is written in the trace buffer.

FIG. 52 shows the structure of this trace data.

Trace data is stored in the trace buffer 571.
Written to ~ 573. The trace buffer is divided for each processor. 5711 in the trace data
Is the time, 5712 is the address where the library function was called, 5713 is the name of the called library function,
5714 is a state, and 5715 to 5716 are arguments passed to the library function.

Now, when the execution of the program is completed, the tracer 33 displays the result of analyzing the trace data as shown in FIG. 53 on the screen based on the created trace data. This screen shows how many times each part of the program has been executed. The displayed program is the same as that shown in FIG. 87 is a legend and each color is 87
1 indicates how many times the execution (872) corresponds.
The color of the process such as 421 indicates how many times the process is executed. The color of the swath 88 next to the text indicates how many times each portion of the text has been executed. The color of the write 532 to the shared data also indicates how many times the write was executed. Although this figure shows the number of executions, it is possible to display information such as how many processors were not idle when each part was executed with the same screen configuration.

The display by the tracer 33 is as follows.
This is performed using the address / graphic correspondence table.

FIG. 54 shows an address figure correspondence table.

This table is also created when the program is compiled. Each record in table 9780
.About.9783 are provided for each instruction that calls a library function. In each record, 9680 is a record number, 9681 is an address in the object program of the instruction, 9682 is a terminal definition number indicating which arrow in the display graphic corresponds to the library call at the address, 9683 is a text definition number indicating which figure of text the address is defined in, 9684
Indicates the number of lines defined in the text file, and 9685 indicates the number of times this address appears in the trace data. For example, the record 9780 holds information regarding the library call whose address in the object program is 1FFE23D4. This call corresponds to the arrow represented by the fourth record 9734 in the terminal list of FIG. 11, and indicates that it is on the 23rd line of the 8th text of the text definition table of FIG. 12.

By the way, the tracer 33 first executes the processing procedure shown in FIG. 55 to collect the trace data.

In this processing, since it is necessary to aggregate the trace data of all the processors, a variable p for storing the processor number is provided, and the number of the processor 0 is assigned to it in step 2490. Step 2491
Then, it is checked whether all the data of the processor p in the trace data of FIG. 52 has been read. After reading, go to step 2 to examine the next processor's data.
Fly to 495. If you have not read, step 24
At 92, one record is read from the trace data of p,
Substitute in t. In step 2493, a record having an address member that matches the value of the address member of t is searched for in the address figure correspondence table of FIG. Step 24
At 94, step 2 is performed to increment the value of the count member of that record and process the next trace data.
Fly to 491. In step 2495, it is checked whether or not the trace data of all the processors have been added up, and if it has ended, the function returns. If not finished, the number of the next processor is set to p and the same processing is repeated.

When such tabulation is completed, the trace
The server 33 performs a process of displaying on the screen as shown in FIG. 53 based on the trace data collected in the address / graphic correspondence table.

In this process, as shown in FIG. 57, first, in step 2500, one record is read from the address / graphic correspondence table and set as c. In step 2501, the color i is determined according to the value of the number of times member c. The color is determined according to the legend color band displayed at 87 in FIG. It is checked in step 2502 if the terminal definition number of c is 0. In the case of 0, there is no arrow corresponding to that address, so the processing of displaying the arrow is skipped.

At step 2503, the record pointed to by the terminal definition number member of c is read from the terminal list of FIG. 11 and set to t. In step 2504, the arrow represented by t is changed to the color of i. However, at this time, if the arrow is not displayed on the screen, it is not necessary to change the color.
At step 2505, it is checked whether the arrow t touches the upper side of the figure. When touching the upper side, in step 2506, the color of the touching figure is also i.
The color has been changed. However, also in this case, if the figure is not displayed, it is not necessary to change it. Step 25
In 07, the graphic pointed to by the text definition number member of c is
Checking whether it is open in the display. If so, in step 2508, an i-color band is displayed next to the line indicated by the line member c of the graphic displaying the text.

The trace operation has been described above.

By the way, as the trace, as the trace data, the processing units that form the program and the execution manner of the library function are stored in time series.
It is preferable that a trace for changing the display of each figure in the execution order can be executed by executing the processing shown in FIG.

In the processing of FIG. 57, first, step 870.
In step 871 and step 872, one trace data is taken out, and the processing indicated by the trace data and the color of the arrow are changed. In step 873, the button input is awaited.
Then, when the button is pressed, the changed color is returned to the original state and the next trace data is extracted and processed to sequentially display the execution state based on the trace data.

Next, the debug operation will be described.

After compiling the program, when the above-mentioned mode menu (FIG. 16) is displayed and the debug button is clicked, the mode is changed to the debug mode and the screen shown in FIG. 58 is displayed. This screen is displayed on the same screen as the edit screen of FIG.

The displayed program is the same as that shown in FIG. 7. 421 to 423 are processes, 45 is shared data, 491 is a process flow, and 532 is writing to shared data.

Now, on this screen, the debugger 31
Changes the display color of the graphic corresponding to the process currently being executed. In FIG. 58, the colors of the processes 422 and 423 are different, and it can be seen that the processes are executed in parallel. Further, when the details of the processing are displayed in text, a cursor such as 75 is displayed on the text line being executed. When the process being executed changes, the color of the arrow indicating the flow of the process changes. When writing to shared data or message communication is being performed, the color of the arrow representing them changes. In the figure, since the shared data 45 is being written, the color of 532 has changed.

Reference numeral 78 is a menu for debugging. The user can control the execution of the debugger target program by the debugger 31 by pointing the button in the menu with the mouse cursor. 79
Is a step button, which causes the debugger 31 to execute one line of the program to be debugged. Reference numeral 80 denotes a next button, which causes the debugger 31 to advance the execution of the debug target program until the beginning of the next process and stop the debug target program. A continue button 81 causes the debugger 31 to execute the debugger target program until the next breakpoint. A run button 82 causes the debugger 31 to execute the debugger target program from the beginning. Reference numeral 83 is an item for setting a break pointer. When the figure 83 is dragged to the place where a break is desired, the break pointer is set by the debugger 31 at that place. A break by the break pointer can be applied to a process (832), a text line (831), a process flow (833), writing to shared data, a message, and the like.

FIG. 59 is a diagram showing an operation related to a program break at the time of debugging. In the figure, 1
5 is a disk, 16 is a terminal controller, 17 is a display, 18 is a memory, 19 is an operating system, 85 is data for the operating system, 20
Is a library, 23 is a shared data area, 24 is a shared program area, 63 is a bus, 64 is a mouse, 65 is a keyboard, 141-142 are processors, 1411-142.
1 is a register, 211, 213 are processes 210-2.
02, 241-243, 325-327, 841-84
3 is a program.

In this figure, the debugger 31 is realized as a process, and the process 213 is the process. The process of 211 operates as a virtual processor to execute a program. The processor uses the registers 261 and 263 saved from the process in the memory.
By loading (643 to 644), the processing of the process can be executed. Debugger process 2
The program 325 owned by 13 is a program for setting a breakpoint. This program is started by selecting the item 83 in FIG.

In order to break during execution of the program to be debugged, it is necessary to embed a software interrupt instruction in the portion to be broken. However, the program cannot be rewritten from the program of the normal process. Therefore, the debugger program requests the program 841 in the operating system 19 to rewrite the program (674). Then, the operating system writes the software interrupt instruction 245 in the program 241 (675). When the processor 141 executing the process 643 executes the software interrupt instruction 245, the processing is transferred to the program 842 of the operating system 19. In the program 842, the rewritten program is returned to the original state and the process 211 is switched to the waiting state. When you want to rewrite the data with the debugger, the debugger program 2
Operating system program 843 from 13
To rewrite (678).

When the break pointer is set in the library, the process is stopped during the process of 732 in FIG. Also, at this time, it is necessary to change the color of the arrow on the screen. In this case, a color change message is sent to the debugger as in 855. Message received (85
4) The debugger program 327 sends a message to the GUI process 214 (852) to request a color change. In each library function, such processing is performed by the debug processing in step 732 in FIG. FIG. 60 shows details of the debugging process.

In the debugging process of the library function, it is first determined in step 861 whether the debug mode is being executed, and if it is not the debug mode, the process is terminated. If it was in debug mode, step 862
Change the color of the graphic representing the process being executed in step 86.
In step 3, send a message to change the color of the arrow representing the library being executed. In step 864, it is determined whether a break has occurred in the library call. If it is hanging, the process waits for a button input in step 866. If it is not hanging, it is checked in step 865 whether the flag of total stop is set. The overall stop flag is a flag for temporarily stopping the execution of the entire program. When the flag is set, the button input is awaited. In Step 867, Step 862
And a message to restore the color changed in step 863 to the original
I'm sending you.

As described above, according to this embodiment, it is possible to naturally describe a parallel program by a visual method. Furthermore, since hierarchical program development is possible, complex parallel programs can be created relatively easily. In addition, by integrating the program creation tool, the debug tool, and the evaluation tool, the life cycle of a program in which creation, debugging, and evaluation are repeated can be easily performed. Further, by explicitly expressing the access to the shared data by a graphic, it becomes easy to debug the access to the shared data, which has been difficult to catch in the past. In addition, since it is checked whether the shared data is properly accessed at the time of creating the program, it is less likely that a bug will be introduced into this part.

[0178]

As described above, according to the present invention, it is possible to hierarchically develop a program using hierarchical figures. Further, it is possible to satisfactorily visually represent an operation on data commonly used between processes executed in parallel. Further, it is possible to guarantee the determinism of the value of the data commonly used among the processes executed in parallel.

[Brief description of drawings]

FIG. 1 is a block diagram showing a configuration of a parallel computer.

FIG. 2 is an explanatory diagram showing a configuration of a process.

FIG. 3 is a block diagram showing a program execution environment constructed on a parallel computer.

FIG. 4 is a block diagram showing a configuration of a program development environment.

FIG. 5 is an explanatory diagram showing a description example of a program using graphics.

FIG. 6 is an explanatory diagram showing a description example of a program using graphics.

FIG. 7 is an explanatory diagram showing a description example of a program using graphics.

FIG. 8 is an explanatory diagram showing the structure of a graphic definition table.

FIG. 9 is an explanatory diagram showing the structure of a graphic internal table.

FIG. 10 is an explanatory diagram showing a configuration of a graphic list.

FIG. 11 is an explanatory diagram showing a configuration of a terminal list.

FIG. 12 is an explanatory diagram showing the structure of a text definition table.

FIG. 13 is an explanatory diagram showing the structure of a join definition table.

FIG. 14 is an explanatory diagram showing the structure of a barrier definition table.

FIG. 15 is an explanatory diagram showing the structure of a data definition table.

FIG. 16 is an explanatory diagram showing a mode menu.

FIG. 17 is an explanatory diagram showing the structure of an event vector table.

FIG. 18 is an explanatory diagram showing the structure of a window table.

FIG. 19 is a flowchart showing a procedure of processing performed by the GUI according to selection of a menu or the like.

FIG. 20 is a flowchart showing the procedure of program display processing performed by the GUI.

FIG. 21 is a flowchart showing the procedure of program display recursive processing performed by the GUI.

FIG. 22 is a flowchart showing the procedure of graphic display processing performed by the GUI.

FIG. 23 is a flowchart showing the procedure of exit arrow processing performed by the GUI.

FIG. 24 is a flowchart showing the procedure of entrance arrow processing performed by the GUI.

FIG. 25 is an explanatory diagram showing overlap of display of graphics.

FIG. 26 is a flowchart showing a procedure of processing for changing the overlap of the display of figures.

FIG. 27 is an explanatory diagram showing a program editing operation.

FIG. 28 is an explanatory diagram showing a list of library functions.

FIG. 29 is an explanatory diagram showing a display screen when a program is edited.

FIG. 30 is an explanatory diagram showing an initial display screen when a program is edited.

FIG. 31 is an explanatory diagram showing a graphic placement operation.

FIG. 32 is an explanatory diagram showing an operation of arranging an arrow indicating the start of processing.

FIG. 33 is an explanatory diagram showing an operation of arranging an arrow indicating the start of processing.

FIG. 34 is an explanatory diagram showing an operation of arranging an arrow indicating message communication.

FIG. 35 is an explanatory diagram showing an operation of arranging an arrow indicating message communication.

FIG. 36 is an explanatory diagram showing an operation of arranging an arrow indicating writing to shared data.

FIG. 37 is an explanatory diagram showing an operation of arranging an arrow indicating writing to shared data.

FIG. 38 is an explanatory diagram showing an operation of arranging an arrow indicating reading of shared data.

FIG. 39 is an explanatory diagram showing an operation of arranging an arrow indicating reading of shared data.

FIG. 40 is an explanatory diagram showing an operation for describing join synchronization.

FIG. 41 is an explanatory diagram showing an operation for describing join synchronization.

FIG. 42 is an explanatory diagram showing an operation for describing barrier synchronization.

FIG. 43 is an explanatory diagram showing an operation for describing barrier synchronization.

FIG. 44 is an explanatory diagram showing an example of a program in which shared data is indeterminate.

FIG. 45 is a flowchart showing a procedure for checking the determinism of shared data.

FIG. 46 is an explanatory diagram showing a display screen for warning the uncertainty of shared data.

FIG. 47 is a flowchart showing an initial processing procedure common to each process.
It is a chart.

FIG. 48 is an explanatory diagram showing operations at the time of execution of the library function mfork.

FIG. 49 is an explanatory diagram showing a relationship between thread and vp.

FIG. 50 is a flowchart showing a processing procedure when a library function is executed.

FIG. 51 is a flowchart showing the procedure of trace processing in the library function.

FIG. 52 is an explanatory diagram showing a structure of trace data.

FIG. 53 is an explanatory diagram showing a screen displayed by the tracer.

FIG. 54 is an explanatory diagram showing the structure of an address figure correspondence table.

FIG. 55 is a flowchart showing a procedure of trace result totaling processing.

FIG. 56 is a flowchart showing a procedure of trace result display processing.

FIG. 57 is a flowchart showing the procedure of another trace processing.
It is

FIG. 58 is an explanatory diagram showing a display screen in debug mode.

FIG. 59 is an explanatory diagram showing a break operation during a debug operation.

FIG. 60 is a flowchart showing the procedure of debug processing in the library function.

[Explanation of symbols]

11 cubicle 13 parallel computer 14 processor 141-143 processor 1411-1421 register 15 disk 16 terminal controller 17 display 18 memory 19 operating system 20 library 201-202 library function 211-216 process 22 trace data area 23 shared data area 24 shared program area 231 Thread Queues 241 to 243 Shared Programs 2611 to 2612, 262 to 263 Register Saving Areas 271 Data Areas 281 to 285 Message Queues 29 Compilers 30 Editors 31 Debuggers 32 Parallelism Evaluation Programs 321 to 332 Programs 33 Tracers 34 Trace Data 35 Source Programs 36 Object program

─────────────────────────────────────────────────── ─── Continuation of the front page (51) Int.Cl. ⁵ Identification code Internal reference number FI Technical display location G06F 15/16 430 Z 9190-5L 15/60 360 P 7623-5L

Claims (21)

[Claims] 1. A computer having a display device, which is a method of displaying a definition of a program including a plurality of processing units on the display device, wherein a plurality of graphics representing each of the plurality of processing units are formed. A graphic representing a data unit commonly accessed by two or more of the processing units, which is displayed in association with a graphic representing another processing unit related to the processing unit represented by the graphic, is a graphic representing a processing unit accessing the data. A method for displaying a program, characterized in that the definition of the program is displayed by displaying the program in association with. 2. A computer having an input device and a display device, which is a method of displaying the definition of a program composed of a plurality of processing units on the display device. A step of displaying a graphic representing each processing unit that is a unit of processing to be displayed on the display device in association with a graphic representing another processing unit related to the processing unit represented by the graphic, and representing a specific processing unit When the step of receiving the designation of the figure from the input device and the processing unit represented by the designated figure is further configured by a plurality of processing units, the designated figure is replaced by the designated figure. A graphic representing each of the plurality of graphics representing each of the plurality of processing units constituting the represented processing unit, which represents another processing unit related to the processing unit represented by the graphic. Association with, the display method of the program; and a step of displaying. 3. A computer having an input device and a display device, which is a method of displaying a definition of a program composed of a plurality of processing units on a display device, wherein a graphic representing each of the plurality of processing units is displayed. A step of displaying on the display device in association with a graphic representing another processing unit related to the processing unit represented by the graphic, and a step of accepting designation of the graphic representing a specific processing unit from the input device, When the processing unit represented by the figure is defined by text, in place of the specified figure, a text defining the processing unit represented by the specified figure, each text sentence included in the text, And a step of displaying the text sentence in association with a figure representing another processing unit related to the text sentence. 4. The method for displaying a program according to claim 2, wherein the graphic representing the processing unit defined by the combination of the plurality of processing units is not defined by the combination of the plurality of processing units. A method of displaying a program, characterized in that it is displayed so as to be distinguishable from a graphic representing a processing unit. 5. A program edit accepting method for accepting the editing of a program comprising a plurality of processing units in a computer equipped with a display device, wherein a plurality of processing units are designated by a graphic representing the processing unit. Accepted according to a designation, and accepting designation of shared data, which is data accessed by a plurality of processing units, according to a designation of a graphic representing the shared data, a relationship between the processing unit and the shared data, or a plurality of processing units An edit acceptance method for a program, which accepts designation of a relationship between them in accordance with designation of a figure connecting shared data and a plurality of figures representing a processing unit or a plurality of processing units. 6. A program edit accepting method for accepting editing of a structure of a program hierarchically composed of a plurality of processing units in a computer equipped with a display device, wherein the plurality of graphics respectively represent a plurality of processing units. And a plurality of graphics which correspond to a plurality of processing units and which hierarchically edit the graphics representing the relationship between the plurality of processing units on the display of the display device, thereby configuring a plurality of the programs. A method for accepting editing of a program, characterized by accepting editing of a hierarchical structure of processing units. 7. A program editing acceptance method according to claim 6, wherein the definition of the content of a processing unit having no lower processing unit on the hierarchy is accepted in a text format. How to edit. 8. A computer comprising a display device and an input device, wherein a graphic representing each of a plurality of processing units constituting a program to be edited is displayed on the display screen of the display device, and 2
The relationship between each processing unit and the shared data, or a plurality of processes, is established by connecting a graphic representing shared data, which is the data accessed by the processing unit, and a plurality of graphics corresponding to the shared data or the processing unit. A computer having means for accepting editing of a graphic representing a relationship between units according to an operation of the input device, and means for editing a program according to the accepted content of editing of each graphic. 9. The computer according to claim 8, further comprising means for verifying the uncertainty of the shared data at the time of executing the program, from the received edit contents of each figure. 10. A computer comprising a display device and an input device, wherein a plurality of graphics respectively representing a plurality of processing units constituting a program to be edited are associated with a plurality of associated graphics on a display screen of the display device. A unit that connects a plurality of graphics corresponding to processing units and that receives hierarchical editing of a graphic representing a relationship between a plurality of processing units on the display of the display device; and on the display screen of the display device, A means for accepting editing of text that defines the contents of a processing unit represented by a graphic that does not have a lower graphic in the hierarchy, and a hierarchical structure composed of a plurality of processing units according to the received edit contents of each graphic and text. And a means for editing the stored program. 11. The computer according to claim 10, wherein the means for editing the program connects a plurality of graphics corresponding to a plurality of processing units to be related to each other, and creates a graphic representing a relationship between the plurality of processing units. Means for adding / inserting a text sentence that realizes the relationship represented by the graphic to the text that defines the content of the processing unit represented by the graphic that is connected by the graphic that represents the relationship between the plurality of processing units according to the edited content. A computer characterized by having. 12. The computer according to claim 8 or 9, wherein the edited program is executed, history information, which is information indicating a history of execution of the program, is collected, and the collected history information is stored in the computer. Accordingly, among the displays of the graphic edited on the screen of the display device, the display of the graphic showing the executed processing unit, the display of the graphic showing the relationship used for the execution, and the accessed shared data are displayed. A computer having means for sequentially changing the display of the figure represented according to the order of execution. 13. The computer according to claim 8 or 9, wherein the edited program is executed, history information that is information indicating a history of execution of the program is collected, and the collected history information is stored in the collected history information. Accordingly, among the displays of the graphic edited on the screen of the display device, the display of the graphic showing the executed processing unit, the display of the graphic showing the relationship used for the execution, and the accessed shared data are displayed. There should be means for changing the display of the graphic representing the processing unit according to the number of executions for the graphic representing the processing unit, the number of executions for the graphic representing the relation, and the number of access for the graphic representing the shared data. A calculator characterized by. 14. The computer according to claim 10 or 11, wherein the edited program is executed, history information, which is information indicating a history of execution of the program, is collected. Accordingly, among the displays of the graphic edited on the screen of the display device, the display of the graphic showing the executed processing unit and the display of the graphic showing the relationship used for the execution are sequentially displayed in the order of execution, A computer having means for changing. 15. The computer according to claim 10 or 11, wherein the edited program is executed, history information, which is information indicating a history of execution of the program, is collected. Accordingly, among the displays of the graphic edited on the screen of the display device, the display of the graphic showing the executed processing unit and the display of the graphic showing the relationship used for the execution are described with respect to the graphic showing the processing unit. Is a computer having a means for changing the number of times of execution and the number of times of execution of the graphic representing the relationship. 16. The computer according to claim 8 or 9, wherein means for sequentially executing the edited program in response to a predetermined operation from the input device, and on the screen of the display device. Of the display of the edited figure,
A computer having a graphic representing a processing unit being executed and a graphic representing a shared data being accessed. 17. The computer according to claim 10 or 11, wherein means for sequentially executing the edited program in response to a predetermined operation from the input device, and on the screen of the display device. Among the displays of the edited graphic and text, a means for changing the display of the graphic representing the processing unit being executed and the display of the text being executed, and a computer. 18. The program display method according to claim 1, 2, 3 or 4, wherein when the plurality of figures are displayed in a state where the plurality of figures overlap each other, a weight A method for displaying a program, characterized by changing the order and displaying. 19. The computer according to claim 9, wherein when the shared data having uncertainty is present, the processing unit related to the factor of the uncertainty is determined from the received edit content of each figure. Alternatively, a computer having means for changing and changing all or part of display of shared data or a graphic representing a relationship. 20. The computer according to claim 8 or 10, comprising a plurality of processors for executing the edited program, and means for collecting history information, which is information indicating a history of execution of the program, for each processor. Of the graphics displayed on the screen of the display device according to the collected history information, at least at each point during the execution period of the executed program, the display of a graphic representing the processing unit executed and the execution. At each time point during the program execution period, the display of a graphic representing the relationship used for execution is sequentially changed according to a time sequence, and the execution status of each processor at each time point is displayed on the display device. A calculator that is characterized. 21. A computer having a display device, wherein a plurality of graphics representing each of a plurality of processing units constituting a program are associated with a graphic representing another processing unit associated with the processing unit represented by the graphics. A means for displaying a graphic representing data that is commonly accessed by two or more processing units in association with a graphic representing a processing unit that accesses the data; and a means for executing the displayed program. Means for collecting history information, which is information indicating the history of program execution, and a graphic representing the executed processing unit among the graphics displayed on the screen of the display device according to the collected history information. And a display of a graphic representing the relationship used for execution, and a display of a graphic representing the accessed shared data.