JP5465745B2 - Program processing method and system - Google Patents

Description

  The present invention relates to a program processing method and system, and more particularly, to a method and system for processing a program by a periodic timer.

  Cloud computing is expected as a next-generation computing environment. By using cloud services, it is possible to procure, augment, and degenerate system execution environments (servers, storage, networks, etc.) in a short time, and you only have to pay the usage fee for the time you use them. Conventionally, software systems have been built on the premise of a fixed execution environment that is sized based on peak performance that occurs only rarely during operation. As a result, low average load and high operation cost were incurred. In the cloud, the size of the execution environment can be changed as needed, so reduction in operating costs can be expected.

  Conventionally, in the development stage of a software system, lack of machine resources often causes development schedule delay. For example, in the test process, a lot of time is spent due to lack of machine resources. By using cloud computing at the development stage, development that is not restricted by machine resources becomes possible, and shortening of the development period and reduction of development costs can be expected. In this way, cloud computing has the potential to solve problems of conventional software systems.

  Cloud computing also has challenges. In general, a software system needs to satisfy performance requirements in addition to function requirements. Conventionally, a constant performance has been guaranteed by performing a performance test in a fixed execution environment. This is because in the conventional system, the execution environment actually operated is fixed, so that it can be inferred that the test result in the execution environment holds at the time of operation. On the other hand, the cloud service provides an execution environment at best effort.

  In the best effort type, for example, when a user executes a program with a high CPU load with respect to the number of clocks of the CPU, the performance of another user who uses the same environment deteriorates. Further, regarding a storage, when a certain user processes a large number of transactions that place an excessive load on the storage, similarly, the I / O performance of another user who uses the same environment deteriorates. The same applies to the network. In this case, the execution environment cannot be specified, and therefore it cannot be inferred that the result of the performance test is valid even during operation.

  Non-Patent Document 1 points out problems related to the performance guarantee of cloud services in a MapReduce environment lending service using the cloud, but does not show a route to solution.

L. Cherkasova. Performance modeling in mapreduce environments: challenges and opportunities. In Proceeding of the second joint WOSP / SIPEW international conference on Performance engineering, ICPE '11, pages 5-6, New York, NY, USA, 2011. ACM.

  As described above, in cloud computing, it is difficult to guarantee performance by testing. That is, it is difficult to size the execution environment necessary for realizing the predetermined performance.

  The present invention has been made in view of such problems, and an object of the present invention is to provide a means for guaranteeing system performance (throughput) in cloud computing in which the execution environment cannot be fixed. .

  In the present invention, in order to construct and process a program capable of determining the performance of software independently of the execution environment, the concept of clock driving in the logic design of the digital circuit is referred to.

  As is well known, digital logic design is classified into two types: combinatorial logic and sequential logic. In the former, the output is determined only by the input, and in the latter, the output (and the next state) is determined by the input and the current state. Sequential logic circuits are classified into two types, event driven and clock driven. In the former, the state change occurs at the timing of the input (Event), while in the latter case, the state change occurs in synchronization with the clock regardless of the input timing. Table 1 shows a comparison between event driving and clock driving.

  Today, digital circuits are usually made of large scale integrated circuits (LSIs). Since each element (such as a transistor) of LSI is manufactured by microfabrication, its characteristics vary. Therefore, event-driven design requires a design with a sufficient timing margin in consideration of characteristic variations. If the variation is larger than the margin, the circuit will not operate normally. Even in the clock drive design, if the circuit operation is not completed within a period and timing violation occurs, the circuit does not operate normally. However, in clock drive design, the probability of occurrence of timing violation can be lowered by lowering the clock frequency and increasing the margin.

  Furthermore, in event-driven design, variations in device characteristics appear as circuit performance differences as they are. On the other hand, in the clock drive design, the performance is the same if the clock frequency is the same. That is, in the clock drive design, a certain performance guarantee can be easily performed as compared with the event drive design.

  Therefore, in the present invention, a timer interrupt, a timer signal (POSIX / UNIX (registered trademark) / Linux (registered trademark)), a timer event (Windows (registered trademark)), or the like that periodically drives a program is used. Thus, the program is clocked.

  When the program of the present invention is driven by the timer, a predetermined process is executed, and when it is finished, the program is rested until the program is driven by the timer. Using a high-speed machine reduces the execution time, but increases the pause time accordingly. If you use a slow machine, the execution time increases and the pause time decreases accordingly. That is, the number of execution steps per hour is the same regardless of whether a high-speed machine or a low-speed machine is used. Therefore, the performance (throughput) is the same regardless of hardware.

  As shown below, the ratio between the execution time τ and the period T is referred to as a duty ratio D.

  When the duty factor is less than 100%, that is, when the execution time is less than the period, the performance of the program is determined by the period T, not the performance of the machine. As a result, hardware-independent performance design is possible.

  In the cloud computing in which the execution environment cannot be fixed by executing a program that operates to perform a certain fixed process by a timer, and when it finishes, the program operates to rest until it is driven by the timer next time. The system performance can be guaranteed.

  Further, according to the present invention, performance guarantee can be realized by configuring a program that satisfies a predetermined condition, so that the provider of the cloud service does not need to maintain extra equipment for performance guarantee. Furthermore, it is possible to quickly and accurately respond to required changes in performance guarantees simply by configuring a program having the characteristics of the present invention at the software development stage.

It is a figure which shows the network structure which concerns on one Embodiment of this invention. It is a figure which shows the example of a program description of the task which concerns on one Embodiment of this invention. It is a figure which shows the example of a program description of the task which utilizes another task which concerns on one Embodiment of this invention. It is a figure which shows the example of a program description of the task arrangement | sequence which concerns on one Embodiment of this invention. It is a figure which shows the call graph of the task which concerns on one Embodiment of this invention. It is a PERT figure of the task concerning one embodiment of the present invention. It is a figure which shows the call graph of the task which concerns on one Embodiment of this invention. An example of program description of a task using polling is shown. An example of program description of a task using polling is shown. It is a PERT figure of the task concerning one embodiment of the present invention. It is a precedence relation table which shows precedence relation between tasks concerning one embodiment of the present invention. It is a figure which shows the example of a program description before applying a variable rename technique. It is a figure which shows the example of a program description after applying a variable rename technique. It is a figure which shows the call graph before and behind applying an individualization technique. It is a figure which shows the example of a program description of the task to which the lottery technique is applied. It is a figure which shows the example of a program description of the task to which the lottery technique is applied. It is a PERT figure of the task concerning one embodiment of the present invention. It is a figure which shows the example of a program description which performs the task which concerns on one Embodiment of this invention. It is a figure which shows the example of a program description which performs the task which concerns on one Embodiment of this invention. It is a sequence diagram which performs the task which concerns on one Embodiment of this invention in parallel. It is a flowchart which shows the process of processing a program with the periodic timer which concerns on one Embodiment of this invention. It is a figure which shows the example of a program description which performs the task which concerns on one Embodiment of this invention.

(System configuration)
FIG. 1 is a diagram showing a network configuration according to an embodiment of the present invention. A plurality of program processing systems 101a, 101b,..., 101n (hereinafter referred to as program processing system 101) are connected to a plurality of client computers 103a, 103b,. 103) and are communicably connected to each other.

  The program processing system 101 has a memory for storing a program for realizing a service provided to the user, and in response to a user request, the program processing system 101 stores data necessary for processing the program stored in the storage. Use to provide services. The program executed by the program processing system 101 of the present invention is a clock driven programming (CDP) program configured to satisfy a predetermined condition.

  The client computer 103 is a terminal used by a cloud service user. The user uses the service provided by the program processing system 101 via the client computer 103 without being aware of the server group. In this embodiment, the client computer 103 is a general personal computer.

(CDP program)
CDP is part of Event Driven Programming (EDP). Thus, CDP can be practiced with any programming language and OS that supports EDP. In this embodiment, C language and Windows are used, but the present invention is not limited to this.

  The difference between CDP and EDP is in the use of event handlers. In EDP, an arbitrary number of timers can be used, whereas in CDP, it is required to always use one timer that provides a timer event handler.

  In EDP, processing corresponding to an event is performed in all event handlers including a timer event handler. On the other hand, in CDP, in the event handlers other than the timer event handler, by setting a flag indicating the state, only the occurrence of the event is recorded, and the processing corresponding to the event is not performed here. In CDP, a timer event handler executes a task corresponding to the occurrence of an event based on a flag indicating a state.

  The CDP program is created by the following procedure. 1) Identify and describe the task. 2) Understand the prior relationship between tasks and create a PERT diagram. 3) Create a schedule that satisfies the precedence relationship given by the PERT diagram. Task description, PERT diagram creation, and schedule creation will be described in this order.

(Task description)
The task of the CDP of the present invention will be described based on the program description example of FIG. In the present invention, a CDP task is defined using the following elements.
Internal variable: One or more variable interface functions used to take over values between states: Zero or more function reset functions for other tasks to reference or update internal variables Function: Function task body for initializing internal variables Function: Function called by timer event handler

  The CDP task is a state machine whose operation to be executed changes depending on the state. Use internal variables to transfer values between states. In the example of FIG. 2, an internal variable taskA_data of the taskA_data_t structure type is defined at line number L5. Note that the taskA_data_t structure type includes, as members, taskA_state_t enumerated variable state, int type x, y, and result, as indicated by line numbers L2 to L4 in FIG.

  The CDP task defines an interface function for other tasks to refer to or update the internal variables as necessary. In the example of FIG. 2, the calc method defined by line numbers L13 to L31 and the get_result method defined by line numbers L33 to L43 are interface functions. The calc method is a function for requesting processing to TaskA described in FIG. 2, and the get_result method is a function for requesting a processing result.

  The CDP task also defines a reset function to initialize internal variables. In the example of FIG. 2, the taskA_RST method defined by line numbers L45 to L48 is a reset function. In this embodiment, the member variable state of the internal variable taskA_data is initialized in the reset function.

The CDP task defines a task body function called by the timer event handler. In the example of FIG. 2, the taskA_CLK method defined by line numbers L50 to L84 is a task body function. As shown in FIG. 2, the task body function executes calculation according to the value of taskA_data.state. When state is calc1, F (x) is calculated. Here, the function F is an external function defined in another module such as a standard library, as defined by the line number L11. When state is calc2, F (x) ^y is calculated with the constant LIMIT as the upper limit.

  Here, the task execution time needs to be shorter than the timer period. Therefore, the task needs to satisfy the following two requirements. 1) A task has an upper limit of execution steps. 2) Each statement of a task has an upper limit on execution time.

  In order to satisfy the requirement 1), each function is written in a form that syntactically guarantees termination. That is, it is described so that it can be expanded into a combination of selection (if then else) and sequential (;). Regarding loops, only loops with an upper limit on the number of iterations can be described, and it is not allowed to write a loop whose number of iterations is determined at execution time. The indefinite number of loops is realized by periodically executing a fixed number of loops as in the taskA_CLK method of FIG. In this case, although the number of steps varies depending on the selection (if then else), there is an upper limit to the number of steps executed in one cycle, so that the requirement 1) is satisfied.

  The problem in meeting requirement 2) is when the statement contains a function call. When the function to be called is an interface function of another task, there is no problem because there is an upper limit on the number of execution steps for the call destination function, resulting in an upper limit on execution time. On the other hand, if the function to be called is a function that does not conform to CDP, such as an API that calls a library function or an OS function, there may be no upper limit on the execution time.

  Particularly problematic is blocking I / O existing in the OS API. For example, when a file is read using the blocking I / O READ function, control is not returned to the calling program until the file reading is completed. This cannot satisfy the requirement 2). Thus, in principle, CDP tasks use non-blocking I / O instead of blocking I / O. Alternatively, blocking I / O is used after confirming that the block is not blocked using a select function or the like.

  Next, FIG. 3 shows a program description example of taskB that uses taskA shown in FIG. taskB has a structure type internal variable taskB_data including enumeration type variable state and int type a, b, and z as members. In the task body function of taskB, as indicated by the line number L34 in FIG. 3, when the state is state_10, processing is requested to taskA by calling the calc method. As shown in line number L23 of FIG. 2, 0 is returned as a return value only when the request is accepted according to the state of taskA. Therefore, taskB retries until the request is accepted, and transitions to state_11 when the request is accepted.

  Also, as indicated by the line number L40 in FIG. 3, when the state is state_11, an attempt is made to acquire the processing result by calling the get_result method. Again, as indicated by line number L40 in FIG. 2, 0 is returned as the return value only when the calculation is completed according to the state of taskA. Therefore, taskB calls the get_result method for each clock until a return value of 0 is obtained, and transitions to state_12 when the processing result is acquired.

(Task arrangement)
As shown in line number L18 in FIG. 2, taskA accepts a calculation request only when state is free. In other words, while taskA accepts a preceding calculation request and executes a calculation, it cannot accept a calculation request from another task. Therefore, in order to process a plurality of calculation requests at the same time, a task array in which tasks are arrayed is defined in order to prepare a plurality of tasks having the same function. FIG. 4 shows a program description example of a task array in which taskA shown in FIG. 2 is arrayed.

  As indicated by line number L4 in FIG. 4, in the task array, internal variables are arrayed. Then, as indicated by the line number L7, an index is received as an argument of the interface function calc, and the received index is designated when referring to or updating the internal variable. In other functions as well, tasks can be arranged by receiving an index as an argument, and specifying the received index and updating the reference of the internal variable. The number of elements in the internal variable array is referred to as task array multiplicity, and the multiplicity of unarranged tasks (for example, taskA in FIG. 2) is 1.

(Create a PERT diagram)
After the task is described, the prior relationship between the tasks is grasped and a PERT diagram is created. The timer event handler calls a task body function, and the precedence relationship between tasks is a precedence relationship between task body functions. A certain task calls an interface function of another task in its task body function, and acquires a processing result of the other task. For example, taskB shown in FIG. 3 calls the get_result method of taskA in the task body function, and acquires the processing result F (x) ^y of taskA. The call graph of FIG. 5 shows the static call relationship of this interface function.

  Here, in order for taskB to obtain a processing result, the task body function of taskA needs to be completed before the task body function of taskB is executed. In this case, taskA precedes taskB. A PERT diagram showing the completion order can be obtained by reversing the direction of the arrows in the call graph (FIG. 6). However, PERT diagrams cannot be obtained from all call graphs.

  In order to obtain a PERT diagram, the call graph needs to be acyclic (no loop). As shown in FIG. 7, when the call graph is not acyclic, it is necessary to change the interface direction between tasks by using polling. Since the call graph between taskA and taskB is acyclic, there is no need to change the interface direction between tasks. As a reference example using polling, FIGS. 8A and 8B show program description examples of taskA and taskB with the interface direction changed.

  Tasks that can be executed simultaneously can be determined from the obtained PERT diagram. Assume that the PERT diagram shown in FIG. 9 is obtained based on the call graph. Here, the graph G in the PERT diagram shown in FIG. 9 is composed of a set of nodes corresponding to tasks 1 to 9 and a set of arrows representing the preceding relationship between tasks. In the PERT diagram, in addition to the nodes corresponding to the original tasks 1 to 9, end points s and t representing the start and finish of the entire program are described.

  FIG. 10 shows a prior relationship table showing the prior relationship between tasks included in the PERT diagram of FIG. In the figure, ◎ indicates that two tasks have a direct preceding relationship. For example, task 1 and task 4 (calling the interface function of task 1), task 1 and task 6 (calling the interface function of task 1) have a direct precedence relationship. ○ in the figure indicates that the two tasks have an indirect precedence relationship. For example, task 1 and task 7, task 1 and task 8, task 1 and task 9, etc. have an indirect precedence relationship. X in the figure indicates that two tasks cannot have a preceding relationship.

  An indirect predecessor relationship occurs between two tasks that do not have a direct predecessor relationship but have a predecessor relationship via one or more tasks. For example, task 1 and task 7 have a leading relationship via task 4 that calls the interface function of task 1 and that interface function is called by task 7. Similarly, task 1 and task 8 have a preceding relationship via task 4. Task 1 and task 9 have a preceding relationship via task 4 and task 7, or via task 6.

  Here, when the task u calling the interface function of the specific task v and the task w have a direct or indirect precedence relationship, the task u and the task w are not executed simultaneously. For example, the task 4 and the task 6 that call the interface function of the task 1 have a direct precedence relationship as shown in FIG. On the other hand, the task 5 and the task 8 that call the interface function of the task 3 do not have a preceding relationship as shown in FIG.

  When multiple tasks call the interface function of the same task at the same time, the result may change depending on the order in which the tasks are executed or the order in which the interface functions are executed. Therefore, an interface function that can be called simultaneously from a plurality of tasks needs to satisfy Bernstein's conditions. Bernstein's conditions are well-known sufficient conditions that allow program fragments to be executed in parallel.

For example, functions f and g included in task 3 that can be called from task 5 and task 8 at the same time are a set of internal variables (R (f)) syntactically referenced in function f, in function f. A set of internal variables (W (f)) that are syntactically assigned in, a set of internal variables that are syntactically referenced in function g (R (g)), and a syntactic assignment in function g When the following (1) to (3) are satisfied for the set of internal variables (W (g)), Bernstein's conditions are satisfied and parallel execution can be performed.
R (f) ∩ W (g) = φ ・ ・ ・ (1)
R (g) ∩ W (f) = φ ・ ・ ・ (2)
W (f) ∩ W (g) = φ ・ ・ ・ (3)

(Rewriting technique to a program that satisfies Bernstein's conditions)
If tasks that can be executed simultaneously do not meet Bernstein's conditions, the program must be modified using rewrite techniques. Three typical rewriting techniques are introduced below.

  There is a variable renaming technique as the first rewriting technique. 11A and 11B show program description examples before and after applying the variable renaming technique. In the program description example before application, as shown in FIG. 11A, in the interface functions read and write, R (read) {W (write) = {taskA_x} ≠ φ, and Bernstein's conditions are not satisfied. On the other hand, in the example of the program description after application, as shown in FIG. 11B, R (read) ∩W (write) = φ is satisfied by separately modifying the program using internal variables, and Bernstein's conditions are satisfied. it can.

  As a second rewriting technique, there is an individualization technique. In the individualization technique, tasks having interface functions that do not satisfy Bernstein's conditions are arranged. FIG. 12 shows call graphs before and after applying the individualization technique. In the call graph before application, as shown in FIG. 12 (left), competition of the interface function calc_F occurs, R (calc_F)） W (calc_F) = {taskB_data} ≠ φ, and Bernstein ’s conditions are not satisfied. On the other hand, in the call graph after application, as shown in FIG. 12 (right), by arranging taskB, R (calc_F (0)) ∩) W (calc_F (1)) = {taskB_data [0] } ∩ {taskB_data [1]} = φ, and Bernstein's conditions can be satisfied.

  As a third rewriting technique, there is a lottery technique. The personalization technique described above cannot be applied when only one resource is used. In this case, competition of interface functions is prevented by a lottery technique in which only internal variables are arranged and tasks are not arranged. Specifically, as shown in FIG. 13A, in the task body function of taskB that is the target of competition, one of a plurality of interface function calls is selected (lottery), and only the selected (winned) call is selected. Execute the process and return an error for calls that were not selected (declined). Further, as shown in FIG. 13B, in the task C (and task D (not shown)) which is the calling task, the interface function is repeatedly called until it is won.

(Create schedule)
Once the PERT diagram is obtained, a schedule is created next. The schedule defines which task is assigned to which resource at which timing so as to satisfy the preceding relationship given in the PERT diagram. It is desirable to create a schedule that minimizes the completion time under the constraints of available resources. A schedule is created based on the PERT diagram shown in FIG.

(Schedule creation-sequential execution)
In the case of sequential execution, a schedule can be easily created by topologically sorting the PERT diagrams using a known algorithm. In the case of the PERT diagram of FIG. 14, the following three schedules are created. It is assumed that task body functions of taskX, taskY, taskZ, and taskW are taskX_CLK (), taskY_CLK (), taskZ_CLK (), and taskW_CLK (), respectively.
Schedule 1 = taskX_CLK (); taskY_CLK (); taskW_CLK (); taskZ_CLK ();
Schedule 2 = taskX_CLK (); taskY_CLK (); taskZ_CLK (); taskW_CLK ();
Schedule 3 = taskX_CLK (); taskZ_CLK (); taskY_CLK (); taskZ_CLK ();

  As long as the preceding relationship in the PERT diagram is satisfied, the same result can be obtained in any order, and the same completion time can be obtained. Therefore, an arbitrary schedule can be selected. FIG. 15 shows an example of a program description for executing a task according to schedule 1. In line number L25 in FIG. 15, the timer is set so that the function specified by the fourth argument (OnTimer) is called every 100 milliseconds specified by the third argument (presiod). In this embodiment, in order to execute the schedule 1, the task execution order is defined as indicated by line numbers L6 to L9 in FIG.

(Schedule creation-parallel execution)
When executing in parallel, the precedence relationship between tasks is realized using synchronization primitives. In this embodiment, an Event Object provided by Windows is used as a synchronization primitive. The Event Object has two states (signal state / non-signal state). By calling SetEvent (e), the Event Object specified by the handle of the argument e becomes a signal state. When WaitForSingleObject (e) is called, if the Event Object specified by the handle of the argument e is in a non-signal state, the calling thread of WaitForSingleObject (e) continues to wait until it becomes a signal state. When SetEvent (e) is called by another thread and the Event Object specified by e is in a signal state, control is returned and the calling thread can execute the subsequent processing.

For example, consider a case where the PERT diagram of FIG.
Schedule 4-0 = taskX_CLK (); SetEvent (e1); SetEvent (e2);
Schedule 4-1 = WaitForSingleObject (e1); taskZ_CLK ();
Schedule 4-2 = WaitForSingleObject (e2); taskY_CLK (); SetEvent (e3);
Schedule 4-3 = WaitForSingleObject (e3); taskW_CLK ();

  In the schedule 4-0, when the taskX_CLK method is completed, the Event Object specified by e1 and e2 is set in the signal state. In the schedule 4-1, WaitForSingleObject (e1) is called, and it waits until the Event Object specified by e1 becomes a signal state. When SetEvent (e1) is called upon completion of the taskX_CLK method, control is returned to the thread corresponding to the schedule 4-1, and the taskZ_CLK method is executed. Similarly, in schedule 4-2, WaitForSingleObject (e 2) is called, and the process continues to wait until the Event Object specified by e 2 becomes a signal state. When SetEvent (e2) is called by completing the taskX_CLK method, the thread control corresponding to the schedule 4-2 is returned, and the taskY_CLK method is executed. In the schedule 4-2, when the taskY_CLK method is completed, the Event Object specified by e3 is set in the signal state. The schedule 4-3 also calls WaitForSingleObject (e3) and keeps waiting until the Event Object specified by e3 becomes a signal state. When SetEvent (e3) is called upon completion of the taskY_CLK method, control is returned to the thread corresponding to the schedule 4-3, and the taskW_CLK method is executed.

  FIG. 16 shows an example of a program description for executing tasks according to schedules 4-0 to 4-3. In line number L43 in FIG. 16, the timer is set so that the function specified by the fourth argument (OnTimer) is called every 100 milliseconds specified by the third argument (presiod). In this embodiment, threads corresponding to schedules 4-1 to 4-3 are prepared as indicated by line numbers L3 to L14 in FIG.

  In the OnTimer method, first, Event Objects specified by s [0], s [1], and s [2] corresponding to the thread 1, thread 2, and thread 3 are set in a signal state. Thereafter, schedule 4-0 is executed in the main thread, and the WaitForSingleObject method of the Event Object specified by t [0], t [1], and t [2] corresponding to thread 1, thread 2, and thread 3 is called. Thus, it continues to wait until the Event Object becomes a signal state, that is, until the corresponding thread is completed. FIG. 17 shows a sequence diagram of parallel execution.

  The thread 1 corresponding to the schedule 4-1 calls WaitForSingleObject (s [0]) and keeps waiting until the Event Object specified by s [0] becomes a signal state. As indicated by the line number L18 in FIG. 16, when SetEvent (s [0]) is called in the OnTimer method, control is returned to the thread 1 and WaitForSingleObject (e1) is called. After that, it continues to wait until the Event Object specified by e1 becomes a signal state. When SetEvent (e1) is called upon completion of the taskX_CLK method, control is returned to the thread 1 and the taskZ_CLK method is executed. When the taskZ_CLK method is completed, the thread 1 notifies the completion of the thread by setting the Event Object specified by t [0] to the signal state.

  Similarly to thread 1, thread 2 (not shown) corresponding to schedule 4-2 calls WaitForSingleObject (s [1]) and waits until the Event Object specified by s [1] becomes a signal state. to continue. As indicated by the line number L19 in FIG. 16, when SetEvent (s [1]) is called in the OnTimer method, control is returned to the thread 2 and WaitForSingleObject (e2) is called. After that, it continues to wait until the Event Object specified by e2 becomes a signal state. When SetEvent (e2) is called upon completion of the taskX_CLK method, control is returned to the thread 2 and the taskY_CLK method is executed. When the taskY_CLK method is completed, the thread 2 calls SetEvent (e3) that notifies the completion of taskY, and then notifies the completion of the thread by setting the Event Object specified by t [1] as a signal state.

  Similarly to thread 1, thread 3 (not shown) corresponding to schedule 4-3 calls WaitForSingleObject (s [2]) and waits until the Event Object specified by s [2] becomes a signal state. to continue. As indicated by the line number L20 in FIG. 16, when SetEvent (s [2]) is called in the OnTimer method, control is returned to the thread 3 and WaitForSingleObject (e3) is called. After that, it continues to wait until the Event Object specified by e3 becomes a signal state. When SetEvent (e3) is called upon completion of the taskY_CLK method, control is returned to the thread 3 and the taskW_CLK method is executed. In the thread 3, when the taskW_CLK method is completed, the completion of the thread is notified by setting the Event Object specified by t [2] to the signal state.

(Schedule creation-Task arrangement)
There is no predecessor relationship between each task in the task array. Therefore, each task may be scheduled in any order. In addition, since all codes of the task array are the same and only the location of the internal variable is different, it can be expected that the average execution time of each task in the task array is the same. Therefore, when the multiplicity of tasks is m and the number of available CPUs is n, m / n tasks are distributed to each CPU.

If taskY in the PERT diagram shown in FIG. 14 is a task array with a multiplicity of 4, and the number of available CPUs is 5, the following schedule can be created.
Schedule 5-0 = taskX_CLK (); SetEvent (e1); SetEvent (e21); SetEvent (e22);
Schedule 5-1 = WaitForSingleObject (e1); taskZ_CLK ();
Schedule 5-2 = WaitForSingleObject (e21); taskY_CLK (0); taskY_CLK (2);
SetEvent (e31);
Schedule 5-3 = WaitForSingleObject (e22); taskY_CLK (1); taskY_CLK (3);
SetEvent (e32);
Schedule 5-4 = WaitForSingleObject (e31); WaitForSingleObject (e32);
taskW_CLK ();

  In this way, a task body function that exists in the number of multiplicity can be indexed and distributed to each CPU, whereby a schedule can be created according to the number of available CPUs.

(CDP program performance)
The performance of the above-described CDP program can be obtained by the following equation as the throughput P (tps) of a task representing the program.

  m is the multiplicity of tasks (the number of tasks having the same function), c is the number of task body functions called per unit processing (Clocks Per Transaction: CPT), and f is the program driving frequency (the reciprocal of timer period T) Here, in order to call the task body function while maintaining the period T, the duty ratio needs to be less than 1.

When CPT varies as in task A described in FIG. 2, an average value is used. As described above, taskA executes an indefinite number of loops by periodically executing a fixed number of loops. In this embodiment, F (x) ^y is calculated when the state is calc2. As indicated by the line number L62 in FIG. 2, a loop of an indefinite number of times specified by the second argument y of the calc method is Executes periodically at the upper limit specified by the constant LIMIT.

  Therefore, in the case of 1 ≦ y ≦ 101, the task body function is called twice in total, once in state is calc1 and once in state is calc2, and the CPT is 2. In the case of 101 ≦ y ≦ 201, the task body function is called three times in total, with the state being calc1 once and the state being calc2 twice, and the CPT is 3. For example, when the probability that the CPT is 2 is 50% and the probability that the CPT is 3 is 50%, the CPT is 2.5.

  In CDP, as long as the duty ratio is less than 1, a throughput proportional to the program driving frequency f can be guaranteed. The performance difference of the execution environment in CDP appears as a difference in duty ratio. When the program is executed at the same program driving frequency, the low-speed CPU has a higher duty ratio than the high-speed CPU. However, even if there is a difference in duty ratio, the performance is the same if the program driving frequency is the same.

(Method of processing a program with a periodic timer)
Next, with reference to a flowchart of FIG. 18, a process of processing a program by a periodic timer according to the present embodiment will be described. As advance preparation for processing a program by a periodic timer, it is necessary to create the CDP program described above and store it in the memory of a computer that processes the CDP program. The CDP program includes the task program detailed in the (task description) chapter and the execution program detailed in the (schedule creation) chapter.

  In the present embodiment, it is assumed that the task program taskA in FIG. 2 and taskB in FIG. 3 and the execution program for executing taskA and taskB shown in FIG. 19 are stored in the memory.

  In step S1, a call to the reset function is received from the execution program, and internal variables of the task program are initialized. In the present embodiment, upon receiving a call to the taskA reset function indicated by the line number L21 in FIG. 19, the internal variable taskA_data.state indicating the state of taskA is initialized to free. Also, it receives the taskB reset function call shown in line L22 in the figure, initializes the internal variable taskB_data.state indicating the state of taskB to state_10, and executes the internal variable taskB_data.a and taskB_data.b used for calculation in the execution program Stores x and y specified by the arguments.

  In step S2, a timer setting request including a timer period and a first function that calls a task body function of the task program is received from the execution program, and a timer period and a timer event handler are set. In the present embodiment, as indicated by the line number L24 in FIG. 19, the timer period is set to 100 milliseconds, and the OnTimer function is registered as a timer event handler.

  In the OnTimer function, task body functions are called in the order of taskA and taskB based on the preceding relationship in the PERT diagram of FIG.

  In step S3, the task body function is called by calling the first function at a timer cycle, and the process corresponding to the internal variable indicating the state is executed in the called task body function. In this embodiment, it is assumed that x = 5 and y = 3 are designated by the argument of the execution program when the reset function of taskB is called.

  (Timer cycle 1st time) First, the main function of taskA is executed by calling the OnTimer function which is the first function. Since taskA_data.state is free, the main function of taskA ends without doing anything. Next, the main function of TaskB is executed. Since taskB_data.state is initialized to state_10 by the reset function, the interface function calc that requests processing to taskA is called. In this embodiment, taskA_data.state is free when the taskA interface function calc is called. Therefore, in the interface function calc of taskA, calc1 is set in taskA_data.state, and 5, 3 are stored in taskA_data.x and taskA_data.y, respectively. Then, by accepting the processing request for taskA, state_11 is set in taskB_data.state.

  (Timer period second time) The OnTimer function which is the first function is called again. Since the task body function of taskA is called and taskA_data.state is calc1, F (x) is calculated and calc2 is set in taskA_data.state. Next, the task body function of taskB is called, and taskB_data.state is state_11. Therefore, an interface function get_result that requests a processing result from taskA is called. When taskA's interface function get_result is called, taskA_data.state is calc2, so a return value indicating that processing has not ended is returned.

(Timer cycle 3rd) The OnTimer function which is the first function is called again. Since the task body function of taskA is called and taskA_data.state is calc2, F (x) ^y is calculated. Here, since y = 3, the processing corresponding to calc2 is completed in this timer cycle, and fin is set to taskA_data.state. Next, the task body function of taskB is called, and taskB_data.state is state_11. Therefore, an interface function get_result that requests a processing result from taskA is called. When the taskA interface function get_result is called, taskA_data.state is fin. Therefore, taskA_data.state is set to free in the taskA interface function get_result. In the main function of taskB, upon reception of the processing result from taskA, state_12 is set in taskB_data.state, and the Event Object specified by end is set to the signal state in order to instruct the end of the periodic execution.

  As a result of the third timer cycle, the loop continuation condition of line number L25 in FIG. 19 becomes false, and the control of the main function shifts to L31. Finally, in step S4, a call to an interface function that requests a processing result from the task program is received from the execution program, and the processing result is acquired. In this embodiment, a call to an interface function get_resultB that requests a processing result from taskB is received from the execution program. When the interface function get_resultB of taskB is called, taskB_data.state is state_12. Therefore, the execution program can acquire the calculation result from taskB.

  In this manner, a predetermined fixed process is executed by the timer, and when the process ends, a program that operates to rest until it is driven by the timer is processed. In the above-described embodiment, when the constraint of 1 ≦ y ≦ 101 is imposed, the CPT is 3, and as long as the duty ratio is less than 1, according to the equation (2), 1/3 × f (the reciprocal of the timer period T) ) Throughput can be guaranteed. Since the performance guarantee as a system can be realized, the service provider does not need to maintain an extra facility for the performance guarantee. Furthermore, it is possible to quickly and accurately respond to required changes in performance guarantees simply by configuring a program having the characteristics of the present invention at the software development stage.

Claims (7)

A computer having a memory for storing a clock driven programming (CDP) program, which processes the program with a periodic timer, wherein the CDP program describes internal variables, interface functions, reset functions, and task body functions A task program, and an execution program having a timer for periodically executing the task body function,
Receiving a call to the reset function from the execution program and initializing the internal variables of the task program;
A timer setting request including a cycle of the timer and a first function is received from the execution program, a timer cycle of the execution program is set to a cycle included in the timer setting request, and a timer event of the timer of the execution program Registering the first function included in the timer setting request as a handler, the first function including calling the task body function of the task program;
Invoking the task body function by calling the first function at a period of the timer, wherein the task body function is based on a state internal variable indicating the state of the task program among the internal variables. Executing a process corresponding to the state of the task program and updating the state internal variable in accordance with the progress of the execution of the corresponding process,
Receiving a call to the interface function that requests a processing result from the task program from the execution program, and determining whether to accept the processing result request based on the state internal variable. .   2. The method according to claim 1, wherein a plurality of the task programs are provided, and a schedule for calling each task body function of the plurality of task programs is specified in the first function.   The method according to claim 2, wherein the interface functions that can be called simultaneously from the plurality of task programs satisfy Bernstein's condition.   2. The method according to claim 1, wherein the task program is arranged, and a schedule for calling each task body function of the arranged task program is designated in the first function.   The method according to claim 1, wherein the interface function, the reset function, and the task body function do not include an indefinite number of loops.   The method according to claim 1, wherein Blocking I / O is not used in the interface function, the reset function, and the task body function. A memory for storing a clock driven programming (CDP) program;
A program processing system comprising a processor,
The CDP program includes an internal variable, an interface function, a reset function, a task program describing a task body function, and an execution program having a timer for periodically executing the task body function,
The processor is
Receiving a call to the reset function from the execution program and initializing the internal variables of the task program;
A timer setting request including a cycle of the timer and a first function is received from the execution program, a timer cycle of the execution program is set to a cycle included in the timer setting request, and a timer event of the timer of the execution program Registering the first function included in the timer setting request as a handler, the first function including calling the task body function of the task program;
Invoking the task body function by calling the first function at a period of the timer, wherein the task body function is based on a state internal variable indicating the state of the task program among the internal variables. Executing a process corresponding to the state of the task program and updating the state internal variable in accordance with the progress of the execution of the corresponding process,
Receiving a call to the interface function that requests a processing result from the task program from the execution program, and determining whether to accept the processing result request based on the state internal variable. A program processing system.

Images