WO2025262913A1 - Program execution device and program execution method - Google Patents

Abstract

A program execution device (1000) comprises: a task switching unit (1324) that, if a second computation task (1312) is being executed, transfers an execution right from the second computation task (1312) to a first computation task (1311); and a task modification unit (1323) that, if a request to transfer the execution right to the first computation task (1311) is made during execution of the second computation task (1312), interrupts execution of the second computation task (1312), modifies the next checkpoint of the second computation task (1312) on a secondary storage device (1300) so as to cause a call to the task switching unit (1324), and resumes execution of the second computation task (1312) from the point of interruption in the second computation task (1312).

Description

Program execution device and program execution method

This disclosure relates to a program execution device and a program execution method.

In computer systems, the exclusive control function provided by the operating system (OS) can be used to exclusively control multiple threads or tasks, including critical sections, on a single core. For example, when using the exclusive control function provided by the OS from a user program, a system call is issued to invoke the kernel's exclusive control function. Therefore, in addition to the cost of the exclusive processing itself, there is the cost of switching from userland to the kernel, and this overhead accumulates each time a critical section is executed, resulting in performance degradation.

In Patent Document 1, a userland process sets a flag indicating preemption inhibition in its own preemption inhibition variable to 1, and the process invokes a setting process to set the address information where the preemption inhibition variable is located in the OS. The OS then references the preemption inhibition variable using a preset preemption inhibition variable address in response to a periodically occurring timer interrupt, and if the value of the preemption inhibition flag is 1 and the time elapsed since the preemption inhibition start time is less than the duration threshold, the OS continues to execute the process without performing preemption.

International Publication No. 2016/063511

In Patent Document 1, from the perspective of a userland process, preemption can be suppressed simply by setting a value in its own preemption-prohibited variable immediately before the critical section is executed. From an assembly level perspective, this can be achieved by adding instructions to load a value into a register and store the register value in memory, and the degradation in process execution performance is thought to be small, but not zero. However, in Patent Document 1, if preemption execution is blocked during execution of a critical section, there is no function to re-execute the blocked preemption after the critical section is executed, and the process must wait for the next preemption opportunity. This can result in long response times.

Furthermore, when multiple threads or tasks that contain a large number of densely packed critical sections are mutually exclusive on a single core, the overhead caused by the processing time of the mutual exclusive control itself accumulates, resulting in a significant degradation of performance that cannot be ignored. In addition, there is the problem that the side effect of the mutual exclusive control is that it causes an increase in the response time of the threads or tasks. It is difficult for Patent Document 1 to solve both of these problems.

The present disclosure has been made in light of the above, and aims to provide a program execution device that can perform exclusive control while minimizing performance degradation and extended response times, even when multiple threads or tasks that contain a high density of critical sections are exclusively controlled on a single processor core.

In order to solve the above-mentioned problems and achieve the objectives, the program execution device disclosed herein comprises a storage device that stores an operation program and a system program, and a microprocessor that has one or more processor cores and executes the operation program and the system program. The operation program includes a first operation task and a second operation task that has a scheduling priority lower than that of the first operation task, and is executed on a single processor core of the microprocessor. The second operation task includes multiple critical sections and checkpoints located at the beginning of each critical section. The program execution device comprises a task switching unit that transfers execution rights from the second operation task to the first operation task if the second operation task is being executed, and a task modification unit that, when a request to transfer execution rights to the first operation task is made during execution of the second operation task, suspends execution of the second operation task, modifies the second operation task in the storage device to call the task switching unit for the next checkpoint in the second operation task, and resumes execution of the second operation task from the point of suspension in the second operation task.

The program execution device disclosed herein has the advantage of being able to perform exclusive control while minimizing performance degradation and response time extension, even when multiple threads or tasks that contain a high density of critical sections are exclusively controlled on a single processor core.

FIG. 1 is a block diagram showing an example of a configuration of a program execution device according to a first embodiment; 1 is a time chart showing an example of an operation when a computing program is executed in the first embodiment; FIG. 10 is a diagram showing an example of a C language description of a second operation task including a critical section in the first embodiment. FIG. 10 is a diagram showing an example of an assembly code of a second operation task including a critical section in the first embodiment. FIG. 1 is a diagram illustrating an example of a configuration of an address calculation unit of a system program in a program execution device according to a first embodiment; FIG. 1 is a diagram showing an example of a configuration of an address table of an address calculation unit of a system program in a program execution device according to a first embodiment; FIG. 1 is a diagram illustrating an example of a configuration of a checkpoint information holding register of a system program of the program execution device according to the first embodiment; 1 is a flowchart illustrating an example of an operation of a task correction unit of a system program of a program execution device according to a first embodiment. 1 is a flowchart showing an example of an operation of a task switching unit of a system program of a program execution device according to a first embodiment; FIG. 1 is a sequence diagram illustrating an example of a series of operations of each component of the program execution device according to the first embodiment. FIG. 10 is a block diagram showing an example of a configuration of a system program of a program execution device according to a second embodiment. FIG. 10 is a diagram showing an example of a C language description of a second operation task including a critical section in the second embodiment. 10 is a flowchart showing an example of an operation of a task correction unit of a system program of a program execution device according to a second embodiment. 10 is a flowchart showing an example of an operation of a task switching unit of a system program of a program execution device according to a second embodiment. FIG. 10 is a block diagram showing an example of a configuration of an arithmetic program of a program execution device according to a third embodiment. 10 is a time chart showing an example of an operation when a computing program is executed in the third embodiment. FIG. 10 is a diagram showing an example of a C language description of an h-th operation task including a critical section in the third embodiment. FIG. 10 is a diagram showing an example of a C language description of an i-th operation task including a critical section in the third embodiment. 10 is a flowchart showing an example of an operation of a task correction unit of a system program of a program execution device according to a third embodiment. 10 is a flowchart showing an example of an operation of a task switching unit of a system program of a program execution device according to a third embodiment. FIG. 10 is a sequence diagram illustrating an example of a series of operations of each component of the program execution device according to the third embodiment. FIG. 13 is a diagram showing an example of a C language description of an h-th operation task including a critical section in the fourth embodiment. FIG. 13 is a diagram showing an example of a C language description of an i-th operation task including a critical section in the fourth embodiment. 10 is a flowchart showing an example of an operation of a task correction unit of a system program of a program execution device according to a fourth embodiment. 10 is a flowchart showing an example of an operation of a task switching unit of a system program of a program execution device according to a fourth embodiment.

The program execution device and program execution method according to the embodiments are described in detail below with reference to the accompanying drawings.

Performance degradation due to the overhead of exclusive control processing can be reduced by reducing the frequency of use of the exclusive control functions provided by the OS depending on the execution status of the user program, or by performing exclusive control processing in userland instead. However, when targeting multiple threads or tasks that contain a large number of critical sections at a high density and running them on a single processor core while maintaining exclusive control, even using the above-mentioned technologies may still result in problems with execution performance and response time.

As an example of multiple threads or tasks that contain a high density of critical sections, consider the case where a target machine equipped with a dedicated hardware engine and shared memory, such as a PLC (Programmable Logic Controller), is emulated on a single processor core of a host machine, such as an industrial PC (Personal Computer). Incidentally, in embedded devices such as PLCs and industrial PCs, it is common to group similar or interdependent functions and assign them to the same processor core.

The emulator is said to consist of multiple dedicated hardware engine models and a shared memory model. The dedicated hardware engine models simulate the instruction operations of the dedicated hardware engines using instructions from the host machine's processor. If the instruction being simulated is a load or store instruction, it will access the shared memory model, so basically the processing of one instruction in the dedicated hardware engine must be exclusively controlled as an indivisible process (critical section).

In general, emulator performance is required to be equal to or better than the specs of the target machine. For example, if the target machine's processor frequency is 100 MHz, the time required to execute one instruction must be 10 ns or less. It is easy to imagine that if even a few host machine instructions are added to simulate one target machine instruction for the sake of mutual exclusion, this will result in a significant degradation in the emulator's overall performance.

Furthermore, when using exclusive control for critical sections, it is also necessary to consider whether the side effect of exclusive control will unintentionally lengthen waiting times. In the case of the PLC emulator mentioned above, each task corresponding to a dedicated hardware engine must be able to periodically calculate and send control commands to devices such as servos or motors in real time. For example, if an interrupt is used to switch the execution of tasks for each dedicated hardware engine model, it is important that the response time to the interrupt is short and that response performance is good.

Furthermore, when multiple threads or tasks that contain a large number of densely packed critical sections are mutually exclusive on a single core, the overhead caused by the processing time of the mutual exclusive control itself accumulates, resulting in a significant degradation of performance that cannot be ignored. In addition, there is the problem that the side effect of the mutual exclusive control is that it causes an increase in the response time of the threads or tasks. The program execution device according to the embodiment described below solves both of these problems.

Embodiment 1.
The following describes a program execution device and a program execution method according to embodiment 1. In embodiment 1, an example is described in which two computation tasks each having an execution period and a scheduling priority are prioritized by an OS, but embodiment 1 can also be applied to a computation task that does not have an execution period or is not prioritized.

FIG. 1 is a block diagram showing an example of the configuration of a program execution device 1000 according to the first embodiment. The program execution device 1000 according to the first embodiment can be constructed, for example, by an embedded controller, but is not limited to this.

The program execution device 1000 includes a microprocessor 1100, a main memory device 1200, and a secondary memory device 1300 as a memory device.

The microprocessor 1100 has one or more processor cores 1100-1 to 1100-4 and executes various programs. While Figure 1 illustrates a configuration with four processor cores 1100-1 to 1100-4, the number of processor cores is not limited to this. The main memory 1200 stores programs and data required for program execution. The main memory 1200 is, for example, cache memory or RAM (Random Access Memory). The secondary memory 1300 stores and retains programs and data required for program execution. The secondary memory 1300 is, for example, Flash memory or eMMC (embedded Multi-Media Card). The secondary memory 1300 has an operation program 1310 and a system program 1320. The operation program 1310 has a first operation task 1311 and a second operation task 1312. The system program 1320 includes an address calculation unit 1321, a checkpoint information holding register 1322, a task correction unit 1323, and a task switching unit 1324.

The task correction unit 1323 uses the address calculation unit 1321 to identify and correct the checkpoint to be executed next for the currently running second calculation task 1312. At that time, a pair of the address of the corrected checkpoint and the instruction at the location pointed to by that address is stored in the checkpoint information holding register 1322. As will be described later, checkpoints are simply marks for identifying critical sections, and no processing is performed by the processor cores 1100-1 to 1100-4. The task switching unit 1324 restores the checkpoint in the second calculation task 1312 corrected by the task correction unit 1323, and switches task execution between the first calculation task 1311 and the second calculation task 1312.

Figure 2 is a time chart showing an example of the operation of the calculation program 1310 during execution in embodiment 1. The first calculation task 1311 and the second calculation task 1312 are threads or tasks, which are the smallest units of processing executed by the OS. Furthermore, the first calculation task 1311 and the second calculation task 1312 share an address space with each other and do not have their own independent address spaces. In addition, the first calculation task 1311 and the second calculation task 1312 are not interrupt processing or exception processing. The following explanation takes as an example a case where the first calculation task 1311 and the second calculation task 1312 are tasks.

The first calculation task 1311 has a first execution period 2110 and a first scheduling priority 2120. The second calculation task 1312 has a second execution period 2210 and a second scheduling priority 2220 that is lower than the first scheduling priority 2120. The first calculation task 1311 and the second calculation task 1312 are allocated to and executed by a single processor core 1100-n provided in the microprocessor 1100 based on their respective scheduling priorities by the OS scheduler.

While the second calculation task 1312 is running, a timer interrupt or the like occurs at the start of the first execution cycle 2110 of the first calculation task 1311. This causes the execution of the second calculation task 1312 to be suspended, and because the first scheduling priority 2120 is higher than the second scheduling priority 2220, the OS starts execution of the first calculation task 1311. When execution of the first calculation task 1311 ends, execution of the second calculation task 1312 resumes from the point where it was interrupted.

Figure 3 shows an example of a C language description of the second calculation task 1312 including a critical section 3400-n in embodiment 1. n is 1, 2, 3, etc. In Figure 3, a running variable 3100 is defined, indicating whether the second calculation task 1312 is running. A value of "true" for the running variable 3100 indicates that the task is running, and a value of "false" indicates that the task is not running. A task2() function 3200 is also defined as a routine executed by the second calculation task 1312, and it is assumed that the entry point of this routine is linked to the second calculation task 1312 when the second calculation task 1312 is created. Figure 3 shows an example of an implementation of the task2() function 3200, in which a code block containing a large number of densely packed critical sections is repeatedly processed using a while statement. The waitUntilDispatched() function is used at the beginning of the while statement block to wait until the OS grants execution permission and the task enters the running state. Note that the waitUntilDispatched() function is written to make the example in Figure 3 easier to understand, and in practice a function that acquires a semaphore or similar provided by the OS may be used. When the wait is released, the running variable 3100 is set to "true", and at the end of the while block, the running variable 3100 is set to "false".

At the beginning of each critical section 3400-n, a label is written as a checkpoint 3300-n. In embodiment 1, checkpoint 3300-n is simply a marker or label for identifying critical section 3400-n, and no processing is performed by processor cores 1100-1 to 1100-4. However, because each critical section 3400-n includes a checkpoint 3300-n at its beginning that is modified by task modification unit 1323, care must be taken to ensure that the two consecutive critical sections 3400-n and 3400-(n+1) are not optimized together during compilation, resulting in the boundary between them being removed. Therefore, for example, as shown in Figure 3, it is appropriate to write labels equivalent to checkpoint 3300-n using inline assembler with a volatile modifier.

Furthermore, the position at which checkpoints 3300-n are inserted into the second operation task 1312 does not necessarily have to be before or after each critical section 3400-n. For example, checkpoints may be inserted after every third or every fourth critical section. There is a trade-off: the wider the interval at which checkpoints 3300-n are inserted, the less the degree of degradation in execution performance will be, but the longer the response time will be (poor responsiveness); and the narrower the interval, the greater the degree of degradation in execution performance will be, but the shorter the response time will be (better responsiveness). Therefore, the interval at which checkpoints 3300-n are inserted may be used as a parameter, and the interval at which checkpoints 3300-n are inserted may be adjusted based on the degree of degradation in execution performance and the estimated or measured values of response time.

FIG. 4 is a diagram showing an example of assembly code for the second operation task 1312, which includes a critical section, in embodiment 1. FIG. 4 shows a simplified version of the assembly code generated as a result of compiling the C language code for the second operation task 1312 shown in FIG. 3. Checkpoints 4100-n in FIG. 4 correspond to checkpoints 3300-n in FIG. 3.

FIG. 5 is a diagram showing an example of the configuration of the address calculation unit 1321 of the system program 1320 of the program execution device 1000 according to the first embodiment. The address calculation unit 1321 receives a program counter value as input, and calculates the address of the checkpoint 3300-n to be executed next in the second calculation task 1312 from the program counter value. The address calculation unit 1321 includes an address table 5100.

Figure 6 is a diagram showing an example of the configuration of the address table 5100 of the address calculation unit 1321 of the system program 1320 of the program execution device 1000 according to the first embodiment. The address table 5100 is an array of addresses on the main memory device 1200 where the checkpoint 3300-n inserted in the second operation task 1312 is located. Entry 6100-n represents the storage of the addresses of checkpoint 3300-n in Figure 3 and checkpoint 4100-n in Figure 4 (the addresses of the checkpoints in Figures 3 and 4 are the same). One method for obtaining the address of checkpoint 3300-n in the second operation task 1312 is, for example, to declare a variable corresponding to the label equivalent to checkpoint 3300-n as extern in the second operation task 1312, and then obtain the address of each checkpoint 3300-n by referencing each variable during execution. The series of operations up to loading the acquired addresses into each entry 6100-n only needs to be performed once after the second calculation task 1312 is loaded into the main memory 1200, and may be performed during the initialization process of the second calculation task 1312.

FIG. 7 is a diagram showing an example of the configuration of the checkpoint information holding register 1322 of the system program 1320 of the program execution device 1000 according to the first embodiment. The checkpoint information holding register 1322 includes an address field 7100 for holding the address of a checkpoint, and an instruction field 7200 for holding the instruction at the location indicated by the checkpoint address.

FIG. 8 is a flowchart showing an example of the operation of the task correction unit 1323 of the system program 1320 of the program execution device 1000 according to the first embodiment. The task correction unit 1323 is called when a request for transfer of execution rights occurs, and corrects the checkpoint 3300-n in the second calculation task 1312 as necessary. Here, the execution right transfer request can be made using, for example, an interrupt or a semaphore, and a notification can be sent to the second calculation task 1312 from a task assigned to a processor core 1100-m other than the processor core 1100-n to which the calculation program 1310 is assigned. When an interrupt is used, the task correction unit 1323 may be implemented as an interrupt handler. When a semaphore is used, the task correction unit 1323 may be implemented as a task.

In step S8101, the value of the running variable 3100 in the second calculation task 1312 is checked to see if it is "true" or "false," and it is determined whether the second calculation task is currently running. If it is currently running, step S8102 is processed next; if it is not currently running, step S8201 is processed next.

In step S8102, the program counter (PC) value (return address) at the time when execution of the second calculation task 1312 was interrupted due to the task correction unit 1323 being activated in response to a request to transfer execution rights is obtained. If the task correction unit 1323 is implemented as an interrupt handler, for example, if the architecture of the microprocessor 1100 is Armv8, the PC value is saved to a link register when an interrupt occurs, and the PC value is obtained by accessing the link register from the interrupt handler. If the task correction unit 1323 is implemented as a task, the register state, etc. (context) is usually saved to a save area on the main memory device 1200 when the OS switches task execution, and the PC value is obtained by accessing that save area.

In step S8103, the PC value obtained in step S8102 is passed to the address calculation unit 1321, and the address of the next checkpoint 3300-n to be executed in the second calculation task 1312 is obtained.

In step S8104, the next checkpoint information, which is a pair of the address of the next checkpoint 3300-n obtained in step S8103 and the instruction located at the location pointed to by the address of checkpoint 3300-n, is stored in the checkpoint information holding register 1322. These are stored in the address field 7100 and instruction field 7200, respectively.

In step S8105, the location pointed to by the address of the next checkpoint 3300-n obtained in step S8103 is rewritten to an instruction that calls the entry point of the task switching unit 1324. This is nothing more than rewriting the instruction in the executable text area loaded onto the main memory device 1200. For example, if the executable format is ELF (Executable and Linkage Format), this rewrites the load segment (called the text area) that contains the text section in which the instruction is stored. For this reason, the calculation program 1310 must assign a writable attribute to the text area when it is compiled. In step S8106, execution of the task correction unit 1323 ends, and execution of the second calculation task 1312 resumes.

In step S8201, since it was determined in step S8101 that the second calculation task 1312 was not currently being executed, the task correction unit 1323 directly calls the task switching unit 1324 and starts the first calculation task 1311.

FIG. 9 is a flowchart showing an example of the operation of the task switching unit 1324 of the system program 1320 of the program execution device 1000 according to the first embodiment. The task switching unit 1324 restores the checkpoint in the second calculation task 1312 corrected by the task correction unit 1323, and uses the functions of the OS to transfer execution rights from a task with a low scheduling priority to a task with a high scheduling priority. The task switching unit 1324 may be implemented as a function, for example.

In step S9101, it is determined whether the second calculation task 1312 is running. For example, this determination may be made by referring to whether the value of the running variable 3100 in the second calculation task 1312 is "true" or "false." If the second calculation task 1312 is running, step S9102 is processed next; if the second calculation task 1312 is not running, step S9104 is processed next.

In step S9102, the address of checkpoint 3300-n corrected by the task correction unit 1323 and the pair of instructions located at the location indicated by the address of checkpoint 3300-n are obtained from the checkpoint information holding register 1322.

In step S9103, the location pointed to by the address obtained in step S9102 is rewritten to the command obtained in step S9102.

In step S9104, the second operation task 1312, which has a lower second scheduling priority 2220, transfers execution rights to the first operation task 1311, which has a higher first scheduling priority 2120. The transfer of execution rights can be achieved, for example, by using a binary semaphore. In the first operation task 1311 and second operation task 1312 assigned to a single processor core 1100-n, the second operation task 1312 begins execution by acquiring a binary semaphore (P operation). During execution of the second operation task 1312, when the task switcher 1324 is called from a checkpoint in the second operation task 1312 via steps S8101 to S8106 of the task corrector 1323 described above, or when the task switcher 1324 is called from the task corrector 1323 via steps S8101 to S8201, the task switcher 1324 releases the binary semaphore (V operation). As a result, the OS determines that the first calculation task 1311 has the highest scheduling priority among the calculation tasks currently being executed or executable on the processor core 1100-n, and execution is switched from the second calculation task 1312 to the first calculation task 1311.

In step S9105, the process waits until execution of the first calculation task 1311 is complete.

In step S9106, the process returns to the address obtained in step S9102, and execution of the second operation task 1312 resumes. Assuming that the task switching unit 1324 is implemented as a function, when a function is called, the address of the instruction following the jump instruction to the function's entry point is usually held in a dedicated register as the return address, and is used when returning from the function to the caller. In embodiment 1, the position of the first instruction at the beginning of each critical section 3400-n in the second operation task 1312 is set as checkpoint 3300-n. When a request for transfer of execution rights is made, the task modification unit 1323 rewrites the next checkpoint 3300-(n+1) of the critical section 3400-n that was being executed to an instruction that calls the task switching unit 1324. If the task switcher 1324 is called from checkpoint 3300-(n+1), and the task switcher 1324 returns to the second operation task 1312 by returning to the return address stored in the dedicated register, the task will return to the position of the second instruction from the beginning of the critical section 3400-n, and the first instruction from the beginning will not be executed. To avoid this, when returning from the task switcher 1324 to the second operation task 1312, it is necessary to return to the address obtained from the checkpoint information holding register 1322.

FIG. 10 is a sequence diagram showing an example of a series of operations of the components of the program execution device 1000 according to the first embodiment. FIG. 10 shows how the first calculation task 1311, the second calculation task 1312, the task correction unit 1323, and the task switching unit 1324 interact with each other when a request for transfer of execution rights occurs during execution of the critical section 3400-2 in the second calculation task 1312.

First, when a request to transfer execution rights occurs during execution of critical section 3400-2 in the second operation task 1312, the task correction unit 1323 is activated and corrects the task so that the task switch unit 1324 is called from checkpoint 3300-3 located at the beginning of the next critical section 3400-3. Execution of the task correction unit 1323 ends, and the unexecuted part of critical section 3400-2 that was being executed in the second operation task 1312 is executed. Execution reaches checkpoint 3300-3 located at the beginning of the next critical section 3400-3, and the task switch unit 1324 is called. The task switch unit 1324 corrects the task so that it is not called from checkpoint 3300-3, and transfers execution rights from the second operation task 1312 to the first operation task 1311, and the first operation task 1311 is executed.

When execution of the first calculation task 1311 is completed, execution rights are returned to the task switching unit 1324 and returned to the second calculation task 1312, and execution of the second calculation task 1312 is resumed from the beginning of the critical section 3400-3.

<Effects of First Embodiment>
In the first embodiment, when two threads or tasks containing a large number of densely packed critical sections are executed on a single processor core 1100-n, when a request for transfer of execution rights occurs, the task modification unit 1323 modifies the currently executing task to call the task switching unit 1324 from a checkpoint in the currently executing task, and exclusive control is achieved by switching execution to another task starting from the modified checkpoint. When a request for transfer of execution rights does not occur, the task modification unit 1323 does not modify the currently executing task, and the original task simply has a checkpoint (label) inserted that is not processed by the processor core 1100-n, so performance degradation during execution is, in principle, zero. Furthermore, because task execution switching is always performed starting from a checkpoint, there is an effect of preventing an unintended extension of response time.

Embodiment 2.
A program execution device and a program execution method according to the second embodiment will be described below. In the following description, components similar to those described in the first embodiment will be denoted by the same reference numerals, and detailed description thereof will be omitted as appropriate. In the second embodiment, an example will be described in which two computation tasks each having an execution period and a scheduling priority are prioritized by the OS, but the second embodiment can also be applied to a computation task that does not have an execution period or is not prioritized.

In the first embodiment, when a request to transfer execution rights occurs, the task correction unit 1323 rewrites the checkpoint in the task being executed. In other words, an operation is performed to rewrite the executable text area loaded on the main memory device 1200. Generally, a text area is set with readable and executable attributes by a compiler, and rewriting to the text area is not possible when the text area is being executed. If a text area that is intended to be read and executed were to be rewritten during execution, a malicious code block could be inserted and executed, so this is suppressed from a security perspective. Therefore, in the second embodiment, a program execution device and program execution method are described that do not require the operation of rewriting the text area during execution.

FIG. 11 is a block diagram showing an example of the configuration of a system program 11000 of a program execution device 1000 according to the second embodiment. The system program 11000 includes a task correction unit 11100 and a task switching unit 11200.

Figure 12 is a diagram showing an example of a C language description of the second calculation task 1312 including a critical section 12400-n in embodiment 2. In Figure 12, a function pointer 12200 is defined as a checkpoint and initialized to "0." The function pointer 12200 will be described in detail in the explanation of the operation flow of the task correction unit 11100, but this is a difference from embodiment 1. The task correction unit 11100 assigns the address of the entry point of the task switching unit 11200 to the function pointer 12200. Figure 12 shows an example of an implementation of the task2() function 12300 in which a code block containing a large number of critical sections 12400-n densely is repeatedly processed using a while statement. The waitUntilDispatched() function is used at the beginning of the while statement block to wait until execution permission is granted by the OS and the task enters the running state. When the wait is released, the running variable 12100 is set to "true", and at the end of the while block, the running variable 12100 is set to "false".

At the beginning of each critical section 12400-n, code is written as checkpoints 12200-1 to 12200-3 to check that the value of the function pointer is not "0" and to call the task switcher 11200 by referencing the function pointer. Thus, in embodiment 2, checkpoints 12200-1 to 12200-3 are code for referencing the function pointer and calling the task switcher 11200. During execution, overhead is generated for conditional branching depending on the value of the function pointer at the checkpoint. This code for checking the value of the function pointer and calling the function using the function pointer results in overhead for processing the conditional branching compared to embodiment 1, in which the second calculation task 1312 does not contain any unnecessary code. Note that the label corresponding to checkpoint 3300-n in Figure 3 is not processed during execution. Therefore, in order to reduce overhead, hint information may be provided to the compiler, indicating whether the conditional branch is more likely to be taken or not taken, for example. For example, if the compiler used is GCC (GNU Compiler Collection) and there is a high probability that the conditional branch of the if statement at checkpoint 12200-n will not be satisfied, checkpoint 12200-n can be written as "if(__builtin_expect(!!(checkpoint)、0))checkpoint();" using the built-in functions provided by GCC.

FIG. 13 is a flowchart showing an example of the operation of the task modification unit 11100 of the system program 11000 of the program execution device 1000 according to the second embodiment. The task modification unit 11100 is called when a request for transfer of execution rights occurs, and modifies the checkpoint 12200-n in the second calculation task 1312 as necessary. Here, the execution right transfer request can be made using, for example, an interrupt or a semaphore, and a notification can be sent to the second calculation task 1312 from a task assigned to a processor core 1100-m other than the processor core 1100-n to which the calculation program 1310 is assigned. If an interrupt is used, the task modification unit 11100 may be implemented as an interrupt handler. If a semaphore is used, the task modification unit 11100 may be implemented as a task.

In step S13101, the value of the running variable 12100 in the second calculation task 1312 is checked to see if it is "true" or "false," and it is determined whether the second calculation task is currently running. If it is currently running, step S13102 is processed next; if it is not currently running, step S13201 is processed next.

In step S13102, the address of the entry point of the task switching unit 11200 is cast to the function pointer corresponding to checkpoint 12200-n and assigned to that function pointer type. Unlike in embodiment 1, the task correction unit 11100 does not need to identify the location to be corrected; it only needs to rewrite the value of the function pointer.

In step S13103, execution of the task correction unit 11100 ends, and execution of the second calculation task 1312 resumes.

In step S13201, it is determined that the second calculation task 1312 is not currently running, so the task modification unit 11100 directly calls the task switching unit 11200 and starts the first calculation task 1311.

FIG. 14 is a flowchart showing an example of the operation of the task switching unit 11200 of the system program 11000 of the program execution device 1000 according to the second embodiment. The task switching unit 11200 restores the checkpoint 12200-n in the second calculation task 1312 corrected by the task correction unit 11100, and uses the OS functions to transfer execution rights from a task with a low scheduling priority to a task with a high scheduling priority. The task switching unit 11200 may be implemented as a function, for example.

In step S14101, it is determined whether the second calculation task 1312 is running. For example, this determination may be made by referring to whether the value of the running variable 12100 in the second calculation task 1312 is "true" or "false." If the second calculation task 1312 is running, step S14102 is processed next; if the second calculation task 1312 is not running, step S14103 is processed next.

In step S14102, the task correction unit 11100 assigns the invalid value "0" to the function pointer corresponding to the checkpoint 12200-n corrected by the task correction unit 11100.

In step S14103, the second calculation task 1312, which has a lower second scheduling priority 2220, transfers execution rights to the first calculation task 1311, which has a higher first scheduling priority 2120.

In step S14104, the process waits until execution of the first calculation task 1311 is complete.

In step S14105, the process returns to checkpoint 12200-n in the second calculation task 1312, and execution of the second calculation task 1312 resumes. If the task switching unit 11200 is implemented as a function, this step is a normal return operation from the function.

<Effects of Second Embodiment>
In the second embodiment, similar to the first embodiment, when two threads or tasks containing a large number of densely packed critical sections 12400-n are executed on a single processor core 1100-n, when a request for transfer of execution rights occurs, the task modification unit 11100 modifies the currently executing task so that the task switching unit 11200 is called from a checkpoint in the currently executing task, and exclusive control is achieved by switching execution to another task starting from the modified checkpoint. In the second embodiment, compared to the first embodiment, there is overhead during execution due to conditional branching based on the value of a function pointer at a checkpoint, but performance degradation is minimized by measures such as providing a hint to the compiler regarding the direction of the conditional branch. According to the second embodiment, the same effect as the first embodiment is achieved in terms of extending response time. In addition, in the second embodiment, the task modification unit 11100 does not rewrite the text area loaded on the main memory device 1200, which has the effect of closing security holes that allow malicious code blocks to be inserted and executed during execution.

Embodiment 3.
A program execution device and a program execution method according to the third embodiment will be described below. In the following description, components similar to those described in the first and second embodiments will be denoted by the same reference numerals, and detailed description thereof will be omitted as appropriate. In the third embodiment, an example will be described in which three or more computation tasks each having an execution period and a scheduling priority are prioritized by the OS, but the third embodiment can also be applied to computation tasks that do not have an execution period or are not prioritized.

In the first and second embodiments, a program execution device was described for a case in which a computation program includes two computation tasks, all of which are assigned to a single processor core for execution. In the third embodiment, a program execution device and program execution method will be described for a case in which a computation program includes three or more tasks, all of which are assigned to a single processor core for execution. In particular, the third embodiment is based on the first embodiment and is a program execution device in which the number of computation tasks is expanded to three or more. In the third embodiment, as in the first embodiment, checkpoints are simply marks or labels for identifying critical sections, and no processing is performed by processor cores 1100-1 to 1100-4.

First, the basic idea of embodiment 3 will be described. In embodiment 1, the number of calculation tasks was two, so one (second calculation task 1312) was the calculation task to be interrupted, and the other (first calculation task 1311) was the calculation task that interrupted. Therefore, the number of simultaneous execution right transfer requests during execution of the second calculation task 1312 was at most one. In contrast, in embodiment 3, the number of calculation tasks is three or more, so there will be two or more interrupting calculation tasks. In other words, it is possible to imagine a case where the number of simultaneous execution right transfer requests during execution of a certain calculation task will be two or more.

Digging deeper into the cases where multiple execution right transfer requests can occur as shown above, in Figure 10 of embodiment 1, a malfunction occurs if another execution right transfer request occurs during the period from the time an execution right transfer request is made until the time the first operation task 1311 starts executing. During this period, the checkpoint in the second operation task 1312 that was originally being executed is rewritten with an instruction to jump to the entry point of the task switching unit 1324. If another execution right transfer request occurs during this period, it may happen that the same checkpoint in the second operation task 1312 is rewritten twice, or that the address of the checkpoint to be rewritten cannot be obtained. To avoid these cases, a mechanism is used that does not accept another execution right transfer request during this period.

FIG. 15 is a block diagram showing an example of the configuration of a calculation program 15000 of a program execution device 1000 according to the third embodiment. The calculation program 15000 includes N tasks, including a first calculation task 15100, an h-th calculation task 15200, and an i-th calculation task 15300 (1<h<i≦N). The h-th calculation task 15200 corresponds to the second calculation task in the claims, and the i-th calculation task 15300 corresponds to the third calculation task in the claims.

Figure 16 is a time chart showing an example of the operation during execution of the computation program 15000 in embodiment 3. The first computation task 15100 has a first execution period 16110 and a first scheduling priority 16120. The h-th computation task 15200 has an h-th execution period 16210 and an h-th scheduling priority 16220 that is lower than the first scheduling priority 16120. The i-th computation task 15300 has an i-th execution period 16310 and an i-th scheduling priority 16320 that is lower than the h-th scheduling priority 16220. The first computation task 15100, the h-th computation task 15200, and the i-th computation task 15300 are allocated to a single processor core 1100-n provided in the microprocessor 1100 and executed by the OS scheduler based on their respective scheduling priorities.

When the i-th computation task 15300 is being executed, a timer interrupt or the like occurs at the start of the h-th execution cycle 16210 of the h-th computation task 15200. This causes the execution of the i-th computation task 15300 to be suspended, and because the h-th scheduling priority 16220 is higher than the i-th scheduling priority 16320, the h-th computation task 15200 is executed by the OS. When the execution of the h-th computation task 15200 ends, execution of the i-th computation task 15300 resumes from the point where it was interrupted.

When the h-th calculation task 15200 is being executed, a timer interrupt or the like occurs at the start of the first execution cycle 16110 of the first calculation task 15100. This causes the execution of the h-th calculation task 15200 to be suspended, and because the first scheduling priority 16120 is higher than the h-th scheduling priority 16220, the OS executes the first calculation task 15100. When the execution of the first calculation task 15100 ends, execution of the h-th calculation task 15200 resumes from the point where it was interrupted.

Figure 17 is a diagram showing an example of a C language description of the h-th operation task 15200 including a critical section 17400-n in embodiment 3 (1≦h<i≦N). In Figure 17, a running_h variable 17100 is defined, which indicates whether the h-th operation task 15200 is running. If the value of the running_h variable 17100 is "true", it indicates that it is running, and if it is "false", it indicates that it is not running. In addition, a task_h() function 17200 is defined as a routine executed by the h-th operation task 15200, and it is assumed that the entry point of this routine is linked to the h-th operation task 15200 when the h-th operation task 15200 is generated. Figure 17 shows an example of an implementation of the task_h() function 17200, in which a while statement is used to repeatedly process a code block that includes a large number of critical sections 17400-n densely. The waitUntilDispatched() function is used at the beginning of the while block to wait until execution rights are granted by the task switching unit 1324 and the task enters a running state. When the wait is released, the running_h variable 17100 is set to "true", allowing acceptance of the execution rights transfer request, and the running_h variable 17100 is set to "false" at the end of the while block.

At the beginning of each critical section 17400-n, a label is written as a checkpoint 17300-n.

Figure 18 is a diagram showing an example of a C language description of the i-th operation task 15300 including a critical section 18400-n in embodiment 3 (1≦h<i≦N). In Figure 18, a running_i variable 18100 is defined, which indicates whether the i-th operation task 15300 is running. If the value of the running_i variable 18100 is "true", it indicates that it is running, and if it is "false", it indicates that it is not running. In addition, a task_i() function 18200 is defined as a routine executed by the i-th operation task 15300, and it is assumed that the entry point of this routine is linked to the i-th operation task 15300 when the i-th operation task 15300 is created. Figure 18 shows an example of an implementation of the task_i() function 18200, in which a while statement is used to repeatedly process a code block that includes a large number of critical sections 18400-n densely. The waitUntilDispatched() function is used at the beginning of the while block to wait until execution permission is granted by the OS and the process enters a running state. When the wait is released, the running_i variable 18100 is set to "true", allowing the request to transfer execution permission to be accepted, and the running_i variable 18100 is set to "false" at the end of the while block.

At the beginning of each critical section 18400-n, a label is written as a checkpoint 18300-n.

FIG. 19 is a flowchart showing an example of the operation of the task modification unit 1323 of the system program 1320 of the program execution device 1000 according to the third embodiment. The task modification unit 1323 is called when a request for transfer of execution rights occurs, and modifies the checkpoint in the calculation task that was being executed as necessary. Here, the execution rights transfer request can be made using, for example, an interrupt or a semaphore, and a notification can be sent to the i-th calculation task 15300 from a task assigned to a processor core 1100-m other than the processor core 1100-n to which the calculation program 15000 is assigned. When an interrupt is used, the task modification unit 1323 may be implemented as an interrupt handler. When a semaphore is used, the task modification unit 1323 may be implemented as a task.

In step S19101, processor core 1100-n to which computing program 15000 is assigned is prohibited from accepting requests to transfer execution rights. If an interrupt is used for the request to transfer execution rights, interrupts with a specific ID (Identification) can be masked, or all interrupts can be prohibited. Similar measures can be taken when a semaphore is used for the request to transfer execution rights. This is because when a specific task is started by releasing a semaphore, the OS usually issues an interrupt to the processor core in question to switch the task execution.

In step S19102, the task modification unit 1323 identifies the task ID of the calculation task to be executed next after the calculation task that was being executed immediately before being called. Here, it is assumed that the execution right transfer request corresponds one-to-one with the calculation task to be executed next. When an interrupt is used, one interrupt ID is linked to one task. When a semaphore is used, one semaphore is linked to one task. In this way, the task modification unit 1323 can identify the task ID of the calculation task to be executed next by referring to the interrupt ID or semaphore.

In step S19103, the value of the running variable for all calculation tasks is checked to see if it is "true" or "false," and it is determined whether any calculation task is currently running. If it is currently running, step S19104 is processed next; if it is not currently running, step S19201 is processed next.

In step S19104, the PC value at the time when the execution of the i-th calculation task 15300 was interrupted due to the task correction unit 1323 being activated in response to a request to transfer execution rights is obtained.

In step S19105, the PC value acquired in step S19104 is passed to the address calculation unit 1321, and the address of the checkpoint 18300-n to be executed next in the currently running computation task is acquired. Note that the address table 5100 provided in the address calculation unit 1321 may use the method described in the explanation of Figure 6 to acquire the address of the checkpoint during the initialization process of each computation task, for example, and load the acquired address into each entry 6100-n.

In step S19106, the next checkpoint information, which is a pair of the address of the next checkpoint 18300-n obtained in step S19105 and the instruction located at the location indicated by the address of checkpoint 18300-n, is stored in the checkpoint information holding register 1322.

In step S19107, the location pointed to by the address of the next checkpoint 18300-n obtained in step S19106 is rewritten to an instruction to call the entry point of the task switching unit 1324.

In step S19108, execution of the task correction unit 1323 ends, and execution of the i-th calculation task 15300 that was being executed is resumed.

In step S19201, since it was determined in step S19103 that no calculation tasks were currently being executed, the task modification unit 1323 directly calls the task switching unit 1324 and starts the calculation task specified by the task ID.

FIG. 20 is a flowchart showing an example of the operation of the task switching unit 1324 of the system program 1320 of the program execution device 1000 according to the third embodiment. The task switching unit 1324 restores the checkpoint in the running computation task that has been corrected by the task correction unit 1323. It also uses the OS functions to transfer the execution right from a task with a low scheduling priority to a task with a high scheduling priority. It is assumed that the task switching unit 1324 receives the task ID of the computation task from the task correction unit 1323.

In step S20101, it is determined whether any calculation task is running. For example, this determination may be made by checking whether the value of the running variable for all calculation tasks is "true" or "false." If any calculation task is running, step S20102 is processed next; if not, step S20104 is processed next.

In step S20102, the pair of the checkpoint address corrected by the task correction unit 1323 and the instruction located at the location indicated by the checkpoint address is obtained from the checkpoint information holding register 1322.

In step S20103, the location pointed to by the address obtained in step S20102 is rewritten to the command obtained in step S20102.

In step S20104, the execution right is transferred from the currently running calculation task to the calculation task specified by the task ID. For example, the execution right is transferred from the i-th calculation task 15300, which has a lower i-th scheduling priority 16320, to the h-th calculation task 15200, which has a higher h-th scheduling priority 16220.

In step S20105, the process waits until the execution of the calculation task specified by the task ID is completed.

In step S20106, the process returns to the address obtained in step S20102 and resumes execution of the previously running computation task.

FIG. 21 is a sequence diagram showing an example of a series of operations of the components of the program execution device 1000 according to the third embodiment. FIG. 21 shows how the first operation task 15100, the hth operation task 15200, the ith operation task 15300, the task modification unit 1323, and the task switching unit 1324 interact and operate when a request to transfer execution rights to the hth operation task 15200 occurs during execution of the critical section 18400-2 in the ith operation task 15300, and then a request to transfer execution rights to the first operation task 15100 occurs during execution of the critical section 17400-1 in the hth operation task 15200.

First, when a request to transfer execution rights to the h-th operation task 15200 occurs during execution of critical section 18400-2 in the i-th operation task 15300, the task correction unit 1323 is activated and prohibits acceptance of execution rights transfer requests at the beginning of the critical section, and then corrects the task so that the task switch unit 1324 is called from checkpoint 18300-3 located at the beginning of the next critical section 18400-3. Execution of the task correction unit 1323 ends, and the unexecuted part of critical section 18400-2 that was being executed in the i-th operation task 15300 is executed. Execution reaches checkpoint 18300-3 at the beginning of the next critical section 18400-3, and the task switch unit 1324 is called. The task switching unit 1324 is modified so that it is not called from checkpoint 18300-3, and the execution right is transferred from the i-th operation task 15300 to the h-th operation task 15200. The h-th operation task 15200 is executed, and the execution right transfer request is accepted at the beginning of the task.

Next, when a request to transfer execution rights to the first operation task 15100 occurs during execution of critical section 17400-1 in the h-th operation task 15200, the task correction unit 1323 is activated and prohibits acceptance of the execution rights transfer request at the beginning of the critical section, and then corrects the task so that the task switch unit 1324 is called from checkpoint 17300-2 located at the beginning of the next critical section 17400-2. Execution of the task correction unit 1323 ends, and the unexecuted part of critical section 17400-1 that was being executed in the h-th operation task 15200 is executed. Execution reaches checkpoint 17300-2 at the beginning of the next critical section 17400-2, and the task switch unit 1324 is called. The task switching unit 1324 is modified so that it is not called from checkpoint 17300-2, and the execution right is transferred from the h-th operation task 15200 to the first operation task 15100. The h-th operation task 15200 is executed, and after accepting the execution right transfer request at the beginning of the task, subsequent processing is executed.

When execution of the first operation task 15100 is completed, execution rights are returned to the task switching unit 1324, and the execution is returned to the h-th operation task 15200, and execution of the h-th operation task 15200 is resumed from the beginning of the critical section 17400-2. When execution of the h-th operation task 15200 is completed, the execution is returned to the i-th operation task 15300, and execution of the i-th operation task 15300 is resumed from the beginning of the critical section 18400-3.

<Effects of Third Embodiment>
In the third embodiment, when three or more threads or tasks containing a large number of closely spaced critical sections are executed on a single processor core 1100-n, when a request for transfer of execution rights occurs, the task modification unit 1323 modifies the currently executing task to call the task switching unit 1324 from a checkpoint in the currently executing task, and exclusive control is achieved by switching execution to another task starting from the modified checkpoint. When a request for transfer of execution rights does not occur, the task modification unit 1323 does not modify the currently executing task, and the original task simply has a checkpoint (label) inserted that is not processed by the processor core 1100-n, so performance degradation during execution is, in principle, zero. Furthermore, because task execution switching is always performed starting from a checkpoint, there is an effect of preventing an unintended extension of response time.

Embodiment 4.
A program execution device and a program execution method according to the fourth embodiment will be described below. In the following description, components similar to those described in the first to third embodiments will be denoted by the same reference numerals, and detailed description thereof will be omitted as appropriate. In the fourth embodiment, an example will be described in which three or more computation tasks each having an execution period and a scheduling priority are prioritized by the OS, but the fourth embodiment can also be applied to computation tasks that do not have an execution period or are not prioritized.

In the fourth embodiment, similar to the third embodiment, a program execution device and a program execution method will be described for a case in which an arithmetic program contains three or more arithmetic tasks, all of which are assigned to and executed by a single processor core. In particular, the fourth embodiment is a program execution device based on the second embodiment, in which the number of arithmetic tasks is expanded to three or more.

FIG. 22 is a diagram showing an example of a C language description of the h-th operation task 15200 including a critical section 22400-n in embodiment 4. In FIG. 22, a function pointer 22200 is defined as a checkpoint and initialized to "0." The task modification unit 11100 assigns the address of the entry point of the task switcher 11200 to the function pointer 22200. FIG. 22 shows an example of an implementation of the task_h() function 22300 in which a code block including a high density of multiple critical sections 22400-n is repeatedly processed using a while statement. The waitUntilDispatched() function is used at the beginning of the while statement block to wait until the task switcher 11200 grants execution rights and the task enters the running state. When the wait is released, the running_h variable 22100 is set to "true," allowing acceptance of a request to transfer execution rights, and the running_h variable 22100 is set to "false" at the end of the while statement block.

At the beginning of each critical section 22400-n, code is written as checkpoints 22200-1 to 22200-3 to check that the value of function pointer 22200 is not "0" and to call task switcher 11200 by referencing function pointer 22200. As in embodiment 2, checkpoints 22200-1 to 22200-3 are thus code for referencing the function pointer and calling task switcher 11200, and during execution, overhead is generated for conditional branching depending on the value of the function pointer at the checkpoint.

FIG. 23 is a diagram showing an example of a C language description of the i-th operation task 15300 including critical section 23400-n in embodiment 4. In FIG. 23, a function pointer 23200 is defined as a checkpoint and initialized to "0." The task modification unit 11100 assigns the address of the entry point of the task switching unit 11200 to the function pointer 23200. FIG. 23 shows an example of an implementation of the task_i() function 23300 in which a code block containing a large number of densely packed critical sections is repeatedly processed using a while statement. The waitUntilDispatched() function is used at the beginning of the while statement block to wait until execution permission is granted by the OS and the task enters the running state. When the wait is released, the running_i variable 23100 is set to "true," allowing acceptance of a request to transfer execution permission, and the running_i variable 23100 is set to "false" at the end of the while statement block.

At the beginning of each critical section 23400-n, code is written as checkpoints 23200-1 to 23200-3 to check that the value of the function pointer 23200 is not "0" and to call the task switcher 11200 by referencing the function pointer 23200.

FIG. 24 is a flowchart showing an example of the operation of the task correction unit 11100 of the system program 11000 of the program execution device 1000 according to the fourth embodiment. The task correction unit 11100 is called when a request to transfer execution rights occurs, and corrects the checkpoints in the computation task that was being executed as necessary.

In step S24101, the processor core 1100-n to which the computing program 16000 is assigned is prohibited from accepting a request to transfer execution rights.

In step S24102, the task modification unit 11100 identifies the task ID of the computation task to be executed next after the computation task that was being executed immediately before being called. Here, it is assumed that the execution right transfer request corresponds one-to-one with the computation task to be executed next. When an interrupt is used, one interrupt ID is linked to one task. When a semaphore is used, one semaphore is linked to one task. This allows the task modification unit 11100 to identify the task ID of the computation task to be executed next by referring to the interrupt ID or semaphore.

In step S24103, the value of the running variable for all calculation tasks is checked to see if it is "true" or "false," and it is determined whether any calculation task is currently running. If it is currently running, step S24104 is processed next; if it is not currently running, step S24201 is processed next.

In step S24104, the task switching unit 11200's entry point address is cast to the function pointer corresponding to the checkpoint in the computation task that was being executed, and assigned to that function pointer type. Unlike embodiments 1 and 3, the task correction unit 11100 does not need to identify the location to be corrected; it only needs to rewrite the value of the function pointer.

In step S24105, execution of the task correction unit 11100 ends, and execution of the calculation task that was being executed is resumed.

In step S24201, since it was determined in step S24103 that no arbitrary calculation tasks were currently being executed, the task modification unit 11100 directly calls the task switching unit 11200 and starts the calculation task specified by the task ID.

FIG. 25 is a flowchart showing an example of the operation of the task switching unit 11200 of the system program 11000 of the program execution device 1000 according to the fourth embodiment. The task switching unit 11200 restores the checkpoint in the currently running computation task corrected by the task correction unit 11100, and uses the OS functions to transfer execution rights from a task with a low scheduling priority to a task with a high scheduling priority. The task switching unit 11200 may be implemented as a function, for example.

In step S25101, it is determined whether any calculation task is currently running. For example, this determination may be made by checking whether the value of the running variable for all calculation tasks is "true" or "false." If any calculation task is currently running, step S25102 is processed next; if not, step S25103 is processed next.

In step S25102, the task correction unit 11100 assigns "0" to the function pointer corresponding to the checkpoint corrected.

In step S25103, execution rights are transferred from the currently running computation task to the computation task specified by the task ID. For example, execution rights are transferred from the i-th computation task 15300, which has a lower i-th scheduling priority 16320, to the h-th computation task 15200, which has a higher h-th scheduling priority 16220.

In step S25104, the process waits until the execution of the calculation task specified by the task ID is completed.

In step S25105, the process returns to the checkpoint in the previously executing calculation task and resumes execution of that calculation task. If the task switching unit 11200 is implemented as a function, this step is a normal return operation from the function.

<Effects of Fourth Embodiment>
In the fourth embodiment, when three or more threads or tasks containing a large number of closely spaced critical sections are executed on a single processor core 1100-n, when a request for transfer of execution rights occurs, the task modification unit 11100 modifies the currently executing task so that the task switching unit 11200 is called from a checkpoint in the currently executing task, and exclusive control is achieved by switching execution to another task starting from the modified checkpoint. Compared to the third embodiment, the fourth embodiment has overhead during execution due to conditional branching based on the value of a function pointer at a checkpoint, but performance degradation is minimized by measures such as providing a hint to the compiler regarding the direction of the conditional branch. The fourth embodiment has the same effect as the third embodiment in terms of extending response time. Additionally, the fourth embodiment does not rewrite the text area loaded on the main memory device 1200, which effectively closes security holes that could allow malicious code blocks to be inserted and executed during execution.

Furthermore, within the scope of this disclosure, it is possible to freely combine the various embodiments, and to modify or omit various embodiments as appropriate. This disclosure has been described in detail, but the above description is illustrative in all aspects and is not limiting. It is understood that countless variations not illustrated can be envisioned.

The configurations shown in the above embodiments are examples of the content of this disclosure, and may be combined with other known technologies, or different embodiments may be combined with each other. Parts of the configuration may also be omitted or modified without departing from the spirit of this disclosure.

1000 Program execution unit, 1100 Microprocessor, 1100-1 to 1100-4, 1100-n, 1100-m Processor core, 1200 Main memory, 1300 Secondary memory, 1310, 15000 Calculation program, 1311, 15100 First calculation task, 1312 Second calculation task, 1320, 11000 System program, 1321 Address calculation unit, 1322 Checkpoint information holding register, 1323, 11100 Task correction unit, 1324, 11200 Task switching unit, 3100, 12100 Running variable, 3200, 12300 Task2() function, 3300-n, 4100-n, 12200-n, 17300 -n, 18300-n, 22200-n, 23200-n Checkpoint, 3400-n, 12400-n, 17400-n, 18400-n, 22400-n, 23400-n Critical section, 5100 Address table, 6100-n Entry, 7100 Address field, 7200 Instruction field, 12200, 22200, 23200 Function pointer, 15200 hth operation task, 15300 ith operation task, 17100, 22100 Running_h variable, 17200, 22300 Task_h() function, 18100, 23100 Running_i variable, 18200, 22300, 23300 Task_i() function.

Claims (8)

A program execution device comprising: a storage device that stores an arithmetic program and a system program; and a microprocessor that has one or more processor cores and executes the arithmetic program and the system program,
the computing program includes a first computing task and a second computing task having a scheduling priority lower than that of the first computing task, and is executed on a single processor core in the microprocessor;
the second computing task includes a plurality of critical sections and a checkpoint located at the beginning of each critical section;
a task switching unit that transfers execution rights from the second computation task to the first computation task if the second computation task is currently being executed;
a task modification unit that, when a request for transfer of execution right to the first calculation task is made during the execution of the second calculation task, suspends the execution of the second calculation task, modifies the second calculation task on the storage device so as to call the task switching unit at the next checkpoint in the second calculation task, and resumes the execution of the second calculation task from the interruption point in the second calculation task;
A program execution device comprising: the system program includes an address calculation unit that calculates the address of the next checkpoint from a program counter value, and a checkpoint information holding register;
2. The program execution device according to claim 1, wherein when the execution right transfer request is made during execution of the second calculation task, the task modification unit suspends execution of the second calculation task, obtains a program counter value at the suspension point, obtains the address of the next checkpoint from the address calculation unit, stores a pair of the checkpoint address and the instruction at the position pointed to by the address in the checkpoint information holding register, and rewrites the checkpoint on the storage device to an instruction that calls the task switching unit. the address calculation unit has an address table that stores addresses of the checkpoints included in the second operation task,
The program execution device according to claim 2 , wherein the address table is searched for using the program counter value to calculate the address of the next checkpoint in the second operation task. the task switching unit acquires a pair of an address and an instruction of the checkpoint from the checkpoint information holding register before transferring execution right from the second calculation task to the first calculation task;
The program execution device according to claim 2 , wherein the location pointed to by the address in the second operation task on the storage device is rewritten to the instruction. the checkpoint in the second computation task is a pointer that can refer to the task switching unit inserted at the beginning of the critical section,
2. The program execution device according to claim 1, wherein the task modification unit suspends the execution of the second operation task when the execution right transfer request is received during the execution of the second operation task, and sets the address of the entry point of the task switching unit to the checkpoint next to the suspension point in the second operation task. The program execution device according to claim 5 , wherein the task switching unit transfers the execution right from the second computation task to the first computation task after setting an invalid value to the checkpoint in the second computation task. the computing program includes a third computing task having a scheduling priority lower than that of the second computing task, the third computing task having a plurality of critical sections and a checkpoint located at the beginning of each critical section;
the task switching unit, if the third computation task is being executed, transfers execution rights to the first computation task or the second computation task;
the task modification unit, when a request for transfer of execution right to the first or second computation task is made during the execution of the third computation task, prohibits acceptance of the execution right transfer request by a single processor core, suspends the execution of the third computation task, modifies the third computation task on the storage device to call the task switching unit at the next checkpoint in the third computation task, and resumes the execution of the third computation task from the interruption point in the third computation task;
7. The program execution device according to claim 1, wherein the task switching unit allows a single processor core to accept a request to transfer execution rights at the beginning of processing when the first computation task or the second computation task is in an execution state. A program execution method using a storage device that stores an arithmetic program and a system program, and a microprocessor that has one or more processor cores and executes the arithmetic program and the system program, comprising:
the computing program includes a first computing task and a second computing task having a scheduling priority lower than that of the first computing task, and is executed on a single processor core in the microprocessor;
the second computing task includes a plurality of critical sections and a checkpoint located at the beginning of each critical section;
a task switching step of transferring execution rights from the second computation task to the first computation task if the second computation task is currently being executed;
a task modification step of suspending the execution of the second calculation task when a request for transfer of execution right to the first calculation task is made during the execution of the second calculation task, modifying the second calculation task on the storage device so as to call the task switching step at the next checkpoint in the second calculation task, and resuming the execution of the second calculation task from the interruption point in the second calculation task;
A program execution method comprising: