JP7015203B2 - How to run the app - Google Patents

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 information systems and control systems, it is required to manage the reliable execution state of the application to be operated. 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 control system, in order to clearly grasp the end state of the application and surely release the computer resources such as memory secured by the application to guarantee the high reliability of the system, it is inside the OS. It is necessary to devise a method for obtaining the information of.

In addition, since there are many needs to minimize the development investment for porting an application by changing the generation of hardware and OS, it is desirable that the management of the application execution state is realized in the middle layer or the application layer on the OS. As one of the methods, for example, in the case of Linux (registered trademark) , the execution status of the application can be monitored by utilizing 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 status notification event from the OS, and in order not to miss the event, the corresponding application is executed with high priority. There is a need.

On the other hand, it is difficult to operate an application such as a control system in which performance interference occurs due to an application other than control processing. Therefore, there is a need for a method that can manage the execution status of the application operated in the middle layer or application layer on the OS. For example, "Java VM" (Java is a registered trademark) described in Non-Patent Document 1 is a technology that can control and manage an application written in Java language in the middle layer, and monitors the execution state of the application. Is easy. However, it is difficult to operate apps written in languages other than Java, and most of the apps are written in C or assembler, especially in environments where real-time performance requirements are strict, such as control systems. The application of the technology is difficult.

Further, Patent Document 1 discloses a technique of having a plurality of event notification threads as an event management means for managing event information of an application and controlling the operation of a plurality of applications by using the event management means.
Further, Patent Document 2 discloses a technique relating to a procedure for linking another process such as reading internal information of a thread when compiling the thread.

Japanese Unexamined Patent Application Publication No. 2003-280926 Japanese Unexamined Patent Publication No. 2005-242879

The Java Virtual Machine Specification

In a system that operates a mission-critical application that requires high reliability of the system, the execution environment of the application that can reliably manage and monitor the execution status of the application is realized in the middle layer or the application layer on the OS, and the application is executed. There is a need to facilitate the realization of the required high reliability functions depending on the state. Furthermore, it will be necessary to port apps due to changes in hardware and OS generations, but there is a need to minimize development investment for that purpose.
In order to respond to them, an object of the present invention is to realize and provide an execution platform of an application that does not depend on special hardware or OS functions.

In the present invention, in order to solve the above-mentioned problems, a shared library for functionalizing an application and storing it as a functionalized application is generated, a thread for executing the functionalized application is generated in advance and pooled, and a user requests to start the application. In response to this, the application to be executed that received the start request is associated with a free thread selected from the pooled threads, and the function on the shared library corresponding to the application to be executed is used using the associated free thread. It is characterized by running a computerized application.

According to the present invention, in a control system with strict processing performance requirements, it is possible to manage and monitor the execution state of an application without depending on a special hard way air or OS function. In addition, since it does not require modification of the source level of the application, it is possible to manage and monitor the execution state of the managed application in the middle layer and the application layer, and in particular, the release of computer resources realized when the application is terminated. It becomes easy to realize functions that require high reliability such as.

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

Compiling the source of the processing logic of an application that runs on a normal OS produces a binary that runs as a single process on the OS. In the present invention, the application whose execution state is to be managed is compiled as one function instead of one process on the OS and generated as a shared library of the application which can be loaded in the memory of the computer, and this functionalized application is generated. Create and operate a thread to execute.

Further, in the present invention, since the application to be monitored is treated as one function in the thread, the execution end of the corresponding application is surely grasped at the end of the function. In addition, the entry point of the functionalized app and the arguments to pass to that app are specified or set in an external table, one thread is selected from the thread pool, and that thread is functionalized from that external table. Get the parameters for executing the binary.

Hereinafter, examples of the present invention will be described in detail with reference to the drawings. In the drawings, the notation of the application and the concert is "AP" and "Lib".

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

The structure of the software program will be described.
The OS 21 has a function of scheduling applications running on the OS, an exclusive control function of computer resources such as the arithmetic unit 11 and the storage device 12, and a synchronization event generation control function for operation control for cooperation between applications. Have. It also has the functions of a general-purpose OS such as Linux and Windows (registered trademark) .

The application 51 is a source file for generating a binary consisting of an instruction code that exists at least one and can be executed by the arithmetic unit 11. Further, the application 51 is converted into an assemble code by the compiler, and is converted into a binary that can be executed by the arithmetic unit 11. The application 51 converted into binary is executed by the OS 21 in a process unit managed by the OS 21.

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

The thread pool management unit 41 generates and manages one or more threads 61 that execute the binary 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.

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

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 abnormal monitoring of the thread 61 is performed.

Each table (application management table 44, thread management table 45, and thread event table 46) will be described in order with reference to FIGS. 2 to 4.
FIG. 2 is a diagram showing 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 in which the conventional application 51 is operated. The application management table 44 allows the execution status of the application 51 to be monitored, and the highly reliable function required for the system can be realized. For example, release of computer resources allocated to the corresponding application. In this embodiment, the shared library unit 31 and the thread pool management unit 41 can operate in the middle layer on the OS 21.

The application management table 44 is composed of 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. The execution state of the application 51 includes'D'indicating that the thread 61 for executing the application 51 is assigned,'S' indicating the start of execution of the binary of the application 51, and the execution of the binary of the application 51. It has each value of "R" and "E" indicating the end of execution of the application 51. Here, the execution states of ‘S’ and ‘E’ are set by the thread processing unit 42 processed by the thread 61. Other states are set by the thread pool management unit 41 according to the processing content of the binary of the application 51.

FIG. 3 is a diagram showing the configuration of the thread management table 45. The thread management table 45 has a maximum number of threads 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 the processing result in the thread monitoring unit 43 of the monitoring thread 62. , 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 a value of 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 the parameters passed between the thread pool management unit 41 and the thread 61, and there are as many record rows as there are threads 61. Each record row is composed of a thread identifier 46-A for identifying a thread to which the thread pool management unit 41 wants to pass an event, and a parameter to be passed.

This parameter includes a thread management parameter 46-B and an app (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 parameters 46-C are used to execute the functionalized binary of the application 51 executed by the thread 61.

The thread priority 46-B1 in the thread management parameter 46-B manages the thread pool of the middleware layer on the OS 21 by using the scheduler provided in the OS on the computer environment in which the conventional application 51 is executed as one process. This is a parameter to be realized in the unit 41. For example, in the priority-based real-time schedule, the priority may be set by the priority 46-B1. The set priority is reflected in the OS 21 as the priority of the thread 61 that executes the functionized binary on the shared library 53 by the shared library 31 of the conventional application binary. As a result, the scheduler that operates the conventional application can be flexibly realized externally.

Further, since the application execution parameters 46-C can be passed to the thread 61, the processing of the conventional application can be realized even with a functionized binary. For example, the application of the web server can be made into a function by the shared library unit 31 and executed by the thread 61, and the start and end of the process can be reliably monitored in the middle layer of the OS 21. The details of the start and end monitoring processing of the application processing will be described later with reference to FIG.

Next, the processing flow by the shared library unit 31 will be described. FIG. 5 is a diagram showing 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 the execution subject of the process, the description of the subject is omitted.

<Step 101>
Receives from the user the app identifier of the app 51 for which the functionalized binary is to be created.

<Step 102>
The location for storing the intermediate file for creating the functionalized binary from the source file of the application 51 specified in advance 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 by the compiler into the assemble code AP 52 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 OS21. For example, in the case of general-purpose Linxu, it corresponds to the compiler "gcc (GNU Compiler Collection)".

<Step 104>
The assemble code AP52 is read, the "_main" symbol of the entry_point process is searched from this assemble 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", it is converted from "_main" to "_AP1_main". However, regardless of the conversion format, it may be any one that can be associated with the application 51.

<Step 105>
Search the assemble code for the "_exit" symbol of the end processing, and if there is this symbol, replace it with the return processing from the function. For example, replace it with the "pop" and "ret" assemblers of the stack frame.

<Step 106>
The shared library generation option of the compiler compiles all the converted assemble code AP52 stored as an intermediate file in the converted application storage location storage unit 32, and generates the shared library 53. For example, in the case of "gcc" above, use the "-shared" option.

<Step 107>
It is loaded onto the RAM of the storage device 12 so that the thread 61 executing the binary of the functionalized application 51 on the shared library 53 can access it. For example, it is possible to utilize the POSIX API or, in the case of standard Linux, the "ldconfig" command.

Next, the processing flow by the thread pool management unit 41 will be described. FIG. 6 is a diagram showing details of the 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 the process, the description of the subject is omitted.

<Step 201>
The thread MAX number 45-A of the thread monitoring table 45 is read and stored in an internal variable. It is assumed that the thread MAX number 45-A is set by the user, and is set to "32" in this embodiment.

<Step 202>
Initialize the internal variables of the thread generation counter (ct) (ct ← 0).

<Step 203>
It is confirmed whether or not the value of the thread generation counter (ct) exceeds the value of the thread MAX number 45-A. If it exceeds, the process proceeds to (Y) and step 204, and if 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 by 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. 7.

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

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

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

<Step 214>
Initialize the execution application (AP) identifier 45-D of the thread generation counter th in the thread management table 45 with '0'.

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

Next, the processing flow of the application start processing of the previous step 205 will be described. FIG. 7 is a diagram showing details of the processing flow of the application start processing. In each of the following steps, since the thread pool management unit 41 is the execution subject of the process, the description of the subject is omitted.
<Step 301>
Receive the event notification of the application start request from the user or the event notification from the thread monitoring unit 43. The request event from the user by the console and the 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 the "select" API can be used.

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

<Step 303>
The application identifier 44-A, the thread management parameter 46-B, and the 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>
Read the thread identifier 45-C in which the value of the execution application identifier 45-D in the thread management table 45 is '0'.

<Step 305>
In the thread event table 46, the thread management parameter 46-B and the application execution parameter 46-C in the same row as the thread identifier 46-A having the identifier name of the thread identifier 45-C read in the previous step 304 are displayed first. The parameters received in step 303 of the above are stored.

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

<Step 311>
Read the error flag 45-B of the thread management table 45.

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

Next, the processing flow by the thread processing unit 42 will be described. FIG. 8 is a diagram showing 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 processing, the description of the subject is omitted.

<Step 401>
While 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 thread pool management unit 41 notifies the event in the previous step 306. Receive this event notification.

<Step 402>
Read the thread management parameter 46-B of the thread event table 46.

<Step 403>
From the thread management parameters 46-B, the priority of the thread stored in 46-B1 and the resource access authority stored in 46-B2 are set by using the function of OS21.

<Step 404>
Read the application execution parameters 46-C in the thread event table 46.

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

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

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

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

<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 the'S'indicating the start state is stored in the application state 44-B.

<Step 503>
The function indicated by 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 by 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 becomes easy to realize a highly reliable function using the execution state.

<Step 505>
'0' is stored in the execution application identifier 45-D of the thread management table 45, and the initialization state is set. This makes it possible to receive an execution start request from another application 51.

Finally, the processing flow by the thread monitoring unit 43 will be described. FIG. 10 is a diagram showing 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 the execution subject of the process, the 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 is completed, 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 whose execution application identifier 45-D of the thread 61 is not yet '0' in the thread management table 45. As a result, 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 exhausted, it is possible to carry out a process such as starting a new thread 61. Further, this monitoring process may be performed at regular intervals, or may be performed as an abnormality reconfirmation process by providing an abnormality counter.

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

<Step 602>
Read the application status 44-B of the first record of the application management table 44.

<Step 603>
Judge whether the read application status is'E'indicating the end. If the end is'E', the process proceeds to step 604 (Y), and if the end is not'E', the process proceeds to step 611 (N).

<Step 604>
The application identifier 44-A in the same bank as 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, and 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 is notified to the thread pool management unit 41 by the function of OS21. Further, by this event notification, the processing of the previous step 311 is executed in the thread pool management unit 41.

<Step 611>
Check whether the 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.

11 ... Arithmetic logic 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 ... App (AP) management table, 45 ... Thread management table,
46 ... Thread event table, 51 ... Existing application (AP) source,
52 ... Rewrite assemble code, 53 ... Shared library that functions application 51,
61 ... thread, 62 ... monitoring thread

Claims (5)

A shared library that functions an application and stores it as a functionalized application is generated, a thread that executes the functionalized application is generated in advance and pooled, and a start request of the application is received from a user, and the start request is made. To associate the application to be executed with a free thread selected from the pooled threads, and execute the functionalized application on the shared library corresponding to the application to be executed using the associated free thread. How to run an app that features. The method for executing the application according to claim 1.
A method of executing an application, characterized in that when pooling the threads, parameters related to execution control of the threads are initialized for the set number of threads. The method for executing the application according to claim 2.
A method of executing an application, which comprises notifying the associated free thread of the parameters related to the application to be executed for which the start request has been made. The method for executing the application according to any one of claims 1 to 3.
A method of executing an application, characterized in that the priority and resource access authority of the thread are set for the associated free thread. The method for executing the application according to any one of claims 1 to 4.
A method of executing an application, which monitors whether or not the thread associated with the application whose execution has been completed has been executed and has returned to the initialized state.

Images