JP7454700B2 - Arithmetic device and inspection method - Google Patents

Description

The present disclosure relates to an arithmetic device and an inspection method.

In recent years, due to the multi-functionality of electronic devices, the amount of arithmetic processing performed by electronic devices has been increasing year by year.As a result, the performance of processors such as CPUs (Central Processing Units) installed in electronic devices has been improved. is desired.

For this reason, it is becoming increasingly common for electronic devices to be multi-core, by increasing the number of processors installed in the device or increasing the number of processor cores built into the processor.

In addition, in order to utilize multiple processor cores, parts that can be processed in parallel are extracted from a program for a single processor core, and a parallelized program that includes multiple programs to be executed on each processor core is created. Sometimes. In a parallelized program, each task of the original program is appropriately assigned to a plurality of processor cores.

In order to obtain the same execution results as the original program using a parallelized program, it is necessary to create a program that will be executed on each processor core, taking into account the dependencies of each task.

For example, if the computation results of one task are used by another task, you must write a program to run on each processor core such that the execution order of those tasks is the same as that of the original program. be.

Therefore, when inspecting the operation of a parallelized program, it may be checked whether the execution order of tasks having a dependency relationship is the same as the execution order of the original program.

On the other hand, Patent Document 1 describes the results when two tasks that can be executed simultaneously among a plurality of tasks assigned to each CPU core are exchanged and the execution order of those tasks is changed. A method is disclosed for checking a predetermined condition that causes a problem when the software and software are executed simultaneously.

Japanese Patent Application Publication No. 2018-151803

If tasks that can be executed simultaneously can be obtained and predetermined conditions can be determined between these tasks, it is possible to detect whether or not a predetermined violation occurs in a parallelized program.

However, in the prior art, it is very difficult to find tasks that can be executed simultaneously, and Patent Document 1 does not disclose a method for acquiring tasks that can be executed simultaneously.

In a parallelized program that is automatically parallelized, it is not obvious which tasks will be executed simultaneously, so the more complex the parallelized program becomes, the more difficult it becomes to obtain tasks that can be executed simultaneously.

An object of the present disclosure is to provide an algorithm that efficiently and automatically obtains the relationship between multiple tasks that constitute a parallelized program, and to determine a predetermined condition between the tasks, which can be used to inspect the operation of a parallelized program. An object of the present invention is to provide an arithmetic device and an inspection method that can reduce the load.

In order to achieve the above object, the present disclosure is configured as follows.

An inspection method for inspecting the operation of a parallelized program in which a program consisting of a plurality of tasks executed on each of a plurality of processor cores is parallelized, the inspection method comprising access information regarding access to resources shared by the plurality of tasks. and at least a first processing order of the plurality of tasks when the first condition is applied to the plurality of tasks, and a first processing order of the plurality of tasks that is different from the first condition. a second processing order of the plurality of tasks when applying the second condition, and accesses a resource shared by the plurality of tasks in the first processing order and the second processing order. A preceding task group consisting of tasks to be performed before the first task and a subsequent task group consisting of tasks to be performed after the first task are compared, and the task identified based on the comparison result is , detecting the presence or absence of a predetermined violation in the parallelized program using the access information.

An inspection method for inspecting the operation of a parallelized program in which a program consisting of a plurality of tasks executed by each of a plurality of processor cores is parallelized, the method comprising access information regarding access to the resource shared by the plurality of tasks. and obtain at least a first processing order of the plurality of tasks when the first condition is applied to the plurality of tasks, and a first processing order of the plurality of tasks that is different from the first condition. a second processing order of the plurality of tasks when applying the second condition, and accesses a resource shared by the plurality of tasks in the first processing order and the second processing order. A preceding task group consisting of tasks to be performed before the first task and a subsequent task group consisting of tasks to be performed after the first task are compared, and the task identified based on the comparison result is , detecting the presence or absence of a predetermined violation in the parallelized program using the access information.

According to the present disclosure, an algorithm is provided that efficiently automatically acquires the relationship between multiple tasks that constitute a parallelized program, and by determining a predetermined condition between tasks, it is possible to inspect the operation of a parallelized program. It is possible to provide an arithmetic device and an inspection method that can reduce the load.

FIG. 1 is a block diagram showing the configuration of a test device according to Example 1 of the present disclosure. FIG. 2 is a diagram illustrating an example of a functional configuration of a CPU 1200 realized by executing a program according to Example 1 of the present disclosure. FIG. 1 is a diagram showing a functional configuration of a test device according to Example 1 of the present disclosure. 2 is a flowchart for explaining an example of the operation of violation determination processing according to Example 1 of the present disclosure. 2 is a flowchart for explaining an example of the operation of access conflict analysis processing according to Example 1 of the present disclosure. FIG. 6 is a diagram for explaining forward order/reverse order, which is an example of a task acquisition process that can be executed simultaneously according to the first embodiment of the present disclosure. FIG. 2 is a flowchart for explaining an example of the operation of the preceding/succeeding task acquisition process according to the first embodiment of the present disclosure. FIG. FIG. 2 is a diagram for explaining an all-priority scheduler that is an example of a scheduler according to Example 1 of the present disclosure. FIG. 2 is a diagram for explaining an example of a task acquisition process that can be executed simultaneously according to the first embodiment of the present disclosure. FIG. 3 is a diagram for explaining the latest one which is an example of the concurrently executable task acquisition processing according to the first embodiment of the present disclosure. FIG. 2 is a diagram for explaining earliest/latest, which is an example of a task acquisition process that can be executed simultaneously according to Example 1 of the present disclosure. FIG. 2 is a diagram for explaining a slowest scheduler that is an example of a scheduler according to Example 1 of the present disclosure. FIG. 2 is a diagram for explaining an early scheduler that is an example of a scheduler according to Example 1 of the present disclosure. FIG. 3 is a diagram for explaining a specific example of dependency relationships of parallelized programs. FIG. 6 is a diagram for explaining a specific example of the execution order by the latest scheduler. FIG. 3 is a diagram for explaining a specific example of a preceding task group and a succeeding task group. FIG. 3 is a diagram showing a preceding task group and a succeeding task group in the form of a valve diagram. FIG. 4 is a diagram for explaining specific examples of tasks that always precede, tasks that can be executed simultaneously, and tasks that always follow. FIG. 7 is a diagram for explaining a specific example of an execution order by a scheduler with all priorities. FIG. 3 is a diagram showing a functional configuration of a test device according to Example 2 of the present disclosure. 12 is a flowchart for explaining an example of the operation of violation determination processing according to Example 2 of the present disclosure. 12 is a flowchart for explaining an example of the operation of access order analysis processing according to Example 2 of the present disclosure. 12 is a flowchart for explaining an example of the operation of the preceding/succeeding task acquisition process according to the second embodiment of the present disclosure. FIG. 7 is a diagram for explaining an example of a task acquisition process that can be executed simultaneously according to a second embodiment of the present disclosure; FIG. 12 is a diagram for explaining the latest example of the concurrently executable task acquisition processing according to the second embodiment of the present disclosure. FIG. 12 is a diagram for explaining earliest/latest, which is an example of a concurrently executable task acquisition process according to Example 2 of the present disclosure.

Embodiments of the present disclosure will be described below with reference to the drawings. The present disclosure is an arithmetic device and a testing device that test the operation of a parallelized program that is a parallelized program made up of a plurality of tasks executed by each of a plurality of processor cores.

(Example 1)
First, Example 1 will be described using FIGS. 1 to 18.

FIG. 1 is a block diagram showing a schematic configuration of a test device 1000 according to Example 1 of the present disclosure.

In FIG. 1, a test device 1000 is an arithmetic device that executes a test process to test the operation of a parallelized program that is a program for multiple processor cores. The parallelization program may be generated using a predetermined tool or the like from a single-core program that is a program for a single processor core. The parallelized program includes multiple individual programs that are executed on each of multiple processor cores.

Test device 1000 includes memory 1100 and CPU 1200. Memory 1100 and CPU 1200 are interconnected via an internal bus, an adapter, or the like.

The memory 1100 stores resources shared by multiple tasks and parallel programs. That is, the memory 1100 is a storage unit that stores various information including various programs that define the operations of the CPU 1200. The CPU 1200 is a control unit that operates based on a parallelization program. The CPU 1200 detects (inspects) the presence or absence of a predetermined violation in the parallel program according to the program described below.

In the first embodiment, the memory 1100 stores an emulator 1101, a violation inspection program 1102, a core0 program 1103, a core1 program 1104, and a core2 program 1105. The memory 1100 further stores violation information 1106, variable access information 1107, task group information 1108, execution order information 1109, selected core information 1110, and synchronization flag 1111. The variable access information 1107 also includes variables such as global variables, and these variables are resources shared by multiple tasks.

The emulator 1101 is a program for virtually realizing a plurality of processor cores that execute individual programs of the parallelization program. In the first embodiment, three CPU cores (virtual CPU core 0, virtual CPU core 1, and virtual CPU core 2) are virtually realized as the plurality of processor cores.

The violation check program 1102 is a program for checking a parallelized program in the emulator 1101 to see whether the program satisfies a predetermined condition. The task execution order required at that time is obtained by using the realized virtual CPU core 0, virtual CPU core 1, and virtual CPU core 2 as processor cores that execute the parallelized program.

In the following, for convenience, programs and tasks may be described as the operating entities of each process, but the actual operating entity of each process is the CPU 1200, which is a control unit.

The core 0 program 1103, the core 1 program 1104, and the core 2 program 1105 constitute a parallel program to be inspected in the inspection process. The program 1103 for core0, the program 1104 for core1, and the program 1105 for core2 are individually realized by virtual CPU core 0, virtual CPU core 1, and virtual CPU core 2, respectively.

Violation information 1106 indicates information such as whether the parallelization program satisfies a predetermined condition.

Variable access information 1107 indicates information on variables accessed by each of the core programs 1103 to 1105.

The task group information 1108 shows a list in which certain tasks or processes are grouped by states that other tasks or processes can take.

Execution order information 1109 indicates the order in which tasks or processes were executed.

The selected core information 1110 is management information used to manage processor cores in execution order acquisition (scheduling) processing, and in the first embodiment, indicates processor cores that are being selected and have been selected in inspection processing.

The synchronization flag 1111 is constraint information for defining constraints regarding the execution order of each task of the parallelized program. Specifically, the synchronization flag 1111 indicates whether or not a dependent task that is dependent on another task among each task of the parallelized program can be executed.

A dependent task is a task that has execution order constraints with respect to the dependent task, such as using the calculation result of the dependent task. Note that there may be a plurality of synchronization flags 1111.

FIG. 2 is a diagram illustrating an example of the functional configuration of CPU 1200 that is realized by executing a program.

As shown in FIG. 2, virtual CPU core 0, virtual CPU core 1, and virtual CPU core 2 are virtually realized in emulator 1101. The core0 program 1103, the core1 program 1104, and the core2 program 1105 are created here from single-core programs including tasks T1 to T10 so that parallel processing can be performed by three processor cores.

The core0 program 1103 is an individual program that causes the virtual CPU core 0 to execute tasks T1, T2, T6, and T7. Tasks T3, T4, and T5 of the core1 program 1104 and tasks T8, T9, and T10 of the core2 program 1105 are similarly executed by their respective virtual CPUs.

Flag A is a synchronization flag for controlling so that task T3 (a dependent task dependent on task T1) is not started until task T1 is completed. Flag A is set by task T1. Task T3 waits until flag A is set by task T1.

Note that setting the flag to a state indicating executable is called "setting a flag," and waiting until the flag becomes a state indicating executable is called "waiting to set." Similarly, flag B controls the dependency relationship between task T7 and task T4, and flag C controls the dependency relationship between task T4 and task T8.

The violation inspection system performs an inspection process that sequentially executes tasks T1 to T10 according to priority conditions while satisfying the constraints regarding the execution order of each task T1 to T10 defined by the synchronization flag 1111. It is checked whether the constraints regarding the execution order of each task of the core1 program 1104 and the core2 program 1105, that is, the dependency relationship of each task, are equal to those of the original single-core program.

When we focus on a certain task, we determine which tasks must be ordered in a certain order and which tasks can be executed simultaneously.

Therefore, by focusing on all cores, all tasks that can be executed simultaneously can be extracted.

For example, focusing on task T4, tasks T2, T6, T9, and T10 are tasks that can be executed simultaneously. Other tasks are tasks whose order is always determined.

In the first embodiment, variable access is performed under predetermined conditions (for example, whether a read or write operation is being performed on the same variable (shared resource) in concurrently executable tasks executed on different cores. A parallel program is checked for violations by determining whether there is a conflict between operations or write operations (provided that there must be a conflict between at least one write operation).

A violation inspection system 3101 shown in FIG. 3 is an inspection system that inspects conflicts. The violation inspection system 3101 includes a violation determination process 3102, an access conflict analysis process 3103, a concurrently executable task acquisition process 3104, a preceding/successive task group acquisition process 3105, and a scheduler (execution order acquisition process) 3106. be done.

The violation determination process 3102 is a process for determining whether or not there is a violation in the entire program. In the first embodiment, conflicts are checked.

The access conflict analysis process 3103 determines that a certain variable will not be accessed simultaneously by multiple tasks, and returns the result to the violation determination process 3102. A certain variable is all variables that are being written in a task (hereinafter referred to as a reference task) received from the violation determination process 3102.

The concurrently executable task acquisition process 3104 acquires the reference task and tasks that can be executed simultaneously (concurrently executable tasks) received from the access conflict analysis process 3103 and returns them to the access conflict analysis process 3103.

The preceding/succeeding task group acquisition process 3105 acquires a list of task groups that operated before the reference task and a list of task groups that operated after the reference task in various execution orders, and performs the concurrently executable task acquisition process 3104. Return to.

Note that the various execution orders are based on execution order conditions received from the concurrently executable task acquisition processing 3104.

The scheduler (execution order acquisition process) 3106 is a process that acquires the execution order according to the execution order condition received from the preceding and succeeding task group acquiring process 3105, and returns it to the preceding and succeeding task group acquiring process 3105.

FIG. 4 is a flowchart showing an example of the content of the violation determination process 3102 of FIG.

The violation inspection system 3101 sequentially inspects all the tasks constituting the parallelized program in a loop 4100.

In a loop 4100, the violation inspection system 3101 determines whether or not there is a Write process to a shared (global) variable in the selected task. If there is a Write process to the shared (global) variable (Yes), a flag is set.

Note that even if a pointer variable is declared locally, if the pointer is in the global area, it is treated as a global variable (step 4101).

The violation inspection system 3101 is a subflow that inspects access conflicts for a reference task. Details of step 4102 will be explained with reference to FIG.

If the result of step 4102 is OK, the violation inspection system 3101 continues the loop 4100 without doing anything, and if the result is NG, it executes step 4104 (step 4104).

The violation inspection system 3101 stores the presence of a violation in the violation information 1106 in FIG. 1, and terminates the program.

FIG. 5 is a flowchart for determining the presence or absence of variable access conflict, and is a subflow of access conflict analysis in step 4102 of FIG. Note that the flowchart shown in FIG. 5 corresponds to the operation of the access conflict analysis process 3103 in FIG. 3.

The access conflict analysis process 3103 acquires tasks that can be executed simultaneously with the reference task received from the violation determination process 3102 from the concurrently executable task process 3104 (step 5101).

The access conflict analysis process 3103 examines access conflicts (step 5102). That is, for the task group acquired in step 5101, it is determined whether there is R/W for at least one of the inter-core shared variables written by the task.

For all the shared variables that are being written in the standard task, a task that can be executed concurrently with the standard task searches for the presence or absence of Read or Write to the shared variables, and writes the command to at least one shared variable among all the shared variables. If one Read or Write is detected, step 5103 is executed.

On the other hand, in a task that can be executed simultaneously with the reference task, if no Read or Write is found for all the relevant shared variables, the process is ended and the process returns to the flow of FIG. 4.

The violation determination program 3101 is a flow executed when there is an access conflict, and returns a violation to the flow of FIG. 4 (step 5103). Note that the violation location is changed to be stored in the violation information 1106 of the memory 1100. Violation locations can be output to an appropriate output device such as a display. This is useful information when modifying your code.

FIG. 6 is a flowchart showing an example of the contents of the concurrently executable task acquisition processing 3104 shown in FIG. The flowchart shown in FIG. A second condition is used in which a priority order opposite to the first condition is assigned to each of core 0, virtual CPU core 1, and virtual CPU core 2.

When the first condition is applied to multiple tasks, the processing order of multiple tasks is set as the first processing order, and the second condition, which is different from the first condition, is applied to multiple tasks. The processing order of the plurality of tasks will be referred to as the second processing order (the same applies in the following description).

The flowchart shown in FIG. 6 acquires tasks that can be executed concurrently with the reference task received from the access conflict analysis processing 3103 from two execution orders: forward order and reverse order.

The violation inspection system 3101 initializes (empties the list of) a preceding task group that stores tasks executed before the standard task and a subsequent task group that stores tasks that were executed after the standard task in multiple execution orders. ) (step 6101).

When acquiring the execution order, the violation inspection system 3101 sets a policy for the execution order acquisition process (step 6102). In the first embodiment, a policy is set in which two lists are set, one in forward order and one in reverse order.

In normal order, execution priority is set for each core for all tasks. For example, virtual CPU core 0 is given first priority, virtual CPU core 1 is given second priority, and so on.

The reverse order is the reversal of the execution priority set in the normal order. In the execution order acquisition process, tasks belonging to virtual CPU core 0 with first priority are scheduled to be executed as far as possible before tasks belonging to cores with second or lower priority.

The violation inspection system 3101 acquires information from the execution order in a loop 6103 for all policies set in step 6102. In the first embodiment, the number of loops is two.

The violation inspection system 3101 is a process for acquiring preceding/successive task groups, and distributes each task into a preceding task group and a succeeding task group based on the execution order (step 6104).

The violation inspection system 3101 takes the set union of the predecessor task group and the successor task group, and returns the list to the flow in Figure 5 as tasks that can be executed simultaneously (step 6105). In other words, it takes the AND of the predecessor task group and the successor task group, and returns this list to the flow in Figure 5. Tasks that can be executed simultaneously have an indefinite order (they can be swapped) with respect to the reference task, so they are included in both the predecessor task group and the successor task group, and by taking the set union, it is possible to obtain the tasks that can be executed simultaneously.

FIG. 7 is a flowchart showing an example of the contents of the preceding/task group acquisition processing 3105 in FIG.

In FIG. 7, step 7101 is a branching process that selects a scheduler (earliest scheduler, latest scheduler, forward/reverse scheduler) to be used for obtaining the execution order.
In step 7102, the violation checking system 3101 selects the earliest scheduler that performs the earliest scheduling to execute a certain core.

In step 7103, the violation checking system 3101 selects the slowest scheduler that implements the slowest scheduling that executes a certain core the slowest.

In step 7104, the violation inspection system 3101 selects an all-priority scheduler that performs prioritized scheduling in which all cores are given priority and executed.

In step 7105, the violation inspection system 3101 obtains the execution order with the selected scheduler.

The violation inspection system 3101 adds a task to be executed before the reference task in the execution order obtained in step 7105 to the preceding task group (step 7106).

Note that when step 7106 is executed for the second time or later, the task is added to the preceding task group while being ORed with the task already present.

The violation inspection system 3101 adds a task to be executed after the reference task in the execution order obtained in step 7105 to the subsequent task group (step 7107).

Note that when step 7107 is executed for the second time or later, the task is added to the subsequent task group while being ORed with the task that already exists.

FIG. 8 is a flowchart for explaining an example of an execution order acquisition process when the all-priority scheduler set in step 7104 of FIG. 7 is executed in step 7105. The flowchart shown in FIG. 8 corresponds to the operation of the scheduler 3106 in FIG. 3.

In step 8101, the violation inspection system 3101 selects the processor core with the highest priority as the target processor core. In step 8102, the violation inspection system 3101 determines whether the selected target processor core is executable. If the target processor core is not executable, the process of step 8103 is executed. If the target processor core is executable, step 8104 is executed.

In step 8103, the violation inspection system 3101 selects the processor core with the next highest priority after the currently selected target processor core as the target processor core, and returns to the processing in step 8102.

In step 8104, the violation inspection system 3101 instructs the target processor core to execute the task, and adds the executed task to the end of the execution order list in the execution order information 1109.

In step 8105, the violation inspection system 3101 determines whether the target processor core that executed the task has set the flag.

If the target processor core sets the flag, the process returns to step 8101. On the other hand, if the target processor core does not set the flag, the process of step 8106 is executed.

At step 8106, the violation checking system determines whether all tasks of all processor cores have finished. If all the tasks have not been completed, the process returns to step 8102, and if all the tasks have been completed, the process is ended.

Through the above operations, it is possible to execute tasks on each processor core according to the priority set in step 6102 of FIG. 6 and obtain the execution order. Furthermore, if any of the processor cores sets the flag (step 4101: Yes), there is a possibility that a processor core with a higher priority than that processor core can execute the task, so the process returns to step 8101. ing.

Modification 1 of Example 1 will be described using FIG. 9. Unlike FIG. 6, FIG. 9 uses the execution order of several cores in which all cores are set once at the earliest to obtain tasks that can be executed simultaneously with the reference task. The difference from FIG. 6 is that step 9102 is different from step 6102, and step 9102 is different from step 6103.

In the operation of the flowchart shown in FIG. 9, the first condition is that one of the plurality of processor cores (virtual CPU core 0, virtual CPU core 1, virtual CPU core 2) is This is the earliest condition to be executed with priority, and the second condition is a condition in which processor cores other than the one processor core mentioned above are set as the earliest condition once.

The violation inspection system 3101 sets a condition for all cores to execute a certain core at the earliest (tasks executed on the selected core precede tasks executed on other cores as much as possible). Adapted execution conditions for the number of cores are set (step 9102).

In a loop 9103, the violation inspection system 3101 obtains information from the execution order for all policies set in step 9102. In the first modification of the first embodiment, the number of loops is the same as the number of cores.

Modification 2 of Example 1 will be described using FIG. 10. The example of FIG. 10 differs from the example of FIG. 6 in that a task that can be executed simultaneously with the reference task is obtained using the execution order of several cores in which all cores are set to the slowest once each. The difference from FIG. 6 is that step 10102 is different from step 6102, and step 10102 is different from step 6103.

The violation inspection system 3101 sets a condition for all cores to execute a certain core at the latest (tasks executed by other cores precede tasks executed by the selected core as much as possible). Adapted execution conditions for the number of cores are set (step 10102).

In a loop 10103, the violation inspection system 3101 obtains information from the execution order for all policies set in step 10102. In the second modification of the first embodiment, the number of loops is the same as the number of cores.

Modification 3 of Example 1 will be described using FIG. 11. In FIG. 11, unlike FIG. 6, tasks that can be executed simultaneously with the reference task are obtained using two execution orders set to the earliest and the latest to which the core to which the reference task belongs. The difference from FIG. 6 is that step 11102 is different from step 6102.

In the flowchart shown in FIG. 11, the first condition is to give priority to one processor core of multiple processor cores (virtual CPU core 0, virtual CPU core 1, virtual CPU core 2) over other processor cores. The second condition is to give priority to other processor cores for one processor core of multiple processor cores (virtual CPU core 0, virtual CPU core 1, virtual CPU core 2). This is the latest condition to execute.

The violation inspection system 3101 sets two execution conditions: a condition that the core to which the reference task belongs is the earliest to execute, and a condition that the core to which the reference task belongs is the latest to execute (step 10102).

FIG. 12 is a diagram for explaining an example of the task execution process in step 7103 in FIG. The task execution process in FIG. 12 is a slowest scheduler that obtains the execution order under the slowest priority condition that gives the target processor core a lower priority than all other processor cores.

The latest condition means that the target processor core executes the task as late as possible. More specifically, the slowest condition means that if other processor cores can execute the task, the other processor cores execute the task, and if no other processor cores can execute the task, the target processor core executes the task. This is the condition for executing. A processor core that can execute a task is a processor core that has an assigned task that has not been executed yet, and that is not waiting to be set for the next task to be executed.

In step S201, in the task execution process (latest scheduling), the violation inspection system 3101 first determines whether there is another processor core that can execute the task. At this time, the violation inspection system 3101 causes the target processor core to execute the task until it is no longer capable of executing the task.

Note that the other processor cores are processor cores other than the currently selected target processor core.

In step S202, if there is another processor core that can execute the task, the violation inspection system 3101 instructs the other processor core that can execute the task to execute the task, The process returns to step S201.

In step S203, if there is no other processor core that can execute the task, the violation inspection system 3101 instructs the selected target processor core to execute the task. At this time, the violation inspection system 3101 causes the target processor core to execute tasks until the target processor core sets a flag, waits for setting, or finishes all tasks.

In step S204, the violation inspection system 3101 determines whether all tasks of all processor cores have been completed. If all tasks have not been completed, the violation inspection system 3101 returns to step S201, and if all tasks have been completed, the violation inspection system 3101 ends the process.

FIG. 13 is a diagram for explaining another example of the task execution process in step 7102 in FIG. The task execution process in FIG. 13 is an earliest scheduler that obtains the execution order under the earliest condition that gives the target processor core a higher priority than all other processor cores.

The earliest condition means that the target processor core executes the task as soon as possible. The earliest condition is, more specifically, if the target processor core is capable of executing the task, cause the target processor core to execute the task, and if the target processor core is not capable of executing the task, cause other processor cores to execute the task. It is a condition.

In the task execution process (early scheduling), the violation inspection system 3101 first determines whether the selected target processor core is capable of executing the task (step S301).

If the target processor core is capable of executing the task, the violation inspection system 3101 instructs the target processor core to execute the task (step S302), and returns to the process of step S301. At this time, the violation inspection system 3101 causes the target processor core to execute the task until it is no longer capable of executing the task.

If the target processor core is not capable of executing the task, the violation inspection system 3101 searches for a processor core that sets the set wait flag of the target processor core (step S303).

The violation inspection system 3101 determines whether the searched processor core is waiting to be set (step S304).

If the searched processor core is set waiting, the violation inspection system 3101 searches for a processor core that sets the set waiting flag of the searched processor core (step S305), and returns to the process of step S304.

Note that in step S304, it is determined whether or not the last selected processor core is waiting to be set.

If the searched processor core is not waiting to be set, the violation inspection system 3101 instructs the searched processor core to execute a task and causes it to execute one task (step S306).

The violation inspection system 3101 determines whether all tasks of all processor cores have been completed (step S307). If all tasks have not been completed, the violation inspection system 3101 returns to step S301, and if all tasks have been completed, the violation inspection system 3101 ends the process.

Note that in the above operation, if the target processor core finishes the assigned task in step S302, in step S303, the violation inspection system 3101 searches for a processor core that sets the set waiting flag of the target processor core. Then, an executable processor core is searched among other processor cores.

In the first embodiment, tasks that can be executed simultaneously are obtained by comparing execution orders obtained by applying a plurality of conditions. Specifically, the order relationship among the plurality of execution orders appears as two task pairs in which the order relationship is switched in at least one combination of execution orders.

By confirming that there is no Read-Write or Write-Write access to any variable in all combinations of concurrently executable tasks obtained based on this principle, the program can It can be shown that no conflicts can occur throughout. In other words, it can be shown that data conflicts do not occur in any case.

Below, the above-mentioned principle and the operation of the above-mentioned flow will be explained regarding Modification 2.

FIG. 14A is a graph model of a parallelized program composed of tasks A to H. In a graph model, tasks are represented as nodes, and dependencies between tasks are represented as edges. A relationship exists between a task α that is connected to the start point of an edge and a task β that is connected to the end point of an edge, such that the task β must be executed after the completion of the execution of the task α.

In FIG. 14A, tasks A, B, G, and H are executed on core0, tasks C and E are executed on core1, and tasks D and F are executed on core2.

What is particularly important in parallel programs is the dependency relationship between cores. There are inter-core dependencies from task A to tasks C and D, from task C to task F, from task E to task G, and from task F to H.

Therefore, these tasks have an ordering constraint: one is always executed first, and the other is always executed after.

On the other hand, tasks without dependencies are tasks that can be executed simultaneously. These tasks have no order constraints and may be performed in reverse order or simultaneously. For example, tasks E and F have no dependency on each other and can be executed simultaneously.

FIG. 14B is a diagram showing the execution order with each core being the slowest.

In FIG. 14B, focusing on tasks E and F, the execution order in which core1 is the slowest and the execution order in which core2 is the slowest are compared. When core1 is the slowest, tasks F to E are executed, and when core2 is slowest, tasks E to F are executed, and it can be seen that the two tasks can be executed simultaneously.

In the latest scheduling that imposes the latest, there is a constraint that the tasks included in the other cores are executed as far in advance as possible of the tasks included in the core specified as the latest. When core1 is the slowest, task F (core2) is controlled to operate before task E (core1). When core2 is the slowest, task E (core1) is controlled to operate before task F (core2).

What is important here is that program dependencies are a stronger constraint than the constraint in the latest scheduling that imposes the latest. Therefore, the latest scheduling does not perform execution control that ignores program dependencies.

This makes it possible to guarantee that only tasks that can be executed simultaneously will be reordered in multiple execution orders.

FIG. 15 is a diagram showing an example of a preceding task group and a succeeding task group. In FIG. 15, tasks executed before task F are added to the preceding task group, and tasks executed after task F are added to the succeeding task group, using task F as a reference.

FIG. 16 shows tasks A, D, and C, which always precede reference task F, and tasks B, E, which can be executed simultaneously, from the preceding task group and succeeding task group shown in FIG. 15. , G, and a task H that always follows the reference task F, which is executed after the reference task F in any case.

Tasks A, D, and C, which always precede each other, are the complement of the succeeding task group in the preceding task group. Tasks B, E, and G that can be executed simultaneously are the product set of the preceding task group and the succeeding task group. The always successor task H is the complement of the predecessor task group in the successor task group.

FIG. 17 is a diagram showing tasks A, C, and D that always precede task F, tasks B, E, and G that can be executed simultaneously, and task H that always follows task F.

In this first embodiment, only tasks that can be executed concurrently are extracted from tasks that write to all shared variables, and it is checked whether there is any Read-Write conflict or Write-Write conflict to the shared variables among them. By checking, shared variable conflicts (data conflicts, atomic operation violations) can be detected, and if it can be shown that there are no such conflicts, it can be shown that the order of access to the shared variables is uniquely determined.

Therefore, according to the second modification of the first embodiment, it is possible to extract all concurrently executable tasks that are determined with respect to the reference task. Modifications 1 and 3 are also similar to Modification 2.

On the other hand, when using forward or descending order, tasks that can be executed simultaneously may be overlooked. FIG. 18 shows the example shown in FIG. 14A in forward order (first priority: core2, second priority: core0, third priority: core1), reverse order (first priority: core1, second priority: core0, third priority). It is a figure which shows the execution order scheduled with priority:core2). In FIG. 18, when F is a reference task (tasks that can be executed simultaneously are tasks B, E, and G), the order of tasks E and G is switched between normal and reverse order with respect to the reference task F. It can be seen that the order of task B has not been changed with respect to the reference task F, and that it is not possible to obtain all tasks that can be executed simultaneously.

In a case where this phenomenon occurs, there is a core that is set to have a lower priority than the core (the CPU core where the reference task F is located) that can execute the reference task concurrently, and the core that can execute the reference task at the same time A case may be considered in which the priority of a core that includes a task that transmits a synchronization flag (a core that is to be shut down (blocking core)) is lower than that of a core that includes tasks that can be executed concurrently with respect to a previous task.

Normally, the reference task should be executed before the concurrently executable tasks, but the blocking core prevents the concurrently executable tasks from executing. will be executed first.

Since the cutoff core has not issued a synchronization flag, the core is placed on standby and executes a task with a lower priority than the core. If a core to which a reference task and a task that can be executed concurrently belongs has a higher priority than a cutoff core, the concurrently executable task will be executed before the cutoff core issues a synchronization flag.

In Modification 1 or Modification 2, if the core containing the reference task is in the earliest or latest order, tasks that can be executed concurrently with the reference task are guaranteed to be executed after or before the reference task. .

When a core other than the core containing the reference task is the earliest or latest, the concurrently executable tasks included in the core set as the earliest or latest are always executed before or after the reference task. If all cores other than the core containing the standard task are set to the earliest or latest once and executed, tasks that can be executed simultaneously will always be executed before or after the standard task in some order.

Therefore, when the preceding task group and the succeeding task group are obtained from the execution order in which each core is set once to the latest, tasks that can be executed simultaneously are included in both groups. In other words, the set sum of both always includes tasks that can be executed simultaneously, which are determined for all the reference tasks.

Modification 3 can similarly extract all tasks that can be executed simultaneously and that are determined with respect to the reference task. When a core other than the core containing the reference task is the earliest or latest, the concurrently executable tasks included in the core set as the earliest or latest are always executed before or after the reference task. Therefore, even if the preceding task group and the succeeding task group are obtained from the execution order in which the reference task is set to be the earliest or the latest, tasks that can be executed simultaneously are included in both groups.

Furthermore, by executing the execution order only once under each condition and recording the result in the task group information 1108 of the memory 1100, it is possible to reduce the amount of calculation. In FIG. 7, if the scheduler has already generated an execution order that matches the specified conditions, this can be implemented by changing the scheduler to refer to it. In this case, the number of times the execution order is generated in Modifications 1 and 2 is the number of cores, and in Modification 3, it is the number of cores x 2 times.

According to the first embodiment of the present disclosure, all tasks that can be executed simultaneously can be extracted, so it is possible to determine whether or not there is a violation in the parallel program by making a determination based on a predetermined condition among these tasks. Accordingly, it is possible to provide an arithmetic device and a testing method that can reduce the load placed on testing the operation of a parallelized program.

In the present disclosure, the CPU 1200, which is a control unit, acquires access information regarding access to resources shared by a plurality of tasks T1 to T10, and applies a first condition to at least a plurality of tasks T1 to T10. The first processing order of the plurality of tasks T1 to T10 when the plurality of tasks T1 to T10 is The second processing order is determined.

In the first processing order and the second processing order, a preceding task group consisting of tasks performed before the first task that accesses resources shared by the plurality of tasks T1 to T10, and Compare with a subsequent task group consisting of tasks to be performed later. The presence or absence of a predetermined violation in the parallel program is detected using the access information for the task specified based on the comparison result.

(Example 2)
Example 2 of the present disclosure will be described below using FIGS. 19 to 25.

In the second embodiment, it is checked whether the execution order for a certain variable satisfies regulations by referring to tasks whose order is always determined.

In Example 2, the violation is that there is an access process to a shared resource that should not exist in each of the preceding task group and the succeeding task group. It is considered a violation if even one access process exists.

More specifically, it is possible to obtain the execution order of processes for a certain variable from the tasks that are always ordered (executed first or after), which are determined for tasks that include Write processing to a certain variable. Determine whether the order satisfies the specifications. The above determination is performed for all Write processing to a certain variable.

FIG. 19 is a schematic configuration diagram of a violation inspection system 19101 in Example 2 of the present disclosure.
A violation inspection system 19101 shown in FIG. 19 is an inspection system that inspects execution order violations. The violation inspection system 19101 shown in FIG. 19 has roughly the same configuration as the violation inspection system 3101 shown in FIG. 3. The parts that differ from the configuration shown in FIG. 3 are access order analysis processing 19103 and preceding/successive task acquisition processing 19104.

The access order analysis process 19103 confirms that a predetermined order constraint is satisfied for a certain process on a certain variable with respect to another process on the same variable, and returns the result to the violation determination process 19102. A certain variable is all the variables that are being written in the task (reference task) received from the violation determination process 19102.

The preceding/succeeding task acquisition processing 19104 obtains the preceding task group and the succeeding task group from the reference task received from the access order analysis processing 19103 and returns them to the access order analysis processing 19102.

FIG. 20 is a flowchart illustrating an example of the content of the violation determination process 19102 of FIG. 19. In the flowchart shown in FIG. 20, the contents of step 4102 in the flowchart shown in FIG. 4 are the contents of step 20102, and the contents of the other steps are the same as the flowchart shown in FIG. In step 20102, the violation inspection system 19101 is a subflow that inspects the execution order of a certain task (reference task). Details will be explained with reference to FIG.

FIG. 21 is a flowchart for analyzing the access order of variables and determining validity. Note that this corresponds to the operation of the access order analysis process 19103 in FIG.

The violation inspection system 19101 obtains tasks that always precede and always follow the reference task received through the process of the flowchart shown in FIG. 20 (step 21101).

The violation inspection system 19101 performs processing to determine whether there is an access order violation (violation of a predetermined order constraint). Regarding other processing of the same variable as the shared variable written in the task, the process that should come first is not in the subsequent task group, or the process that should be followed is not in the subsequent task group, and exists in the program. (Step 21102).

That is, the following two points are checked for all shared variables written in the standard task (step 21102).

It is confirmed that a process to be executed before the relevant process exists in any task and does not exist in the subsequent task group (condition C221).

It is confirmed that a process to be executed after the relevant process exists in any task and does not exist in the preceding task group (condition C222).

If the above conditions C221 and C222 are violated, step 21103 is executed. Otherwise, the process ends and returns to the flow of FIG. 20.

If condition C221 is satisfied, there is always a process that should be executed before the current process only in the preceding task. Therefore, when a program is executed, it is guaranteed that those processes are always executed before the current process.

If condition C222 is satisfied, there is always a process to be executed after the process in question only in subsequent tasks. Therefore, when a program is executed, it is guaranteed that those processes are always executed after the current process.

If the above conditions are satisfied for a write process of a certain variable, the program satisfies the execution order regulations for the certain variable. Furthermore, if the above conditions hold for all variables, the program satisfies the execution order requirements for all variables in any case.

In step 21103, the violation determination program is a flow executed when there is an access order violation, and returns a violation to the flow of FIG. 20.

FIG. 22 is a flowchart showing an example of the contents of the preceding/succeeding task acquisition processing 19104 shown in FIG. 19. The flowchart shown in FIG. 22 is a process for obtaining the preceding task group and the succeeding task group determined for the standard task received by the processing of the flowchart shown in FIG. 21 from two execution orders, forward order and reverse order. be.

Steps 22101 to 20104 in FIG. 22 are the same as steps 6101 to 6104 in FIG. 6.

In step 22105 of FIG. 22, the violation inspection system 19101 returns the preceding task group and the succeeding task group to the flow of FIG. 21.

Modification 1 of Example 2 will be described using FIG. 23. Unlike the flowchart shown in FIG. 22, the flowchart shown in FIG. 23 uses the execution order of several cores in which all cores are set once at the earliest, and executes the standard task received from the process of the flowchart shown in FIG. Obtain the preceding task group and subsequent task group determined for the task.

Steps 23101 to 23104 are the same as steps 9101 to 9104 in FIG. Step 23105 is the same as 22105 in FIG.

A second variant of the second embodiment will be described with reference to Figure 24. The flowchart shown in Figure 24 differs from the flowchart shown in Figure 22 in that it uses the execution order of several cores in which all cores have been set to the slowest once each to obtain the predecessor task group and the successor task group determined for the reference task received by the processing of the flowchart in Figure 21.

Steps 24101 to 24104 in FIG. 24 are the same as steps 10101 to 10104 in FIG. 10.

Step 24105 is the same as step 22105 in FIG.

Modification 3 of Example 2 will be described using the flowchart shown in FIG. 25. The flowchart shown in FIG. 25 differs from the flowchart shown in FIG. 22 in that the core to which the reference task belongs uses the two execution orders set as the earliest and the latest, and the reference task received through the processing of the flowchart in FIG. Obtain the preceding task group and successor task group determined for the task.

Steps 25101 to 25104 are the same as steps 11101 to 11104 in FIG. Step 25105 is the same as step 22105 in FIG.

According to the second embodiment of the present disclosure, since the configuration is configured to check whether the execution order for a certain variable satisfies the regulations by referring to the tasks whose order is always determined, it is possible to detect whether or not there is a violation in the parallelized program. It is possible to provide an arithmetic device and a testing method that can reduce the load placed on testing the operation of a parallelized program.

1000...Test device, 1100...Memory, 1101...Emulator, 1102...Violating program, 1103...Program for core0, 1104...Program for core1, 1105...Program for core2, 1106... Violation information, 1107... Variable access information, 1108... Task group information, 1109... Execution order information, 1110... Selected core information, 1111... Synchronization flag, 1200... CPU (control unit), 3101, 19101... Violation detection system, T1 to T10... Task

Claims (14)

An arithmetic device that inspects the operation of a parallelized program that parallelizes a program consisting of a plurality of tasks executed on each of a plurality of processor cores,
resources shared by the plurality of tasks and a memory that stores the parallelization program;
a control unit that operates based on the parallelization program;
Equipped with
The control unit acquires access information regarding access to the resource shared by the plurality of tasks, and at least obtains access information regarding access to the resource shared by the plurality of tasks, and at least a first condition of the plurality of tasks when a first condition is applied to the plurality of tasks. and a second processing order of the plurality of tasks when a second condition different from the first condition is applied to the plurality of tasks, and and in the second processing order, a preceding task group consisting of tasks performed before the first task that accesses the resource shared by the plurality of tasks, and a preceding task group consisting of tasks performed after the first task. and a subsequent task group, and detects whether or not a predetermined violation occurs in the parallelized program using the access information for the task identified based on the comparison result. . The arithmetic device according to claim 1,
The first condition is a condition for assigning an arbitrary execution priority order to each of the plurality of processor cores, and the second condition is a condition for assigning an arbitrary execution priority order to each of the plurality of processor cores, and the second condition is a condition for assigning an arbitrary execution priority order to each of the plurality of processor cores. An arithmetic device characterized by being a condition for allocating. The arithmetic device according to claim 1,
The first condition is the earliest condition for executing one processor core of the plurality of processor cores with priority over other processor cores, and the second condition is the earliest condition for executing one processor core of the plurality of processor cores with priority over other processor cores. An arithmetic device characterized in that the earliest condition is set once at a time. The arithmetic device according to claim 1,
The first condition is the slowest condition for executing one processor core of the plurality of processor cores with priority given to other processor cores, and the second condition is the slowest condition for executing one processor core of the plurality of processor cores with priority given to other processor cores, and the second condition is a An arithmetic device characterized in that each core is set to the slowest condition once. The arithmetic device according to claim 1,
The first condition is an earliest condition for executing one processor core of the plurality of processor cores with priority over other processor cores, and the second condition is an earliest condition for executing one of the plurality of processor cores with priority over other processor cores. An arithmetic device characterized in that the slowest condition is that one processor core executes with priority over other processor cores. The arithmetic device according to claim 1,
The predetermined violation occurs when at least one of the shared resources accessed by a task obtained by the set sum of the preceding task group and the succeeding task group has conflicting read or write operations for the same resource. An arithmetic device characterized in that a violation occurs when one or more of the following occurs. The arithmetic device according to claim 1,
The predetermined violation is a violation in which an access process to the shared resource exists that must not exist in each of the preceding task group and the succeeding task group, and . The arithmetic device, wherein if there is even one of the access processes to the shared resource, it is considered a violation. An inspection method for inspecting the operation of a parallelized program in which a program consisting of a plurality of tasks executed on each of a plurality of processor cores is parallelized, the method comprising:
a first processing order of the plurality of tasks when acquiring access information regarding access to resources shared by the plurality of tasks and applying at least a first condition to the plurality of tasks; A second processing order of the plurality of tasks when a second condition different from the first condition is applied to the plurality of tasks, and a second processing order of the plurality of tasks is determined. In the processing order, a preceding task group consisting of tasks performed before a first task that accesses a resource shared by the plurality of tasks, and a subsequent task group consisting of tasks performed after the first task, 1. An inspection method characterized in that the access information is used to detect the presence or absence of a predetermined violation in the parallelized program for a task specified based on the comparison result. In the inspection method according to claim 8,
The first condition is a condition for assigning an arbitrary execution priority order to each of the plurality of processor cores, and the second condition is a condition for assigning an arbitrary execution priority order to each of the plurality of processor cores, and the second condition is a condition for assigning an arbitrary execution priority order to each of the plurality of processor cores. An inspection method characterized by being a condition for assigning. In the inspection method according to claim 8,
The first condition is the earliest condition for executing one processor core of the plurality of processor cores with priority over other processor cores, and the second condition is the earliest condition for executing one processor core of the plurality of processor cores with priority over other processor cores. An inspection method characterized in that the earliest condition is set once at a time. In the inspection method according to claim 8,
The first condition is the slowest condition for executing one processor core of the plurality of processor cores with priority given to other processor cores, and the second condition is the slowest condition for executing one processor core of the plurality of processor cores with priority given to other processor cores, and the second condition is a An inspection method characterized by subjecting each core to the slowest condition once. In the inspection method according to claim 8,
The first condition is an earliest condition for executing one processor core of the plurality of processor cores with priority over other processor cores, and the second condition is an earliest condition for executing one of the plurality of processor cores with priority over other processor cores. An inspection method characterized by being the slowest condition for executing one processor core with priority over other processor cores. In the inspection method according to claim 8,
The predetermined violation occurs when at least one of the shared resources accessed by a task obtained by the set sum of the preceding task group and the succeeding task group has conflicting read or write operations for the same resource. An inspection method characterized in that a violation is determined when one or more of the following conditions exist. In the inspection method according to claim 8,
The predetermined violation is a violation in which an access process to the shared resource exists that must not exist in each of the preceding task group and the succeeding task group, and . An inspection method characterized in that a violation is determined if even one of the access processes to the shared resource exists.

Images