JPH11134307A - Program development supporting device and method therefor and recording medium for recording program development supporting software - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a technique for preparing complicated plural parallel programs with excellent reliability and efficiency. SOLUTION: A preparing means 3 prepares the scenario of execution from a first parallel program 2. An analyzing means 12 extracts a dependent relation from the first parallel program 2. A decomposing means 5 hierarchically decomposes the scenario judged to be correct into blocks in which a loop is not included. A paralleling mean 7 parallels the scenario by assigning the scenario to plural processes by using the block as a unit. An integrating means 8 integrates the assigned scenario for each process. A generating means 10 generates a second parallel program 11 from the integrated scenario of each process. Even the parallel program whose structure is complicate is decomposed into blocks and processed so as to be developed as easy as sequential programming.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an improvement of a technique for developing a concurrent program, and more specifically, to a technique for creating a complicated concurrent program with excellent reliability and efficiency.

[0002]

2. Description of the Related Art A concurrent program is a program in which a plurality of processes operate concurrently in parallel, and has a complicated structure in which the overall operation is determined by the interrelationship between the separately running processes. Therefore, it is more difficult to create a parallel program than a sequential program in which processes operate sequentially according to a single flow. In particular, the behavior of a concurrent program is non-deterministically different for each execution, depending on which part of which process is executed and at what timing.
As a result, bugs in concurrent programs are poorly reproducible,
In addition, since the number of test cases to be tested is extremely large, it is very difficult to test and debug.

[0003] Ultra-sequential programming is known as a technique for supporting the creation of such a concurrent program and improving the reliability of the concurrent program (Japanese Patent Laid-Open No. Hei 8-16442).
9). In this technique, a super-sequential program is created by serializing a concurrent program once. What is a super sequential program?
This is a serialized version of the original concurrent program while maintaining information about its concurrent structure. Then, programming, testing, and debugging are performed on such a super-sequential program, and a parallel program with high reliability can be created by parallelizing the super-sequential program again based on the results.

For example, a test is performed by giving a test case to a concurrent program, and a correct execution log determined to have no bug is temporarily serialized from the original concurrent program among execution logs at the time of the test. It is regarded as a kind of super sequential program. Then, by merging a plurality of such correct execution logs, a scenario graph representing a correct behavior of the hyper-sequential program is created. This scenario graph, along with synchronization instructions that specify the order of execution between parts,
Re-parallelize by assigning portions to multiple processes to create concurrent programs.

[0005] Further, in another technology filed by the present applicant,
The concurrent program is divided into sections, which are the units of execution control, and the correct execution order between sections is represented by the path of the scenario graph. By assigning each operation included in this path to each process together with a synchronization instruction designating the execution order between operations, a concurrent program showing correct behavior is created. Note that a concurrent program may include several paths that represent different execution orders,
By automatically restoring a path equivalent to the scenario graph, such as when the execution results for each path are the same,
More flexibility in the behavior of the generated concurrent program,
Execution efficiency is improved.

[0006]

However, in these prior arts, when a correct behavior of a program is represented by a scenario graph, a scenario graph having a planar structure having only a single hierarchy is used. In other words, in this scenario graph, each part of the program is represented by an arc, and nodes representing each state are connected by an arc, so that the execution order between the parts of the program is represented by a state transition graph having a planar structure. It was done. When trying to represent a complex structure such as a loop or a hierarchical structure with a scenario graph having a planar structure, the scenario graph becomes complicated and large-scale according to the complexity of the structure. Not only does it become complicated or the processing efficiency deteriorates, but also the scenario graph itself becomes difficult to understand. For this reason,
The prior art as described above has a problem that it is difficult to apply it to a complicated concurrent program.

The present invention has been proposed to solve the above-mentioned problems of the prior art, and has as its object to provide a technique capable of creating a complicated concurrent program with excellent reliability and efficiency. That is.

[0008]

According to another aspect of the present invention, there is provided a program development support apparatus for creating an execution scenario from a first concurrent program, and analyzing the first concurrent program. Means for extracting a dependency existing between portions of the first concurrent program, means for hierarchically decomposing the scenario into blocks not including a loop, and means for extracting the scenario based on the dependency. Means for parallelizing by assigning a plurality of processes in units of the block, means for integrating the scenario assigned to each process for each process, and second parallel processing from the scenario for each integrated process. Means for generating a program. A program development support method according to a seventh aspect is obtained by grasping the invention according to the first aspect from a method viewpoint.
Creating an execution scenario from a first concurrent program; analyzing the first concurrent program to extract dependencies between portions of the first concurrent program; Hierarchically decomposing into blocks that do not include a loop, parallelizing by assigning the decomposed scenario to a plurality of processes in units of the blocks based on the dependencies, Integrating the scenario for each process, and generating a second concurrent program from the integrated scenario for each process. According to a tenth aspect of the present invention, the invention of the first aspect is grasped from the viewpoint of a recording medium on which software is recorded. In a recording medium on which program development support software for supporting concurrent program development using a computer is recorded. The program development support software causes a computer to create an execution scenario from a first concurrent program, and analyzes the first concurrent program to determine a dependency existing between portions of the first concurrent program. Extraction, the scenario is hierarchically decomposed into blocks that do not include loops, and the decomposed scenarios are parallelized by assigning the decomposed scenarios to a plurality of processes in units of the blocks based on the dependencies. Integrate scenarios assigned to each process and integrate them Thereby generating a second concurrent program from been per process scenario characterized. According to the first, sixth and tenth aspects of the present invention, the concurrent program is temporarily serialized in the form of a scenario confirmed to be correct, and the concurrent program is generated again based on this scenario, thereby improving the reliability of the concurrent program. . At that time, the scenario is once hierarchically decomposed into blocks that do not include a loop. Then, each decomposed block is assigned to each process to be parallelized, and each process is integrated again to generate a parallel program. Since each decomposed block does not include a loop or a hierarchical structure, parallel processing can be performed efficiently, and development can be performed efficiently as a whole concurrent program.

According to a second aspect of the present invention, in the program development supporting apparatus according to the first aspect, the decomposing means has means for normalizing a given scenario. According to the second aspect of the present invention, the scenario is converted into a regular expression by normalizing the scenario, and the scenario converted into the regular expression can be easily decomposed hierarchically. For this reason, the decomposition of the concurrent program is made more efficient.

According to a third aspect of the present invention, in the program development support apparatus according to the first or second aspect, the parallelizing means embeds a synchronization instruction corresponding to the dependency in the scenario when assigning the scenario to a process. It is characterized by comprising. According to the third aspect of the present invention, a scenario is assigned to a process while embedding a synchronous instruction. Therefore, the execution timing of each part between processes is controlled so as to conform to a preceding constraint based on a dependency, and a finally obtained concurrent program is obtained. Reliability is ensured.

According to a fourth aspect of the present invention, in the program development support apparatus of the third aspect, the parallelizing means is configured to remove a redundant synchronization instruction from the synchronization instructions embedded in a scenario. It is characterized by the following. According to an eighth aspect of the present invention, the invention of the fourth aspect is grasped from the viewpoint of a method. In the program development support method according to the seventh aspect, the step of parallelizing is performed when the scenario is assigned to a process. And a sub-step of removing redundant synchronization instructions from the synchronization instructions embedded in the scenario. According to the fourth and eighth aspects of the present invention, by removing redundant synchronization instructions, the degree of freedom in what timing the processes operate with each other is expanded. This means optimizing a concurrent program by giving harmless nondeterminism. Concurrency can be restored as much as possible in a concurrent program once serialized in the form of a scenario.

According to a fifth aspect of the present invention, in the program development support apparatus according to the fourth aspect, the parallelizing means suppresses an action of an arbitrary synchronization instruction embedded in a scenario when removing the redundant synchronization instruction. Then, between each scenario before and after the suppression, it is determined whether or not the execution order that the operation having the dependency relationship can show is the same, and if the execution order is the same, The method is characterized by being configured to remove an instruction. The invention of claim 9 is
The invention of claim 5 is grasped from a method point of view, wherein in the program development support method according to claim 8, the removing sub-step suppresses an action of an arbitrary synchronization instruction embedded in a scenario, and It is determined whether or not the execution order that the operation having the dependency relationship can indicate is the same between the previous and subsequent scenarios, and if the execution order is the same, the synchronous instruction whose operation has been suppressed is removed. It is characterized by. According to the fifth and ninth aspects of the present invention, since the synchronous instruction which does not affect the execution order of the operation having the dependency is removed, the execution order of the operation having the dependency is correctly corrected while expanding the degree of freedom of the operation of the concurrent program. Will be maintained.

According to a sixth aspect of the present invention, there is provided a program development method for supporting the development of a concurrent program using a scenario, the method further comprising the step of determining whether two scenarios including mutually dependent parts are equivalent. The determining step includes, for each of the two scenarios, a sub-step of calculating a set of counting traces that indicates when the dependent part has been executed, and comparing the calculated two sets. And a sub-step of determining that the two scenarios are equivalent when they are equal to each other. In the development of a concurrent program, the determination of whether or not scenarios are equivalent can be used for normalization of scenarios, removal of redundant synchronization instructions, and the like. In the invention of claim 6,
The determination of the equivalence is performed based on the counting trace indicating when the part having the dependency is executed. Here, in the concurrent program, if the execution order of the parts having a dependency is changed, a bug may be caused. However, if the execution order is freely set, the execution of the execution order does not cause a bug. This has the effect of increasing the flexibility of the program. According to the sixth aspect of the present invention, only the parts having a dependency in the determination of the equivalence are considered as problems.
While preventing the occurrence of bugs, the flexibility of the concurrent program can be enhanced by increasing the degree of freedom of the execution order for the portions that do not cause bugs.

[0014]

DESCRIPTION OF THE PREFERRED EMBODIMENTS Next, a program development support device (hereinafter referred to as "the present device") according to an embodiment of the present invention will be described with reference to the drawings.

[1. Configuration] [1-1. Configuration of Computer System for Realizing the Present Apparatus] First, FIG. 1 shows a configuration example of a computer system for realizing the present apparatus. This computer system includes N processors 211 and 21 for simultaneously and concurrently executing processes constituting a parallel program.
,..., 21N.
, 21N, a shared memory 23 and peripheral devices are connected via an I / O interface 22. As the peripheral devices, an input device 24, an output device 25, and an external storage device 26 are used.

Among the above peripheral devices, the input device 4 is a device for inputting various commands and data, and has a keyboard and a pointing device such as a mouse. Also,
The output device 5 is provided on a display screen such as a CRT display,
This is a device that presents to a user by displaying text or graphic information on a source program, debugging status, and the like. In addition, a printer or the like can be used as appropriate as the output device. The user can interactively operate the computer using the input device 4 and the output device 5. Also, the external storage device 6
Is a device that writes and reads a source program and information related to a debugging situation using a recording medium such as a magnetic disk or a magneto-optical disk.

The present apparatus is realized by controlling various hardware resources of the computer system as described above by software. However, since the computer system and the specific configuration of the software can be variously considered,
Hereinafter, the present embodiment will be described using virtual circuit blocks that realize the functions of the present apparatus.

[1-2. Configuration based on functional block diagram]
That is, FIG. 2 is a functional block diagram showing the configuration of the present apparatus. As shown in this figure, the present apparatus includes an editing unit 1,
It has a creating unit 3 and a disassembling unit 5. The editing unit 1 is a unit 1 for creating and modifying the first parallel program 2. The creating unit 3 creates an execution scenario based on the first concurrent program 2 and provides scenario information 4 representing the scenario. Further, the decomposing unit 5 provides structural scenario information 6 that hierarchically decomposes a scenario determined to be correct into blocks that do not include a loop and that represents the scenario decomposed into blocks together with the structure between blocks. Means.

The apparatus has an analyzing means 12, a parallelizing means 7, an integrating means 8, and a generating means 10. The analysis means 12 includes the first parallel program 2
Is a means for extracting the dependency existing between the respective parts of the first concurrent program 2 by analyzing the information, and providing analysis information 13 representing the dependency. The parallelizing means 7 is a means for parallelizing the decomposed scenarios by allocating them to a plurality of processes in units of blocks while maintaining the execution order between the parts corresponding to the extracted dependencies. Further, the integrating means 8 includes the analysis information 1
The local scenario information 9 representing the integrated scenario for each process by integrating the scenarios assigned to each process for each process while referring to FIG.
It is a means to provide. Further, the generation means 10 generates a second parallel program 11 based on the local scenario information 9.
Is a means for generating

[2. Overall Processing Procedure] FIG. 3 is a flowchart showing an overall processing procedure in the apparatus having the above-described configuration. [2-1. Creation of First Concurrent Program] First, the user creates a first concurrent program 2 using the editing means 1 (step 1). Here, the programming language for creating the concurrent program can be freely selected,
For example, it may be described in a concurrent programming language such as Java, or may be described by combining a sequential programming language such as C language with a system call of an operating system such as μ-ITRON.

[2-2. Creation of Scenario] Next, the creation means 3 creates a scenario when the first concurrent program 2 is executed (step 2). Here, a scenario represents the behavior of a program as a sequential sequence of instructions in the program to be executed.

To create such a scenario, for example, a test case is given to virtually execute the first concurrent program 2 and its execution history is used as a scenario.
The execution order between each part which can be shown by the concurrent program 2 of
It is conceivable that the path is represented as each path of a branching graph, a path corresponding to an unacceptable execution order is deleted from the graph, and the resulting graph is used as scenario information. Here, each route included in the graph corresponds to an individual scenario.

As a specific format for expressing such a scenario, for example, a scenario graph in a state transition diagram format can be considered. The scenario graph is a directed graph in which the overall state of the system realized by the concurrent program, that is, the global state, is a node, and each operation of the program is represented by an arc connecting the nodes. Here, in a parallel program composed of a plurality of processes, the global state is a combination of the state of which position each process is executing and the state of the memory of each process. The scenario created as described above is provided to later steps as scenario information 4 representing the content of the scenario. That is, in the present application, a “scenario” is a sequence of one instruction that can be indicated by a program, and a “scenario graph” represents a set of one or two or more scenarios. In this case, one path (path) in the scenario graph represents one scenario. The “scenario information” is information that represents a set of one or more scenarios in a format such as a scenario graph as described above.

[2-3. Confirmation of Scenario Behavior] For the scenario created in this way, the user confirms that the behavior of the concurrent program 2 represented by the scenario is as specified and correct (step 3). This confirmation may be performed by using a conventionally known program test method. If there is an incorrect scenario (step 4),
Since there is a bug in the first concurrent program 2 which is the source of the scenario, the first concurrent program 2
Is corrected (step 1), a scenario is created again (step 2), and it is confirmed that the scenario is correct. If it is confirmed that the scenario is correct (step 4), to create a further scenario, create the scenario (step 2)
When the creation of the scenario ends, the process proceeds to the next step 6.

As described above, when a plurality of scenarios are sequentially created, a plurality of scenarios are integrated by adding a different route between the already created scenario and the newly created scenario to the already created scenario. Into single scenario information. For example, in the scenario graph, when the execution order between the program parts is different in the latter half of two scenarios, the scenario graph is branched into two from the middle, and the paths corresponding to the different orders are branched. By continuing beyond
The two scenarios can be represented by single scenario information. When a plurality of scenarios are created, the correctness may be checked each time a single scenario is created. However, after a plurality of scenarios are continuously created, the correctness may be checked collectively. Good.

[2-4. Extraction of Dependency] As described above, the correctness of each scenario represented by the scenario information is confirmed, and if it is considered that there is no bug in the first concurrent program 2, in step 6, the analyzing means 12 By analyzing the first concurrent program 2, a dependency between instructions constituting the first concurrent program 2 is extracted.

Here, the dependency relationship is a relationship in which different parts of a program are based on each other, and there are data dependency and control dependency. A dependency is a relationship that exists mutually between program parts, that is, has a symmetry. For two instructions having such a dependency, there is a possibility that the calculation result will differ depending on the execution order, and there is a restriction that one must be executed before the other. Such a constraint is called a preceding constraint. Algorithms for extracting such dependencies and precedence constraints are already known, and are specifically described in the document "Hiroki Honda: Automatic Parallelizing Compiler, Information Processing Vol.3
4.No.9,1993 ”.

That is, first, which process is to be executed is not determined by the conditional branch between processes, and when all processes are executed, the dependency can be detected by obtaining data dependency between processes. Data dependence is a relationship in which one instruction depends on data provided by the other instruction. For example, as shown in FIG. 4A, an instruction write (M, X) for writing the value of X to the shared variable M
And an instruction Y = read for reading data from the same shared variable M
There is a direct data dependency between (M).

As shown in FIG. 4B, the value written in the shared variable M is temporarily copied to another variable M2, and the read command is the same as the write command when data is read from this variable M2. There are indirect data dependencies between the read instructions. Such direct data dependence and indirect data dependence can be extracted by tracing which processing is performed on which variable by each instruction.

When a process to be executed is determined by a conditional branch between processes, it is necessary to obtain control dependence in addition to the data dependence. Control dependence means that until one condition evaluates to true,
This is a dependency in which the execution of the other process cannot be started. Such control dependence is detected by examining the relationship between the conditional branch instruction included in each process and each process.

A set of dependencies between instructions of the concurrent program C as described above is represented as D (C). That is, (t
(i, tj) ∈D (C) means that a dependency exists between the instructions ti and tj. Further, in the operation sequence θ indicated by the given concurrent program C, the precedence constraint between the operations is defined as follows. That is, when the precedence constraint is represented by the symbol “<<” and the i-th operation of the scenario θ is represented as c (θ, i), c (θ, i) << c (θ, j) iff (θ [i], θ [j]) ∈D (C) and
i <j. This means that the i-th and j-th actions in scenario θ have a dependency, and if i is greater than j (preceding), the i-th action must precede the j-th action. Indicates that a precedence constraint exists. In the present invention, the “operation” specifically means a program instruction, for example, an operation and substitution instruction such as “a = b−1” or an evaluation instruction such as “a == b”. Is the unit of instruction. The dependency extracted as described above is provided to later steps as analysis information 13 representing the dependency.

[2-5. Scenario Decomposition] The scenario information confirmed to be correct is hierarchically decomposed into blocks not including a loop by the decomposing means 5 (step 7). Here, in general, concurrent programs often continue to run forever, and scenarios based on concurrent programs often have loops. For this reason, in the decomposition of the scenario, the part that does not include the loop is a block, and the loop is
As a path connecting the end and the beginning of such a block,
Distinguish from the block itself. Further, since loops may be multiplexed, decomposition is performed hierarchically.

The original scenario decomposed in this way is
When represented as a scenario graph, which is a directed graph, each block obtained by decomposition can be represented as an acyclic graph having lower blocks as nodes. This acyclic graph is a graph that does not include a loop. For example, as shown in FIG. 5B, the scenario graph shown in FIG. 5A is decomposed into a block B1 not including a loop and other portions, and this block B1 is further divided into a block B2 including no loop. And is decomposed into other parts. Such a block that does not include a loop is hereinafter referred to as an acyclic block.

Further, the disassembled scenario is shown in FIG.
Instead of using a graph like this, it is also possible to use the following regular expression equivalent to this graph. t14 + (t1 (t2 t3 t4 + t7 t8 (t12 t13 t14) * t9 t10 t1
1) t5 t6) * Here, t1 + t2 represents “t1 or t2”, and t1 *
Represents 0 or more repetitions of t1. A detailed procedure for decomposing a scenario and a regular expression will be described later.

As a result of decomposing the scenario as described above, information indicating the contents of each block and information indicating a higher order and lower order between blocks other than the block, such as a loop, are obtained. Called scenario information.
That is, the structural scenario information 6 is obtained from the disassembly unit 5.
Provided for later steps.

[2-6. Parallelization of Scenario] Subsequently, a process of allocating the scenario decomposed as described above to a plurality of processes for each block, that is, parallelization is performed (step 8). Here, it is assumed that the structure of the process, for example, the number of processes to be used, is the same as that of the first concurrent program 2, but of course, the structure of the process can be arbitrarily set.

At the time of this parallelization, the program analysis information 1
3 is used. That is, parallelization means that parts having no dependency in a scenario can be moved in parallel with each other. For example, in one scenario, in the instruction a of the process P1 and the instruction b of the process P2 in the serial relationship (ab), if there is no dependency between a and b, the parallel relationship (a) is assigned by assigning a and b to different processes. a‖b)
Can be On the other hand, for instructions having a dependency, synchronous instructions are inserted before and after each instruction during parallelization in order to satisfy the preceding constraint derived from the dependency.

The parallelizing means 7 removes redundant synchronization instructions from such parallelized scenarios. Here, the criterion for determining whether or not a synchronization instruction is redundant is that, even if the synchronization instruction is removed from the scenario, a set of scenarios generated by regarding the removed scenario as a concurrent program is the same as the scenario before the removal. It is determined whether or not it is equivalent to a set of scenarios generated assuming that the synchronous command is redundant even if it is removed. A detailed procedure for removing redundant synchronization instructions using the equivalent concept will be described later.

[2-7. Integration of Scenarios] As a result of the parallelization as described above, a portion of a scenario originating from a different block is assigned to each process independently of each other. Therefore, the integrating means 8 integrates the scenarios assigned to each block as a unit for each process (step 9). The detailed procedure of this integration will be described later. Further, as a result of the integration, local scenario information (9) representing a scenario for each integrated process is provided to a later step.

[2-8. Generation of second concurrent program]
Finally, the generating means 10 generates the second concurrent program 11 from the local scenario information 9 for each process integrated as described above (step 10). Since the second parallel program 11 generated here reproduces only the scenario represented by the original scenario information 4 and the behavior equivalent to the scenario, the scenario given in step 2 is correct. If this is the case (step 4), it is guaranteed that this second concurrent program is also correct.

[3. Detailed Procedure] Next, taking a case where the scenario is given by a directed graph as an example, a detailed procedure of the decomposition of the scenario (Step 7) among the procedures of Steps 1 to 10 described above will be described. Detailed procedures will also be described for parallelizing scenarios (step 8) and integrating scenarios (step 9).

Here, the given scenario is shown in FIG.
4A is a scenario graph as shown in FIG. 5A. The nodes of the scenario graph represent the global execution state of the first program 2, and the arc between nodes is within the first concurrent program 2. T1 and t14. Also, a plurality of scenarios are represented by one scenario graph, and one scenario corresponds to one route on the scenario graph.

[3-1. Detailed Procedure of Scenario Decomposition] [3-1-1. Normalization of Scenario Graph] In order to decompose a scenario graph, first, a scenario graph SGr converted from a scenario graph SG created by a user into a regular expression is created. Here, the regular expression is a data structure in which the loop part repeats 0 or more times, and is a scenario graph SG that is not a regular expression.
Generating a scenario graph SGr converted from a normal expression into a regular expression is called scenario graph normalization. At this time,
SGr is generated so that SG and SGr can be guaranteed to be semantically equivalent. The scenario graph SGr thus normalized is equivalent to the original SG, but has a structure that can be easily decomposed by extracting a hierarchical structure.

Here, the semantic equivalence of two scenarios is called scenario equivalence, the feature that two scenarios are equivalent is called equivalence, and the equivalence is represented by the symbol "==
= ”. In this case, equivalence can be defined as follows: That is, two scenarios θ1 and θ2 are scenario equivalent (θ1 === θ2) if the following condition is satisfied. (1) For any i, there exists a certain j, and c (θ1, i)
= c (θ2, j), and for any j, there exists a certain i, and c (θ2, j) = c (θ1, i). (2) For any i1, i2, there exists a certain j1, j2, and c (θ1, i1) = c (θ2, j1) and c (θ1, i2) = c (θ
2, j2) and c (θ1, i1) << c (θ1, i2) → c (θ2, j1) <<
c (θ2, j2)). (3) For any j1, j2, there exists a certain i1, i2, and c (θ1, i1) = c (θ2, j1) and c (θ1, i2) = c (θ
2, j2) and c (θ2, j1) << c (θ2, j2) → c (θ1, i1) <<
c (θ1, i2)).

On the premise of such scenario equivalence, the fact that scenario graphs representing scenarios are equivalent is called scenario graph equivalence. Then, two scenario graphs SG1 = (S1, T1, δ1, s01) and SG
For 2 = (S2, T2, δ2, s02), SG1 and SG2 are equivalent to a scenario graph (SG1 === SG
2) is that the following condition is satisfied. That is,
For an arbitrary SG1 scenario θ1, there is a certain SG2 scenario θ2, θ1 === θ2, and for an arbitrary SG2 scenario θ2, there is a certain SG1 scenario θ1 and θ1 === θ2.

Next, an example of a procedure for normalizing a given scenario graph while maintaining the above equivalence will be described. First, from a given scenario graph, a loop that may not be executed at all is detected based on a branch structure or the like. Next, in the loop, even if the loop is not executed, an arc shared with the path to be executed is detected. The loop is made independent from other parts by making the same arc as the detected arc exclusive to the loop.

More specifically, the scenario graph is a finite automaton, and for normalization of the scenario graph, a known algorithm for generating an equivalent regular expression from the finite automaton is used (references: Fukumura, Inagaki / Automaton, Formal Language Theory and Computational Theory, Iwanami Shoten, 198
2). In the scenario graph converted into such an equivalent regular expression, since a loop and other parts are clearly separated, it is easy to extract a hierarchical structure.

[3-1-2. Hierarchical decomposition into blocks)
Following the normalization as described above, the normal scenario graph S
Gr is hierarchically decomposed into blocks that do not include a loop, as shown in FIG. In each of the hierarchies included in the hierarchical structure obtained by such decomposition, the scenario can be represented as a subgraph that does not include loops, with the lower blocks as nodes.

That is, in order to decompose the scenario normalized as described above, the largest loop is found from the scenario, and the loop is divided into a block that does not include the loop and a path that connects the end and the beginning of the block. Separate. Then, the next largest loop is searched for from the block thus created, and such a procedure may be repeated hierarchically until no loop is found. For example,
When the scenario shown in FIG. 5A is given, a loop structure including t1-t2-t3-t4-t5-t6 is extracted as the largest loop, and as shown in FIG. B1. Further, a loop t12-t13-t14 is extracted from the block B1, and this portion becomes a block B2.

[3-2. Detailed Procedure for Scenario Parallelization] In the scenario parallelization (step 8), the following procedure is performed for each acyclic block of each layer obtained by the above-described decomposition. This is because it is difficult to parallelize the case including the loop and the case not including it in a uniform procedure. A similar approach has been adopted in the conventional parallelization of a sequential program in a supercomputer compiler (references:
M. Girkar and CD Polychronopoulos, Automatic Ext
raction of Functional Parallelism from Ordinary Pro
grams, IEEE Trans.on Parallel and Distributed Sys
tems, Vol. 3, No. 2, 1992).

[3-2-1. Synchronous operation insertion)
If there is no dependency between the instruction t11 of the process P1 and the instruction t21 of the process P2 that constitute the acyclic block, these two instructions t11 and t21 are assigned to the respective processes so that the parallel relationship (t11‖
t21). The same applies to two blocks having no dependency. It is to be noted that to which process each instruction belongs in the first concurrent program 2 is determined, so in the parallelization of the scenario, each instruction is projected to the process to which each instruction belongs. When parallelizing instructions or blocks having a serial relationship having a dependency or parallelizing a block including a branch, a synchronous instruction is used as follows.

First, a synchronization instruction si is inserted between serially dependent instructions and blocks having a dependent relationship. For example, it is assumed that operations t11 and t21 having a mutual dependency are serially connected in a block having a scenario (FIG. 6A). Then, based on the dependency between operations t11 and t21,
It is assumed that there is a precedence constraint that the operation t11 must precede the operation t21. In this case, by inserting the synchronization instruction s1 between the serial operations t11 and t12, t11 t21 → t11 s1 t21 (FIG. 6B). Also, for example, when there is a similar preceding constraint between the blocks B1 and B2, the synchronization instruction s1
To make B1 B2 → B1 s1 B2.

Also, a synchronization instruction is inserted into each branch. For example, in the example of FIG.
The operation sequence branches into a path on the left including the operations t12-t13 and a path on the right including the operations t21-t22 according to the content of the operation t12-t13. In this case, as shown in FIG. 7 (b), the synchronization instructions s1 and s2 are inserted into the parts branching to the respective paths, and t11 (t12 t13 + t21 t22) → t11 (s1 t12 t13 + s2 t21)
t22). Also, for example, in the case of branching into blocks B2 and B3 based on the branching operation in block B1, synchronization instructions s1 and s2 are similarly inserted into portions branching to respective paths, and B1 (B2 + B3) → B1 (s1 B2 + s2 B3).

[3-2-2. Projection to process)
The scenario in which the synchronization command is inserted as described above is projected to each process. Here, "projection" means to assign a part of a scenario to each process. here,
B | _P means the projection of block B onto process P.

For example, in FIG. 6B, the operations t11 and t21 are included in the scenario in which the synchronization instruction s1 is inserted, but the operation t11 is assigned to a certain process P1 and the operation t21 is assigned to another process P2. When assigning
As shown in FIG. 6C, in the process P1, an operation t11 is performed.
After that, in the process P2, the synchronous instruction s1 is allocated before the operation t21, so that t11 s1 t21 → t11 s1 ‖s1 t21. In this case, since the synchronization instruction s1 of the process P2 is in a waiting state until the synchronization instruction s1 is executed in the process P1, the operation t21 of the process P2 is always performed by the process P2.
The execution is started after the execution of the first operation t11 is completed.
Therefore, the execution order of the operations t11 and t21 is maintained so as to match the preceding constraint.

Similarly, when there is a precedence constraint between the blocks B1 and B2, the inserted synchronous instruction s1 is assigned to each process together with the blocks B1 and B2, so that B1 s1 B2 → (B1 | P1 ) s1 (B2 | P1) ‖ (B1 | P2) s1 (B2 |
P2).

In FIG. 7B, the scenario where the synchronization commands s1 and s2 are inserted includes a left path including the operations t12 and t13 and a right path including the operations t21 and t22. It is assumed that these two paths are respectively assigned to different processes P1 and P2. In this case, as shown in FIG. 7C, in the process P1, the operation t11
, The synchronization instruction s1 is inserted into the left path executed in the process P1, and the right path is configured to end the synchronization instruction s2 last. In the process P2, on the contrary, the path of the synchronization instruction s1 is configured to be terminated, and the path on the right side after the operation t21 is configured following the synchronization instruction s2, so that t11 (s1 t12 t13 + s2 t21 t22). ) → t11 (s1 t12 t13 + s
2) Let ‖ (s1 + s2 t21 t22). In this case, when the operation t12 and the subsequent operations are executed following the synchronization instruction s1 in the process P1, the process P2 ends with the synchronization instruction s1 and the operations t21 and the subsequent operations are executed following the synchronization instruction s2 in the process P2. If so, the process P1 ends with a synchronization instruction s2. For this reason, even if the processes P1 and P2 are observed together, both the right and left paths shown in FIG. 7B are not executed at the same time, and the branch of the branch included in the original scenario is not executed. Structure is preserved.

Similarly, in the case of branching to blocks B2 and B3 based on the branching operation in block B1, the inserted synchronous instructions s1 and s2 are allocated to the respective processes together with the blocks, and B1 (s1 B2 + s2 B3) → (B1 | P1) (s1 (B2 | P1) + s2 (B
3 | P1)) ‖ (B1 | P2) (s1 (B2 | P2) + s2 (B3 | P2)). In this case, the block B follows the synchronization instruction s1.
When Step 2 is executed, of the respective portions of the block B2, the portion projected to the process P1 is executed in the process P1, and the portion projected to the process P2 is executed in the process P2. Further, following the synchronization instruction s2, the block B3
Is executed, in the process P1, of the portions of the block B3, the portion projected to the process P1 is executed,
In the process P2, the part projected on the process P2 is executed.

At the time when the above-mentioned projection is performed, an instruction corresponding to the process in the first concurrent program 2 is assigned to each process, and all the synchronous instructions inserted in the block are Assigned to all processes.

[3-2-3. Removal of Redundant Synchronous Instruction] Subsequently, a redundant synchronous instruction is extracted for each acyclic block from all allocated synchronous instructions, and is removed. For example, FIG. 8B shows the result of projecting the scenario of FIG. 8A onto the processes P1 and P2 and setting (s1 as2 + s3 s4 a) ‖ (s1 s2 b + s3 bs4). In this example, the synchronous instructions s1, s2, s
3 and s4 are used, but in the scenario of FIG. 8A, both the order of a → b and the reverse order of b → a are both allowed, so that the synchronization instructions s1, s2, s
3 and s4 are redundant. Therefore, the state shown in FIG. 8C can be obtained by removing these synchronization instructions.

[3-2-3-1. Primitive procedure] The procedure for removing such redundant synchronization instructions from the scenario graph SG can be primitively expressed as follows.
That is, an arbitrary synchronization instruction s is selected, and the graph SG before the removal is compared with the graph SG ′ after the removal,
If both are equivalent to the scenario graph (SG == SG ′), the process of deleting the synchronization command s is repeated, and when one synchronization command cannot be removed even if this process is repeated for all the synchronization commands. The process ends.

[3-2-3-2. Procedure for Determining Scenario Graph Equivalence] In the above procedure, it is necessary to determine whether or not the scenario graphs before and after removing the selected synchronization instruction are equivalent. Such a counting trace is used.
The counting trace is information indicating which operation is performed in the scenario and how many times, and the operation having the dependency is performed. Here, the counting trace ct (θ) of a given scenario θ is defined as follows. ct (θ) = (<set of action occurrence counters>, <set of precedence constraints>) In this definition, the action occurrence counter is an item that indicates how many times the action has occurred in the scenario. For example, an expression such as (a, k) means that the operation a has occurred k times in the scenario θ. The precedence constraint indicates when an operation having a dependency has occurred.
For example, the concurrent program C is executed in the order of operations a → b → c → b → a, and a scenario θ = abc representing this execution order
If the set of dependencies D (C) includes the dependencies (a, c) with respect to ba, the counting trace of θ is ct (θ) = ({(a, 2), (b, 2 ), (c, 1)}, {c (θ, 1) << c (θ,
3), c (θ, 3) << c (θ, 5)}). In this example, the set of operation occurrence counters {(a, 2), (b, 2), (c, 1)} is such that in scenario θ = abcba, operation a is twice and operation b is 2
Times, the action c has occurred once, and the first preceding constraint c (θ, 1) << c (θ, 3) corresponds to the scenario θ
, Means that two actions a and c having a dependency have occurred as the first and third actions, respectively, and the second preceding constraint c (θ, 3) << c (θ,
5) means that the operations c and a have occurred as the third and fifth operations, respectively.

A set of such counting traces is referred to as a counting trace set, and in the acyclic scenario graph SG, the counting traces are set.
Ctset (SG) is defined as follows. ctset (SG) = {ct (θ) | θ is an SG scenario} This definition means that a counting trace set ctset (SG) based on the scenario graph SG is a counting trace ct of all scenarios θ in the scenario graph SG.
(Θ). Since an arbitrary scenario is finite in the acyclic scenario graph SG, the scenario graph SG can be regarded as a concurrent program C, and ctset (C) can be calculated. Here, the acyclic scenario graph SG
1 and SG2, the following property is established between the scenario graph equivalent and the counting trace set. SG1 === SG2 iff ctset (C1) = ctset (C2) This is a counting trace set ctset based on each of two scenario graphs SG1 and SG2.
If (C1) and ctset (C2) are the same, it means that the two scenario graphs SG1 and SG2 are equivalent.

[3-2-4. Procedure for Efficiently Removing Redundant Synchronous Instructions] A procedure for efficiently removing redundant synchronous instructions by applying the above-described method for determining scenario graph equivalence is described below. In this case, the async block SGn in which the synchronization command sync (s1) is inserted between the operations t1 and t2 having the dependency relationship (FIG. 9)
It is assumed that redundant synchronization instructions are removed from (a)). First, SGn is projected onto processes P1 and P2. Note that the projected process can be regarded as a concurrent program Cn. First, FIG. 10 shows a procedure for efficiently removing redundant synchronization instructions. [3-2-4-1. Insertion of Dummy Operation] In the procedure shown in FIG. 10, first, a dummy operation nsync (Pi, ID) is inserted in one-to-one correspondence with each synchronization instruction sync (ID) inserted in each process Pi ( Step 10
1). The dummy operation is an instruction that does not synchronize with a synchronous instruction that is a synchronous instruction, in other words, an operation that releases synchronization by the synchronous instruction. Such a dummy operation is realized, for example, by inserting an instruction for selectively jumping immediately after the synchronization instruction immediately before the synchronization instruction. For example, in the scenario graph shown in FIG. 9A, when the processes are assigned to the processes P1 and P2 and parallelized, the synchronization instruction sync (s1) is skipped immediately before the synchronization instruction sync (s1). Immediately after the dummy operation nsync (P1, s1) and ns
nc (P2, s1) is inserted into each process (FIG. 9)
(B)). A scenario graph in which such a dummy operation is inserted is defined as SGe. All the dummy operations inserted in this way are recorded in a recording set ANS (step 102).

[3-2-4-2. Generation of State Space] Next, the scenario graph SGe into which the dummy operation has been inserted as described above is regarded as a concurrent program Ce, and the state space SS (C
e) is generated (step 103 / FIG. 9 (c)). Here, for the concurrent program C, the state space SS (C) is a state transition graph SS (C) = (S,
T, δ, m0). S is a set of global states of C. T is a set of instructions of C. δ is a state transition relation. That is, the element (m, t, m ′) of the state transition relation δ means that when the instruction t is executed in the global state m, the state becomes the global state m ′.
m0 is the initial global state of C. Note that the scenario graph SG = (S, A, δ ′, s0) is the state space SS (C) of the concurrent program C = (S, A,
δ, s0). That is, δ ′ is a subset of δ.

[3-2-4-3. Detection of Violation Path] Subsequently, a violation path θ that generates a counting trace ct (θ) not included in the counting trace set ctset (Cn) from the generated state space SS (Ce), that is, violates the preceding constraint or deadlocks. Is detected (step 104). In FIG. 9C,
The violation path θ is indicated by a thick line and a cross. Note that ctset
(Cn) is a set of counting traces corresponding to the scenario graph before the dummy operation is inserted, and is created when the violation path θ is detected, or created and stored before that.

When the violation path θ is detected (step 1)
05), the dummy path nsync (Pi, Pi,
ID) (step 106 / FIG. 9 (c)). That is, the violation path θ is the dummy operation nsync (Pi, I
Since it is considered that this occurred due to the insertion of D), it can be determined that the synchronization instruction sync (ID) is indispensable and not redundant. In the example of FIG. 9C, the operation ns21
Has been detected as a dummy operation that has caused a deviation from the correct operation.

The dummy operation detected in this way is added to the recording set DNS (step 107). Also,
After removing the dummy operation from the scenario graph SGe (step 108), the state space SS (Ce) is generated again, or a part of the state space starting from the dummy operation is pruned. Then, the procedure from the detection of the violation path θ is repeated again, and when the violation path θ is no longer detected (step 105), the procedure proceeds to the following procedures.

[3-2-4-4. Judgment of Redundancy] When the violation path θ is no longer detected, all the dummy operations detected so far are included in the set DNS. As a result, from the set ANS of all the inserted dummy operations,
ANS-D excluding the set of detected dummy operations DNS
NS is a set of dummy operations that have been inserted but have not generated a violation path. Even if the synchronization command corresponding to such a dummy operation is actually deleted, it does not affect the counting trace set of the scenario graph.

Therefore, the dummy operation nsync (P
i, ID) is included in the ANS-DNS, the synchronization instruction sync (ID) inserted in the process Pi
Since is redundant, it is removed from the scenario graph (step 109). It is assumed that the concurrent program Co is finally obtained by removing all redundant synchronization instructions from the concurrent program Cn. At this time, a concurrent program Cn holding all the inserted synchronous instructions,
Since the concurrent programs Co from which redundant synchronization instructions have been removed have a common counting trace set, they are equivalent to a scenario graph, and satisfy SS (Co) === SS (Cn).

[3-3. Detailed procedure for integration]
The scenarios parallelized for each block of the decomposed hierarchy are integrated into one scenario for each process.

[3-3-1. [Embedment of Blocks] At the time of integration, first, details of blocks in a lower hierarchy are embedded in an upper hierarchy. For example, if B1 = a1 (B2 | P1) a2 ‖ b1 (B2 | P2) b2 B2 = a3 ‖ b3, and substituting B2 | P1 = a3 and B2 | P2 = b3 for the lower-level blocks, = a1 a3 a2 ‖b1 b3 b2.

[3-3-2. Next, a loop for a block is defined as a loop of each process inside the block. For example, (a‖b) * → a * ‖b *.

[4. Specific Example] Hereinafter, a specific example in which the present embodiment is applied to a concurrent program will be described with reference to each step of the flowchart shown in FIG. The target here is a shared variable type concurrent program C,
This concurrent program C has at least two processes P
1, P2, and read and write two shared variables m1 and m2 using a shared memory.

[4-1. Creation of Concurrent Program] In this specific example, it is assumed that a concurrent program C = P1‖P2 has been created (step 1). The set D (C) of dependencies between instructions of the program includes a dependency (a2, b2) based on data dependency via the variable m1 and a dependency (a3, b3) based on data dependency via the variable m2. ) Is included.

M1 = 0; m2 = 0; P1: while (true) {a1: v11 = 1; a2: write (m1, v11); a3: v12 = read (m2);} P2: while (true) { b1: v21 = 2; b2: v22 = read (m1); b3: write (m2, v21);} [4-2. Creation of Scenario] From the parallel program C as described above, a scenario is created using the creating means 3 (step 2). Here, it is assumed that a scenario graph (FIG. 11A) in which a plurality of scenarios are put together has been created.

[4-3. Confirmation of Scenario Behavior] The user confirms that each scenario on the scenario graph is correct (step 3), and if there is a bug, returns to step 1 (step 4). Here, it is assumed that no bug is found in the scenario, and the scenario is decomposed (step 7) following the extraction of the dependency (step 6).

[4-4. Scenario Decomposition] In the scenario decomposition (step 6), the scenario graph is normalized and the hierarchical structure is extracted. That is, first, the following scenario converted into a regular expression is obtained by normalizing the scenario graph (FIG. 11A). Here, a * is "a
A + b means "execute a or b". SGr = (b1 (a1 a2 a3) * a1 (a2 b2 + b2 a2) b3 a3) * FIG. 11B shows a scenario graph in which the scenario converted into the regular expression is represented by an equivalent graph. The scenario (b1 (a1 a2 a3) * a1 (a2 b2 + b2 a2) b3 a3) * converted into a regular expression can be decomposed into blocks having the following hierarchical structure. Here, if B1 * and B2 * are regarded as one element, each block of each layer does not include a loop structure. SGr = B1 * B1 = b1 B2 * a1 (a2 b2 + b2 a2) b3 a3 B2 = a1 a2 a3 [4-5. Parallelization of Scenario] Subsequently, parallelization is performed in units of the blocks thus decomposed (step 8). In this example, the block B2 satisfies B2 = a1a2a3‖ε (ε denotes an empty sequence), and includes only the operation of the process P1, so that there is no need for parallelization. On the other hand, the block B1 is parallelized as follows. First, synchronization instructions s1, s2, s are stored in block B1.
3, s4, s5, and s6 are introduced. B1 = b1 B2 * s1 a1 (s2 a2 s3 b2 + s4 b2 s5 a2) b3 s6
a3 Subsequently, the block B1 into which the synchronization instructions s1 to s6 are inserted is projected onto the processes P1 and P2. B1 = (B2 | P1) * s1 a1 (s2 a2 s3 + s4 s5 a2) s6 a3 ‖ b1 (B2 | P2) * s1 (s2 s3 b2 + s4 b2 s5) b3 s6 Further remove redundant synchronization instructions. . Where (s2 a2 s
For 3 b2 + s4 b2 s5 a2), (s2 a2 s3 + s4 s5 a2) ‖ (s2 s3 b2 + s4 b2 s5) → a
It can be reduced to 2 ‖b2. That is, the synchronization instructions s2, s3, s
4, s5 are redundant and are therefore removed. As a result, the final regular expression of the block B1 is as follows. B1 = (B2 | P1) * s1 a1 a2 s6 a3 ‖b1 (B2 | P2) * s1 b2
b3 s6 [4-6. Integration of Scenarios] Next, the scenarios assigned to each process for each block are integrated.
In this integration, SGr = ((a1 a2 a3) * s1 a1 a2 s6 a3 ‖b1 s1 b2 b3 by embedding the contents of the lower block B2 into the block B1 of the upper layer.
s6) *. By expanding the loop, SGr = ((a1 a2 a3) * s1 a1 a2 s6 a3) * ‖ (b1 s1 b2 b
3 s6) *. A scenario finally generated by such integration is represented by a scenario graph as shown in FIG. Here, the regular expression represented as a graph as it is has some redundancy, and is partially optimized.

[4-7. Generation of second concurrent program]
Finally, the following concurrent program C = P1‖P2 is generated from the scenario graph shown in FIG.

P1: while (true) {a1: v11 = 1; s1: if (sync (1)) {a2: write (m1, v11); s2: sync (6); a3: v12 = read (m2) ;} else {a2: write (m1, v11); a3: v12 = read (m2);}} P2: while (true) {b1: v21 = 0; s1: sync (1); b2: write (m2, v21); b3: v22 = read (m1); s2: sync (6);} [5. Effects] As described above, in the present embodiment, the concurrent program is temporarily serialized in the form of a scenario that has been confirmed to be correct, and the concurrent program is re-created based on this scenario. Improve. At that time, the scenario is once hierarchically decomposed into blocks that do not include a loop. Then, each decomposed block is assigned to each process and parallelized,
Integrate again for each process to generate a concurrent program. For this reason, even a concurrent program having a complicated structure can be developed as easily as sequential programming by decomposing it into blocks and processing. Further, since each decomposed block does not include a loop or a hierarchical structure, it can be efficiently processed, and the entire concurrent program can be efficiently developed.

In particular, in the present embodiment, the scenario is converted into a regular expression by normalizing the scenario.
Scenarios converted into regular expressions can be easily decomposed hierarchically. For this reason, the decomposition of the concurrent program is made more efficient.

In this embodiment, the scenario is assigned to the process while embedding the synchronization instruction. Therefore, the execution timing of each part between the processes is controlled so as to conform to the preceding constraint based on the dependency, and finally obtained. The reliability of the concurrent program is ensured.

In the present embodiment, by removing redundant synchronization instructions, the degree of freedom in what timing the processes operate with each other is expanded. This means optimizing a concurrent program by giving harmless nondeterminism. Concurrency can be restored as much as possible in a concurrent program once serialized in the form of a scenario.

Further, in this embodiment, since the synchronous instruction which does not affect the execution order of the operation having the dependency is removed,
While the degree of freedom of the operation of the concurrent program is expanded, the execution order of the operation having the dependency is correctly maintained.

[6. Other Embodiments] The present invention is not limited to the above embodiments, but includes other embodiments as exemplified below. For example, as for the configuration of a computer used to realize the above-described embodiment, the configuration example shown in FIG. 1 is a multi-CPU, but the present invention may be realized on a computer system having another configuration. A parallel computer having a memory, a parallel computer having no shared memory, a distributed network computer system, a single CPU computer having a multitask system, and the like can be considered.

In the above-described embodiment, the dependency is extracted before the scenario is decomposed. However, the dependency may be extracted after the scenario is decomposed. In the above embodiment, the scenario graph is used as the scenario format. However, the scenario format is free, and a scenario in a desired format such as a text format or a flowchart format can be used. Further, the concurrent programs and scenarios shown in the above embodiments are merely examples, and the language, expression form, complexity, and the like to be used can be freely selected.

It is generally considered that the present invention is realized by software for realizing the operation of the present invention, but a recording medium on which such software is recorded is also one embodiment of the present invention.

[0088]

As described above, even a concurrent program having a complicated structure can be developed with excellent reliability and efficiency, so that the productivity and accuracy of programming are greatly improved.

[Brief description of the drawings]

FIG. 1 is a diagram illustrating a hardware configuration of a computer system used to implement an embodiment of the present invention;

FIG. 2 is a functional block diagram showing a configuration of an embodiment of the present invention.

FIG. 3 is a flowchart showing a processing procedure in the embodiment of the present invention.

FIG. 4 is a diagram showing an example of data dependence in the embodiment of the present invention.

FIG. 5 is a diagram illustrating an example of decomposition of a scenario in the embodiment of the present invention.

FIG. 6 is a diagram showing an example in which a synchronization instruction is inserted into a scenario and assigned to each process in the embodiment of the present invention.

FIG. 7 is a diagram showing another example in which a synchronization instruction is inserted into a scenario and assigned to each process in the embodiment of the present invention.

FIG. 8 is a diagram showing a state in which a synchronization instruction inserted into a scenario is removed as redundant in the embodiment of the present invention;

FIG. 9 is a diagram showing a state in which a dummy path is inserted into a scenario graph and a violation path occurs in the embodiment of the present invention;

FIG. 10 is a flowchart showing a procedure for efficiently removing a redundant synchronization instruction in the embodiment of the present invention.

FIG. 11 is a diagram showing a specific example according to the embodiment of the present invention.

[Explanation of symbols]

 1: Editing means 2: First parallel program 3: Creation means 4: Scenario information 5: Decomposition means 6: Structural scenario information 7: Parallelization means 8: Integration means 9: Local scenario information 10: Generation means 11: Second concurrent program 12: analysis means 13: analysis information 21: processor 22: I / O interface 23: shared memory 24: input device 25: output device 26: external storage device

Claims (10)

[Claims] Means for creating an execution scenario from a first concurrent program; means for extracting a dependency existing between parts of the first concurrent program by analyzing the first concurrent program; A means for hierarchically decomposing the scenario into blocks that do not include a loop; and a means for parallelizing by assigning the decomposed scenario to a plurality of processes in units of the block based on the dependency. A program development support device comprising: means for integrating a scenario assigned to each process for each process; and means for generating a second parallel program from the integrated scenario for each process. 2. The program development support device according to claim 1, wherein said decomposing means includes means for normalizing a given scenario. 3. The program development according to claim 1, wherein the parallelizing unit is configured to embed a synchronization instruction corresponding to the dependency in the scenario when assigning the scenario to a process. Support equipment. 4. The program development support device according to claim 3, wherein said parallelizing means is configured to remove a redundant synchronization instruction from among the synchronization instructions embedded in a scenario. 5. The parallelizing means, when removing the redundant synchronization instruction, suppresses an operation of an arbitrary synchronization instruction embedded in a scenario, and performs the operation between each scenario before and after the suppression. It is configured to judge whether or not the execution order that can be indicated by the operation having the dependency is the same, and if the execution order is the same, the synchronous instruction whose operation has been suppressed is removed. 4. The program development support device according to 4. 6. A program development method for supporting the development of a concurrent program using a scenario, comprising the step of determining whether two scenarios including a part having an interdependency are equivalent to each other; For each of two scenarios, a sub-step of calculating a set of counting traces indicating when said part with dependencies has been executed; and comparing the two sets calculated, two sets if the two sets are equal And a sub-step of determining that the scenarios are equivalent. 7. A step of creating an execution scenario from a first concurrent program; and a step of analyzing the first concurrent program to extract a dependency existing between parts of the first concurrent program. , Hierarchically decomposing the scenario into blocks that do not include loops, and parallelizing by assigning the decomposed scenario to a plurality of processes in units of the blocks based on the dependencies, A program development support method, comprising: integrating a scenario assigned to each process for each process; and generating a second concurrent program from the integrated scenario for each process. 8. The parallelizing step includes, when assigning a scenario to a process, a sub-step of embedding a synchronization instruction corresponding to the dependency in the scenario, and a redundant synchronization instruction among the synchronization instructions embedded in the scenario. The program development support method according to claim 7, further comprising: a removing step. 9. The removing sub-step suppresses an action of an arbitrary synchronization instruction embedded in a scenario, and an execution order in which an operation having the dependency relationship can be indicated between each scenario before and after the suppression. 9. The method according to claim 8, wherein it is determined whether are the same, and if the execution order is the same, the synchronous instruction whose operation is suppressed is removed. 10. A recording medium on which program development support software for supporting concurrent program development using a computer is recorded. The program development support software causes a computer to create an execution scenario from a first concurrent program. Analyzing the first concurrent program to extract dependencies existing between parts of the first concurrent program; decomposing the scenario hierarchically into blocks that do not include loops; Based on the above, the decomposed scenarios are parallelized by assigning the blocks to a plurality of processes in units of blocks, and the scenarios assigned to each process are integrated for each of the processes. From the integrated scenario for each process, It is special to generate a second concurrent program. A recording medium recording a program development support for software to be.