JP2019185423A - Execution method for application - Google Patents

Abstract

To provide an application execution platform that realizes an execution environment that can reliably manage and monitor an execution state of an application at a middle or an application layer on an OS, and that does not depend on special hardware or OS functions to achieve high-reliability functions required by the application execution state, in a mission-critical application operation system that requires high system reliability.SOLUTION: An application execution platform generates a common library that functionalizes an application and stores it as a functionalized application; generates and pools threads that execute functionalized applications in advance; receives an application start request from a user; associates an execution target application for which a start request has been made with a free thread selected from among the pooled threads, and uses the associated free thread to execute the functionalized application on the common library corresponding to the application to be executed.SELECTED DRAWING: Figure 1

Description

  The present invention relates to an application execution method that enables management and monitoring of an application execution state.

  In order to guarantee high reliability in the information system and the control system, management of the execution state of the application to be operated is required. However, since the execution state of the application is often managed inside the OS, it is not easy to monitor the middle layer or the application layer on the OS. In particular, as an information system and a control system, in order to clearly grasp the end state of an app and to reliably release computer resources such as memory secured by the app and to guarantee high system reliability, It is necessary to devise a method for obtaining information.

  In addition, since there is a great need for minimizing development investment for porting applications by changing generations of hardware and OS, it is desirable that management of the application execution state is realized in the middle layer or application layer on the OS. As one of the techniques, for example, in the case of Linux, the execution state of an application can be monitored using an interface such as NetLink which is a communication means between the OS and the application. However, in the monitoring method, another application is required to reliably receive the application state notification event from the OS, and in order not to miss the event, the application is executed with high priority. There is a need.

  On the other hand, it is difficult to operate an application in which performance interference occurs due to an application other than control processing such as a control system. Therefore, there is a need for a technique capable of managing the execution state of an application operated on the middle layer or application layer on the OS. For example, “Java VM” described in Non-Patent Document 1 is a technology that can control and manage an application written in the Java language in the middle layer, and it is easy to monitor the execution state of the application. However, it is difficult to operate apps written in languages other than Java, especially in environments with strict real-time performance requirements such as control systems, most apps are written in C or assembler. There are difficulties in applying the technology.

Japanese Patent Application Laid-Open No. 2004-151561 discloses a technique that has a plurality of event notification threads as event management means for managing event information of an application, and controls the operations of the plurality of applications using the event management means.
Furthermore, Patent Document 2 discloses a technique relating to a procedure for linking another process such as reading internal information of a thread at the time of thread compilation.

JP 2003-280926 A JP 2005-242879 A

The Java Virtual Machine Specification

In a system that operates mission-critical apps that require high system reliability, an app execution environment that can reliably manage and monitor the execution status of apps is realized in the middle layer or app layer on the OS, and app execution There is a need to facilitate the realization of the required high reliability function depending on the state. In addition, there is a need to minimize development investment for the purpose of porting apps due to generational changes in hardware and OS.
In order to meet these requirements, an object of the present invention is to realize and provide an application execution platform that does not depend on special hardware or OS functions.

  In order to solve the above-mentioned problem, the present invention generates a shared library for functionalizing an application and storing it as a functionalized application, generating and pooling a thread for executing the functionalized application in advance, and requesting to start the application from the user In response, the execution target application for which the start request has been issued is associated with a free thread selected from the pooled threads, and the function is created on the common library corresponding to the execution target application using the related free thread. It is characterized by executing an application.

  According to the present invention, an execution state of an application can be managed and monitored in a control system with strict processing performance requirements without depending on special hardware and OS functions. In addition, since the application source level is not required to be corrected, it is possible to manage and monitor the execution state of the application to be managed in the middle layer and the application layer, and in particular, release of computer resources realized by the application end state. Thus, it is easy to realize a function that requires high reliability.

It is a figure which shows an example of a structure of the hardware which concerns on the Example of this invention, and a software program. It is a figure which shows the structure of an application (AP) management table. It is a figure which shows the structure of a thread management table. It is a figure which shows the structure of a thread event table. It is a figure which shows the detail of the processing flow which a shared library part process performs. It is a figure which shows the detail of the processing flow which a thread pool management part performs. It is a figure which shows the detail of the processing flow of an application start process. It is a figure which shows the detail of the processing flow which a thread process part performs. It is a figure which shows the detail of the processing flow of an application execution process. It is a figure which shows the detail of the processing flow which a thread monitoring part performs.

  When a source of processing logic of an application executed on a normal OS is compiled, a binary executed as one process on the OS is generated. In the present invention, an application whose execution state is to be managed is generated as a shared library of applications that can be loaded into the memory of a computer after being compiled as a single function instead of a single process on the OS. Generate and operate threads to be executed.

  Further, according to the present invention, since the monitoring target application is handled as one function in the thread, the execution end of the corresponding application is surely grasped at the end of the function. Furthermore, the entry point of the functionalized application and the argument to be passed to the application are specified or set by providing an external table, one thread is selected from the thread pool, and the thread is functionalized from the external table. Get the parameters for binary execution.

  Hereinafter, embodiments will be described in detail with reference to the drawings as modes for carrying out the present invention. In the drawings, the notations of the application and the library are “AP” and “Lib”.

FIG. 1 is a diagram illustrating an example of the configuration of hardware and software programs according to an embodiment of the present invention.
The hardware configuration includes an arithmetic device 11 that executes a software program including an OS, and a storage device 12 that stores the program and data necessary for the execution. Here, the storage device 12 is, for example, a RAM or a hard disk. The arithmetic device 11 includes one or more CPUs 11-A.

The configuration of the software program will be described.
The OS 21 has a function for scheduling an application that runs on the OS, an exclusive control function for computer resources such as the computing device 11 and the storage device 12, and a generation control function for a synchronous event for operation control for cooperation between applications. Have. In addition, it has a function provided in a general-purpose OS such as Linux or Windows.

  The application 51 is a source file for generating at least one binary that includes instruction codes that can be executed by the arithmetic device 11. The application 51 is converted into an assembly code by a compiler and converted into a binary executable by the arithmetic device 11. The application 51 converted into binary is executed by the OS 21 in units of processes managed by the OS 21.

  The shared library (Lib) conversion unit 31 has a processing function for converting an application 51 that is converted into a binary that is normally executed in a process unit by a compiler into a binary in one function unit of the shared library 53. With this function, after one or more applications 51 are binary-converted in units of functions, a shared library 53 is generated using a compiler function.

  The thread pool management unit 41 generates and manages one or more threads 61 that execute the binaries of the functionalized application 51 included in the shared library 53. The thread 61 is a process or thread managed by the OS 21, and is generated by the thread pool management unit 41 using the function of the OS 21.

  The thread pool management unit 41 includes a thread processing unit 42 and a thread monitoring unit 43, and an application (AP) management table 44, a thread management table 45, and a thread event table 46 as tables.

  The thread processing unit 42 is a processing function executed by the thread 61, and the thread monitoring unit 43 is a processing function executed by the monitoring thread 62. Here, the monitoring thread 62 is generated by the thread pool management unit 41 and monitors the abnormality of the thread 61.

Each table (application management table 44, thread management table 45, and thread event table 46) will be described in order with reference to FIGS.
FIG. 2 is a diagram illustrating the configuration of the application management table 44. The application management table 44 is a table managed and operated in the OS layer in the computer environment where the conventional application 51 is operated. With the application management table 44, the execution state of the application 51 can be monitored, and a highly reliable function necessary for the system can be realized. For example, there is a release of computer resources allocated to the corresponding application. In the present embodiment, the shared library unit 31 and the thread pool management unit 41 can be operated in the middle layer on the OS 21.

  The application management table 44 includes an application (AP) identifier 44 -A for identifying the application (AP) 51 and an application (AP) state 44 -B for storing the execution state of the application 51. As the execution state of the application 51, 'D' indicating that the thread 61 for executing the application 51 is allocated, 'S' indicating the binary execution start of the application 51, and indicating that the application 51 is being executed in binary. Each of “R” and “E” indicating the end of execution of the application 51 is included. Here, the execution states of ‘S’ and ‘E’ are set by the thread processing unit 42 processed by the thread 61. The other states are set by the thread pool management unit 41 according to the binary processing content of the application 51.

  FIG. 3 is a diagram showing the configuration of the thread management table 45. The thread management table 45 includes a thread MAX number 45-A that stores the value of the maximum number of threads 61 generated by the thread pool management unit 41, and an abnormality flag 45-B that stores a processing result in the thread monitoring unit 43 of the monitoring thread 62. , The thread identifier 45-C for identifying the thread 61, and 45-D for storing the identifier of the application 51 executed by the thread 61. The thread MAX number 45-A is preset by the user. The abnormality flag 45-B stores either “1” indicating an abnormal state or “0” indicating a normal state.

  FIG. 4 is a diagram showing the configuration of the thread event table 46. The thread event table 46 sets parameters passed between the thread pool management unit 41 and the thread 61, and there are as many record rows as the number of threads 61. Each record line includes a thread identifier 46-A for identifying a thread to which the thread pool management unit 41 wants to deliver an event and a parameter to be delivered.

  These parameters include a thread management parameter 46-B and an application (AP) execution parameter 46-C. Further, the thread management parameter 46-B has a thread priority 46-B1 and a resource access authority 46-B2 for controlling access to computer resources. Further, the application execution parameter 46-C is used to execute a function-modified binary of the application 51 executed by the thread 61.

  The thread priority 46-B1 in the thread management parameter 46-B is based on the scheduler provided by the OS on the computer environment in which the conventional application 51 is executed as one process, and the thread pool management of the middleware layer on the OS 21. This is a parameter to be realized by the unit 41. For example, in the priority-based real-time schedule, the priority may be set with the priority 46-B1. The set priority is reflected in the OS 21 as the priority of the thread 61 for executing the binarized function on the shared library 53 by the shared library forming unit 31 using the binary of the conventional application. Thereby, the scheduler which operated the conventional application can be flexibly realized by an external connection.

  In addition, since the application execution parameter 46-C can be passed to the thread 61, the processing of the conventional application can be realized by a functionalized binary. For example, the web server application can be functionalized by the shared library unit 31 and executed by the thread 61, and the start and end of the processing can be reliably monitored by the middle layer of the OS 21. Details of the monitoring process of the start and end of the application process will be described later with reference to FIG.

  Next, a processing flow by the shared library unit 31 will be described. FIG. 5 is a diagram illustrating details of a processing flow executed by the shared library unit 31. In each of the following steps, since the shared library unit 31 is an execution subject of processing, description of the subject is omitted.

<Step 101>
From the user, the application identifier of the application 51 for which the functionalized binary is created is received.

<Step 102>
The location where the intermediate file for creating the functionalized binary from the source file of the application 51 specified by the user is read from the converted application (AP) storage location storage unit 32 that stores the information.

<Step 103>
The application 51 of the application (AP) source is rewritten to the assembly code AP52 by the compiler and stored in the designated location of the converted application storage location storage unit 32. The compiler used here may be a general-purpose compiler that can be operated by the OS 21. For example, in the case of general-purpose Linux, it corresponds to a compiler “gcc (GNU Compiler Collection)”.

<Step 104>
The assembly code AP52 is read, the “_main” symbol of the entry_point process is searched from the assembly code, the application identifier received from step 101 is added to the head, and the entry_point symbol is converted. For example, when the application identifier is “AP1”, “_main” is converted to “_AP1_main”. However, what is necessary is just to be tied with the application 51 irrespective of the format of conversion.

<Step 105>
The “_exit” symbol for end processing is searched from the assembly code, and if there is this symbol, it is replaced with return processing from the function. For example, the stack frame “pop” and “ret” assemblers are replaced.

<Step 106>
According to the shared library generation option of the compiler, all converted assembly codes AP52 stored as intermediate files in the converted application storage location storage unit 32 are compiled to generate a shared library 53. For example, in the case of “gcc”, the option “−shared” is used.

<Step 107>
It is loaded on the RAM of the storage device 12 so that the thread 61 that executes the binary of the functionalized application 51 on the shared library 53 can access. For example, the POSIX API can be used, or in the case of standard Linux, the “ldconfig” command can be used.

  Next, a processing flow by the thread pool management unit 41 will be described. FIG. 6 is a diagram illustrating details of a processing flow executed by the thread pool management unit 41. In each of the following steps, since the thread pool management unit 41 is the execution subject of processing, the description of the subject is omitted.

<Step 201>
The thread MAX number 45-A in the thread monitoring table 45 is read and stored in an internal variable. The thread MAX number 45-A is assumed to be set by the user, and is set to “32” in the present embodiment.

<Step 202>
The internal variable of the thread generation counter (cnt) is initialized (cnt ← 0).

<Step 203>
It is confirmed whether or not the value of the thread generation counter (cnt) exceeds the value of the thread MAX number 45-A. When it exceeds (Y), the process proceeds to step 204, and when it does not exceed (N), the process proceeds to step 211.

<Step 204>
A monitoring thread 62 to be processed by the thread monitoring unit 43 is generated. The monitoring thread 62 is generated using the function of the OS 21.

<Step 205>
Proceed to the application start process. The application start process will be described later with reference to FIG.

<Step 211>
A thread 61 to be processed by the thread processing unit 42 is generated, and a return value from the OS 21 is stored in the internal variable TID. The thread 61 is generated using the function of the OS 21.

<Step 212>
The thread generation counter (cnt) is incremented by 1, and the internal variable TID is stored in the thread identifier 45-C of the thread management table 45 for this thread generation counter.

<Step 213>
The internal variable TID is stored in the thread identifier 46-A of the thread generation counter in the thread event table 46, and the line of the thread identifier 46-A is initialized with “0”.

<Step 214>
A thread generation counter-th execution application (AP) identifier 45-D of the thread management table 45 is initialized with “0”.

  As described above, by generating necessary threads in advance from step 211 to step 214 and creating a pool, the process generation processing time required when the conventional application 51 starts execution as a process can be saved. Further, this embodiment is also effective in the execution environment of the application 51 of the system that requires real-time performance.

Next, the process flow of the application start process in step 205 will be described. FIG. 7 is a diagram illustrating details of a process flow of the application start process. In each of the following steps, since the thread pool management unit 41 is the execution subject of processing, the description of the subject is omitted.
<Step 301>
The event notification of the application start request from the user or the event notification from the thread monitoring unit 43 is received. A request event from the user by the console and an event from the thread monitoring unit 43 described later are realized by using the function of the OS 21. For example, in the case of general-purpose Linux, the asynchronous event function of “select” API can be used.

<Step 302>
Check whether the received event notification is an application start request event or not. If the event notification is an application start request (Y), the process proceeds to step 303. If it is not an event notification of an application start request (N), that is, if it is an event notification from the thread monitoring unit 43, the process proceeds to step 311.

<Step 303>
An application identifier 44-A, a thread management parameter 46-B, and an application execution parameter 46-C are received from the user. These parameters are set by the user when the event notification of the A51 start request from the user in the previous step 302 is performed.

<Step 304>
The thread identifier 45-C in which the value of the execution application identifier 45-D in the thread management table 45 is “0” is read.

<Step 305>
In the thread event table 46, the thread management parameter 46-B and the application execution parameter 46-C on the same line as the thread identifier 46-A having the identifier name of the thread identifier 45-C read in the previous step 304 are added to the previous one. The parameter received in step 303 is stored.

<Step 306>
The event notification is performed using the function of the OS 21 to the thread 61 having the identifier name of the thread identifier 45-C read in the previous step 304.

<Step 311>
The abnormal flag 45-B of the thread management table 45 is read.

<Step 312>
It is confirmed whether or not the value of the abnormality flag 45-B is a normal value “0”. If the normal value is “0” (Y), the process returns to step 301. If the abnormal value is “1” (N), the processing of the thread pool management 41 is terminated. This termination process includes a process for terminating the thread 61 generated in the previous step 211.

  Next, a processing flow by the thread processing unit 42 will be described. FIG. 8 is a diagram illustrating details of a processing flow executed by the thread processing unit 42. In each of the following steps, since the thread processing unit 42 is the execution subject of the process, the description of the subject is omitted.

<Step 401>
In the state waiting for the event notification from the thread pool management unit 41, after the necessary parameters are set in the thread event table 46 in the previous step 305, the event notification is sent from the thread pool management unit 41 in the previous step 306. Receive this event notification.

<Step 402>
The thread management parameter 46 -B of the thread event table 46 is read.

<Step 403>
The thread priority stored in 46-B1 and the resource access authority stored in 46-B2 are set using the functions of the OS 21 among the thread management parameters 46-B.

<Step 404>
The application execution parameter 46-C in the thread event table 46 is read.

<Step 405>
Proceed to the app execution process. The application execution process will be described later with reference to FIG.

<Step 406>
The thread priority and resource access authority set in the previous step 403 are restored. When the thread 61 is generated in the previous step 211, the default thread priority and resource access authority set in the OS 21 are restored.

  As described above, the process or thread scheduling method in the computer environment in which the conventional application 51 is operated externally can be realized by steps 404 and 406 before and after step 405. For example, a priority-based real-time schedule method can be easily realized by this embodiment.

Next, the application execution process in the previous step 405 will be described. FIG. 9 is a diagram illustrating details of a process flow of the application execution process. In each of the following steps, since the thread processing unit 42 is the execution subject of the process, the description of the subject is omitted.
<Step 501>
The application identifier is extracted from the entry_point name 46-C1 in the application execution parameter 46-C of the thread event table 46, and the application identifier 45-D in the same row as the thread identifier 45-C of the thread management table 45 is associated with the application identifier. Is stored. The own thread identifier 45-C can be acquired by the function of the OS 21, and matches the return value of the OS 21 stored in the previous step 211.
By this step 501, association between the binary of the application 51 to be executed and the thread 61 to be executed is performed.

<Step 502>
The application identifier extracted in the previous step 501 is stored in the application identifier 44-A of the application management table 44, and 'S' indicating the start state is stored in the application state 44-B.

<Step 503>
The function indicated by the entry_point name 46-C1 in the application execution parameter 46-C of the thread event table 46 is called, the argument 46-C2 is passed to the function, and the binary processing of the application 51 on the shared library 53 is executed.

<Step 504>
The return value from the binary processing of the application 51 in the previous step 503 is confirmed, and “E” indicating the end state is stored in the application state 44 -B of the application management table 44. By the previous step 502 and this step 504, the execution state of the start and end of the application 51 can be clearly managed in the middle layer of the OS 21, and it is easy to realize a highly reliable function using it.

<Step 505>
'0' is stored in the execution application identifier 45-D of the thread management table 45, and the thread management table 45 is initialized. As a result, an execution start request from another application 51 can be received.

  Finally, the processing flow by the thread monitoring unit 43 will be described. FIG. 10 is a diagram illustrating details of a processing flow executed by the thread monitoring unit 43. In each of the following steps, since the thread monitoring unit 43 is an execution subject of processing, description of the subject is omitted.

  This processing flow is processed using the monitoring thread 62. The binary processing of the application 51 executed by the thread 61 ends, and the application state 44-B of the application management table 44 is in the “E” state. In this state, the monitoring thread 62 monitors the thread 61 having a state where the execution application identifier 45 -D of the thread 61 is not yet “0” in the thread management table 45. Thereby, the execution state of the thread 61 can be monitored, and the thread 61 that can execute the start request of the application 51 from the user is prevented from being exhausted. Even if it is depleted, it is possible to execute processing such as starting a new thread 61. Further, this monitoring process may be performed at a constant cycle, or may be performed as an abnormality reconfirmation process by providing an abnormality counter.

<Step 601>
“0” is stored in the abnormality flag 45 -B of the thread management table 45 and is initialized.

<Step 602>
The application state 44-B of the first record in the application management table 44 is read.

<Step 603>
It is determined whether or not the read application state is “E” indicating the end. If it is the end “E” (Y), the process proceeds to step 604. If it is not the end “E” (N), the process proceeds to step 611.

<Step 604>
The application identifier 44 -A that accompanies the application state 44 -B read from the application management table 44 is read.

<Step 605>
It is confirmed whether or not the read application identifier 44 -A exists in the execution application identifier 45 -D of the thread management table 45.

<Step 606>
If it exists (Y), the process proceeds to step 607. If it does not exist (N), the process proceeds to step 611.

<Step 607>
“1” indicating an abnormality is stored in the abnormality flag 45 -B of the thread management table 45.

<Step 608>
An event notification is sent to the thread pool management unit 41 by the function of the OS 21. Further, in response to this event notification, the processing of the previous step 311 is executed in the thread pool management unit 41.

<Step 611>
It is confirmed whether or not processing has been performed up to the last row of the application management table 44. If it is not the last line (Y), the process proceeds to step 612, and if it is the last line (N), the process proceeds to step 602.

<Step 612>
The application state 44-B in the next row of the application management table 44 is read, and the process returns to step 603.

DESCRIPTION OF SYMBOLS 11 ... Arithmetic unit, 11-A ... CPU, 12 ... Storage device, 21 ... OS,
31 ... Shared library (Lib) conversion unit, 32 ... Converted application (AP) storage location storage unit,
41 ... Thread pool management unit, 42 ... Thread processing unit, 43 ... Thread monitoring unit,
44 ... Application (AP) management table, 45 ... Thread management table,
46 ... Thread event table, 51 ... Existing application (AP) source,
52 ... rewrite assembly code, 53 ... a shared library in which the application 51 is functionalized,
61 ... Thread, 62 ... Monitoring thread

Claims (5)

A shared library for functionalizing an application and storing it as a functionalized application is generated, and a thread for executing the functionalized application is generated in advance and pooled. Associating an execution target application with a free thread selected from the pooled threads, and executing the functionalized application on the common library corresponding to the execution target application using the related free thread How to run the featured app. An application execution method according to claim 1,
When pooling the thread, a parameter for execution control of the thread is initialized with respect to a set number of threads, and the application execution method is characterized in that: An application execution method according to claim 2,
A method for executing an application, comprising: notifying the associated empty thread of the parameter related to the execution target application for which the start request has been made. It is the execution method of the application of any one of Claim 1 to 3,
A method for executing an application, wherein a priority and a resource access authority of the associated free thread are set. An application execution method according to any one of claims 1 to 4, wherein:
A method for executing an app, comprising: monitoring whether the thread associated with the app that has been executed has been executed and returned to an initialized state.

Images