JP6946820B2 - Electronics, controls and programs - Google Patents

Description

The present invention relates to electronic devices, control devices and programs.

Patent Document 1 provides a multi-processor control method that can flexibly deal with the addition of a new instruction and data transmission method or a change of either processor to a processor having another physical limitation. In a multi-processor system in which a processing device having a second processor is connected to a processing device having a first processor, the conversion between the internal notation of the first processor and the standard notation of the system is to be provided. The second processor has an execution program name, a procedure name, and a data part, and the data part has a variable length according to the type of the execution program and the procedure. The request information of the internal notation is converted into the standard notation by the first conversion means and sent, and the response information of the standard notation having a variable length according to the type of the response is received and converted into the internal notation by the first conversion means. 1. Processing means, request information buffer holding variable length request information converted into standard notation from the first processing means, and response holding standard notation response information having variable length depending on the type of response. A second processing means that is activated by the information buffer and the request information from the first processing means and retrieves the request information from the request information buffer, and a second that converts the internal notation of the second processor and the standard notation of the system. It has a conversion means, analyzes the request information fetched from the request information buffer, executes the execution program specified by the request information on the second processor, and executes the execution result according to the type of response. By creating the response information of the internal notation with variable length, converting the response information from the internal notation to the standard notation by the second conversion means and holding it, and by completing the execution of the second processing means. It is disclosed that the response sending means which is activated and takes out the response information from the second processing means and sends it to the response information buffer is provided.

Patent Document 2 has an object of preventing a malfunction when a program is restarted on one of the processors after passing a command between processors of a multi-processor system, and a first OS (Operating System) is executed. The first control means includes a control means, a second control means for executing the second OS, and a device controlled by the second control means, and the first control means performs a function called by a process running on the first OS. A first conversion means for converting into a command commonly interpreted by the first OS and the second OS, and a command writing means for writing the command converted by the first conversion means into the storage area of the second control means. , When a notification is received indicating that the status indicating the result of execution of the system call of the second OS corresponding to the command written by the command writing means by the second control means has been written to the storage area. A status reading means for reading the status from the storage area, a second conversion means for converting the status read by the status reading means into a return value interpreted by the process, and returning the return value to the process. If the process is restarted after the command writing means writes the command and before the status is read by the status reading means, the read by the status reading means after the process is restarted. It is disclosed that it is provided with a status disposal means for discarding the status.

Japanese Patent No. 2976576 Japanese Unexamined Patent Publication No. 2015-005097

There is a multiprocessor control technology that controls a plurality of OSs and executes different functions on different devices at the same time. Since this multiprocessor control technology does not consider executing one type of function on a plurality of different devices at the same time, it is not possible to identify the thread that called the function that is the source of the command.
An object of the present invention is to provide an electronic device, a control device, and a program that can convert a function into a command by adding information that can identify the thread that called the function.

The gist of the present invention for achieving such an object lies in the inventions of the following items.
The invention [1] includes a first control means for executing control by the first OS, a second control means for executing control by the second OS, and a device controlled by the second control means, and the first control. The means were converted by the first conversion means for converting the function called by the process running on the first OS into a command commonly interpreted by the first OS and the second OS, and the first conversion means. A status indicating a command writing means for writing a command to the storage area of the second control means and a status indicating the result of execution of the system call of the second OS corresponding to the command written by the command writing means by the second control means. The status reading means that reads the status from the storage area when notified that the status has been written to the storage area, and the return value that the process interprets the status read by the status reading means. A second conversion means for converting and returning the return value to the process is provided, a plurality of threads are executed in the process, the function is called by the thread, and the first conversion means is When the function can be executed multiple times, it is converted into a command to which the thread identification information for identifying the thread is added, the status reading means reads the thread identification information together with the status, and the second conversion means reads the status. An electronic device that converts a status into a return value interpreted by the thread according to the thread identification information read by the reading means.

The invention [2] is the electronic device according to the invention [1] , wherein the first conversion means converts the thread identification information into a command to which the thread identification information is added when the thread identification information is added to the function. be.

According to the invention [3] , when the thread identification information is not added to the function, the first conversion means generates the thread identification information and converts the generated thread identification information into a command to which the thread identification information is added . 1] The electronic device according to the above.

The invention [4] is the electronic device according to the invention [1] , wherein the first conversion means returns an error to the thread that called the function when the function is not multi-executable.

According to the invention [5] , when the first conversion means adds the thread identification information to the function and the function cannot be executed multiple times, the thread identification information is invalidated and the function is used. The electronic device according to the invention [4] , which returns an error to the calling thread.

In the invention [6] , the first conversion means returns an error to the thread that called the function when the thread identification information is not added to the function and the function cannot be executed multiple times. The electronic device according to the invention [4].

According to the invention [7] , when the process is restarted after the command writing means writes the command and before the status is read by the status reading means, the status reading means is restarted after the process is restarted. The electronic device according to any one of the inventions [1] to [6] , further comprising a status disposal means for discarding the status read by.

The invention [8] includes a flag storage means for storing a flag indicating ON when the command is written in the storage area and OFF when the process is restarted for each type of the command. , The status discarding means discards the status when the flag stored in the flag storage means indicates OFF in association with the type of command corresponding to the status after the status is read by the status reading means. , The electronic device according to the invention [7].

The present invention [9] stores a counter indicating the number of times a command is written by the command writing means minus the number of times a status read corresponding to the type of the command is read by the status reading means for each type of command. The status discarding means includes counter storage means, and after reading the status by the status reading means, the flag stored in the flag storage means is valid in association with the type of the command corresponding to the status. The electronic device according to the invention [8] , wherein the status is discarded when the counter stored in the counter storage means does not show 1 in association with the type of the command corresponding to the status.

In the invention [10] , a command holding means for holding a command converted by the first conversion means and a system call of the second OS corresponding to the command after writing the command by the command writing means are the first. 2 From the invention [7] further provided with a command rewriting means for writing the command held by the command holding means to the storage area when the second OS is restarted before being executed by the control means. The electronic device according to any one of [9].

According to the invention [11] , when the status corresponding to the open command is read by the status reading means after the second OS is restarted, the command rewriting means takes a file descriptor included in the status as an argument. The electronic device according to the invention [9] or [10] , which writes a command to be executed in the storage area.

According to the invention [12] , the device is an electronic device according to any one of the inventions [1] to [11] , which forms an image based on image data.

The invention [13] is converted by the first conversion means for converting a function called by a process running on the first OS into a command commonly interpreted by the first OS and the second OS, and the first conversion means. The command writing means for writing the command to the storage area of the second control device that executes the second OS, and the second system call of the second OS corresponding to the command written by the command writing means. A status reading means for reading the status from the storage area when a notification indicating that the status indicating the result of execution by the control device has been written to the storage area is received, and the status read by the status reading means. Is converted into a return value interpreted by the process, and a second conversion means for returning the return value to the process is provided. A plurality of threads are executed in the process, and the function is called by the thread. When the function can be executed multiple times, the first conversion means converts the function into a command to which the thread identification information for identifying the thread is added, and the status reading means reads the thread identification information together with the status. The second conversion means is a control device that converts the status into a return value interpreted by the thread according to the thread identification information read by the status reading means.

The invention [14] comprises a first conversion means for converting a computer into a command called by a process running on the first OS into a command commonly interpreted by the first OS and the second OS, and the first conversion means. The command writing means for writing the command converted by the second OS to the storage area of the second computer executing the second OS, and the first system call of the second OS corresponding to the command written by the command writing means. A status reading means for reading the status from the storage area when a notification indicating that the status indicating the result of execution by the computer of 2 has been written to the storage area is received, and the status reading means read by the status reading means. A plurality of threads are executed in the process by converting the status into a return value interpreted by the process and functioning as a second conversion means for returning the return value to the process. When the function can be executed multiple times, the first conversion means converts the function into a command to which the thread identification information for identifying the thread is added, and the status reading means outputs the thread identification information together with the status. Reading, the second conversion means is a program that converts the status into a return value interpreted by the thread according to the thread identification information read by the status reading means.

According to the electronic device of the invention [1] , information that can identify the thread that called the function can be added, and the function can be converted into a command.

According to the electronic device of the invention [2] , when the thread identification information is added to the function, it can be converted into a command to which the thread identification information is added.

According to the electronic device of the invention [3] , when the thread identification information is not added to the function, the thread identification information can be generated and converted into a command to which the generated thread identification information is added.

According to the electronic device of the invention [4] , if the function cannot be executed multiple times, an error can be returned to the thread that called the function.

According to the electronic device of the invention [5] , when the thread identification information is added to the function and the function cannot be executed multiple times, the thread identification information is invalidated and an error occurs in the thread that called the function. Can be replied.

According to the electronic device of the invention [6] , when the thread identification information is not added to the function and the function cannot be executed multiple times, an error can be returned to the thread that called the function.

According to the electronic device of the invention [7] , it is possible to prevent a malfunction when a program is restarted on any of the processors after passing a command between the processors of the multiprocessor system.

According to the electronic device of the invention [8] , it is possible to determine whether or not to discard the status for each type of command corresponding to the read status.

According to the electronic device of the invention [9] , even if there is a problem with the processor without restarting the program, it is possible to prevent the processor from malfunctioning.

According to the electronic device of the invention [10] , it is possible to prevent a malfunction when a program is restarted on any of the processors after passing a command between the processors of the multiprocessor system.

According to the electronic device of the invention [11] , it is possible to prevent the file from becoming unidentifiable after the second OS is restarted.

According to the electronic device of the invention [12] , it is possible to prevent a malfunction when a program is restarted on any of the processors after passing a command between the processors of the multiprocessor system.

According to the control device of the invention [13] , information that can identify the thread that called the function can be added, and the function can be converted into a command.

According to the program of the invention [14] , the function can be converted into a command by adding information that can identify the thread that called the function.

An example of a conventional system (multiple call prohibition / single processor) is shown. An example of a conventional system (multiple call prohibition / multiprocessor) is shown. An example of a conventional system (multiple call permission / single processor) is shown. An example of the system (multiple call permission / multiprocessor) of this embodiment is shown. It is a block diagram which shows the hardware configuration example of the computer which realizes this embodiment. An example of the command format in the conventional system is shown. An example of the status format in the conventional system is shown. An example of the command format is shown. An example of the status format is shown. An example of the system (multiple execution discrimination function) in the present embodiment is shown. An example of the multiple execution discrimination function in this embodiment is shown. An example of a configuration breakdown diagram for each command ID of the multiple execution determination function in the present embodiment is shown. An example of an embodiment (unnecessary status disposal function) in this embodiment is shown. An example of an unnecessary status discard function in this embodiment is shown. An example of a configuration breakdown diagram for each command ID of the unnecessary status discard function in this embodiment is shown. An example of an embodiment (command reissue function) in this embodiment is shown. An example of the command reissue function in this embodiment is shown. An example of the configuration breakdown diagram for each command ID of the command reissue function in the present embodiment is shown. An example of the configuration breakdown diagram of the open command reissue function of the command reissue function in the present embodiment is shown. An example of the command issuance processing sequence of the multiple execution discrimination function is shown. An example of the command issuance processing sequence of the multiple execution discrimination function is shown. An example of the initialization processing sequence of the unnecessary status discard function is shown. An example of the processing sequence in the open method of the unnecessary status discard function is shown. An example of the processing sequence in the write method of the unnecessary status discard function is shown. An example of the processing sequence in the read method of the unnecessary status discard function is shown. An example of the initialization processing sequence of the command reissue function is shown. An example of the processing sequence in the write method of the command reissue function is shown. An example of the processing sequence in the read method of the command reissue function is shown.

An example of a preferred embodiment for realizing the present invention will be described with reference to the drawings.
The module generally refers to parts such as software (computer program) and hardware that can be logically separated. Therefore, the module in this embodiment refers not only to the module in the computer program but also to the module in the hardware configuration. Therefore, in the present embodiment, a computer program for functioning as those modules (a program for causing the computer to execute each procedure, a program for causing the computer to function as each means, and each function for the computer). It also serves as an explanation of the program), system and method for realizing the above. However, for convenience of explanation, words equivalent to "remember" and "remember" are used, but these words are stored in a storage device or stored when the embodiment is a computer program. It means that it is controlled so that it is stored in the device. Further, the modules may have a one-to-one correspondence with the functions, but in mounting, one module may be configured by one program, a plurality of modules may be configured by one program, and conversely, one module may be configured. May be composed of a plurality of programs. Further, the plurality of modules may be executed by one computer, or one module may be executed by a plurality of computers by a computer in a distributed or parallel environment. In addition, one module may include another module. In addition, hereinafter, "connection" is used not only for physical connection but also for logical connection (data transfer, instruction, reference relationship between data, etc.). "Predetermined" means that it is determined before the target process, not only before the process according to the present embodiment starts, but also after the process according to the present embodiment starts. However, if it is before the target process, it is used with the intention that it is determined according to the situation / state at that time or according to the situation / state up to that point. When there are a plurality of "predetermined values", they may be different values, or two or more values (including all values, of course) may be the same. Further, the description "if A, do B" is used to mean "determine whether or not it is A, and if it is determined to be A, do B". However, this excludes cases where it is not necessary to determine whether or not it is A. Further, when a thing is listed such as "A, B, C", it is an example list unless otherwise specified, and includes a case where only one of them is selected (for example, only A).
In addition, a system or device is configured by connecting a plurality of computers, hardware, devices, etc. by communication means such as a network (including a one-to-one correspondence communication connection), and one computer, hardware, device, etc. It also includes cases where it is realized by such means. "Device" and "system" are used as synonymous terms. Of course, the "system" does not include anything that is nothing more than a social "mechanism" (social system) that is an artificial arrangement.
In addition, for each process by each module or when multiple processes are performed in the module, the target information is read from the storage device, and after the processes are performed, the process results are written to the storage device. be. Therefore, the description of reading from the storage device before processing and writing to the storage device after processing may be omitted. The storage device here may include a hard disk, a RAM (Random Access Memory), an external storage medium, a storage device via a communication line, a register in a CPU (Central Processing Unit), and the like.

The present embodiment has a so-called multiprocessor system including two CPUs as a basic configuration, and here, a basic software configuration of a single processor system and a multiprocessor system will be described. In the following description, for convenience, software components will be the main body of operation.
The technique described in Patent Document 1 supports a plurality of types of request information and its response information between the first processor and the second processor, but executes a plurality of one type of request information and its response information. It is not supposed to be done. Further, although the technique described in Patent Document 2 supports exception handling, it is not assumed that one type of request information and a plurality of response information thereof are executed.

FIG. 1 shows an example of a conventional system (multiple call prohibition / single processor). The OS (Operating System) includes a driver 8 that controls a device (not shown). Process 1 is a process that constitutes an application program. In process 1, thread [1]: 2, thread [2]: 3, and thread [3]: 4 call the driver 8 by system call 10 via API (Application Programming Interface) 5, 6, and 7, respectively. The called driver 8 executes a process according to the content of the system call 10, and returns a return value 11 representing the execution result of each process to the process 1 via APIs 5, 6 and 7. This system shows a system that prohibits multiple calls on a single processor.

FIG. 2 shows an example of a conventional system (multiple call prohibition / multiprocessor). However, it can be the base system of this embodiment. Since the process 1 operates on the first control means side and the driver 8 operates on the second control means side, the threads [1]: 2, threads [2]: 3, and threads [3]: 4 in the process 1 are , The system call 10 is executed via the shared library 15 of the first OS17. Specifically, the system call 10 called by APIs 12, 13 and 14 may be associated with the function 21 interpreted by the library 15 in advance, or the process 1 is configured to directly call the function 21. You may. When the function 21 is called, the library 15 converts the function 21 into a command 29 that is commonly interpreted by the first OS 17 and the second OS 9 in order to pass the contents of the function 21 to the second OS 9, and the OS-to-OS communication driver. Pass to 16. The inter-OS communication driver 16 transmits this command 29 to the inter-OS communication driver 19 via the PCle 18 by inter-OS communication. The interface for inter-OS communication may be any method, but in the present embodiment, an example using PCI (Peripheral Component Interconnect) Express (registered trademark, hereinafter abbreviated as PCIe) will be shown.

The inter-OS communication driver 19 passes the received command 29 to the task 20. Upon receiving the command 29, the task 20 converts the command 29 into a system call 10 interpreted by the driver 8, and calls the driver 8 by the system call 10 via APIs 5, 6 and 7, respectively. The called driver 8 executes a process according to the content of the system call 10, and returns a return value 11 representing the execution result of each process to the task 20 via APIs 5, 6, and 7.

The task 20 that has received the return value 11 converts the return value 11 into a status 30 that is commonly interpreted by the first OS 17 and the second OS 9 in order to pass the contents of the return value 11 to the first OS 17, and an inter-OS communication driver. Pass to 19. The inter-OS communication driver 19 transmits this status 30 to the inter-OS communication driver 16 by inter-OS communication. The inter-OS communication driver 16 passes the received status 30 to the library 15. The library 15 that has received the status 30 converts the status 30 into a return value 22 interpreted by the process 1, and returns the return value 22 to the process 1 via the APIs 12, 13, and 14, respectively. In this way, the multiprocessor system obtains the same processing result as when process 1 directly calls the driver 8 in the single processor system.

FIG. 3 shows an example of a conventional system (multiple call permission / single processor). In the system example shown in FIG. 1, the API 5 was between the driver 8 and one thread [1]: 2, but in the system example shown in FIG. 3, the API 5 is between the driver 8 and two threads (thread [1]: 2. 2. Between threads [2]: 3). As a result, the system call 10 can be executed simultaneously with the thread [1]: 2 and the thread [2]: 3. That is, a plurality of system calls 10 can be executed simultaneously for one API.

FIG. 4 shows an example of the system (multiple call permission / multiprocessor) of the present embodiment. In the system example shown in FIG. 2, the API 12 was between the library 15 and one thread [1]: 2, and the API 5 was between the driver 8 and only one task 20, but in the system example shown in FIG. , API 12 is between library 15 and two threads (thread [1]: 2, thread [2]: 3), API 5 is driver 8 and two cotasks (cotask [1]: 25, cotask [2]: It is between 26). As a result, the function 21 can be executed simultaneously in the thread [1]: 2 and the thread [2]: 3. That is, a plurality of functions 21 can be executed simultaneously for one API.
The first control means 100 that executes control by the first OS is composed of a process 1, an API 12, an API 13, a library 15, an inter-OA communication driver 16, and a first OS 17. The second control means 200 is composed of a second OS 9 having an inter-OA communication driver 19, a task 20, API 5, API 6, and a driver 8.
The library 15 converts the function 21 called by the process 1 running on the first OS 17 into a command 29 that is commonly interpreted by the first OS 17 and the second OS 9. Then, the converted command is written in the storage area accessible to the second OS9.
Then, when a notification indicating that the status 30 indicating the result of execution by the device 300 controlled by the driver 8 of the system call of the second OS 9 corresponding to the written command has been written to the storage area is received, the notification is received. Read status 30 from the storage area. Next, the read status 30 is converted into a return value 22 interpreted by the process, and the return value 22 is returned to the process 1.
In this case, a plurality of threads (in the example of FIG. 4, thread [1]: 2, thread [2]: 3, thread [3]: 4) are executed in process 1, and the function 21 is the thread. Calls. The library 15 determines whether or not the function 21 can be executed multiple times, and if it is determined that the function 21 can be executed multiple times, converts it into a command 29 to which thread identification information for identifying a thread is added. Then, the thread identification information is read together with the status 30, and the status 30 is converted into a return value 22 interpreted by the thread according to the read thread identification information.

In the present embodiment, each library that uses inter-OS communication is provided with a multiple execution determination function that determines whether or not each function supported by each library can be executed multiple times.
Then, when the user ID is specified by the higher-level software (process 1 or thread), the library 15 that uses the inter-OS communication determines whether or not the specified function 21 can be executed multiple times by the multiple execution determination function. do. Then, when it is feasible, the user ID is valid and the command 29 to which the user ID is added is issued. If the user ID is not specified by the higher-level software (process 1 or thread) and the function can be executed by the multiple execution determination function, the user ID is assigned and the user ID is added to the command 29. Is issued.
Further, when the user ID is specified by the higher-level software (process 1 or thread), the library 15 that uses inter-OS communication determines whether or not the specified function can be executed multiple times by the multiple execution determination function. .. Then, if it is not executable, the user ID is invalidated and an error is returned to the higher-level software (process 1 or thread). If the user ID is not specified by the higher-level software (process 1 or thread) and the function cannot be executed by the multiple execution determination function, an error is returned to the higher-level software (process 1 or thread).

By making it possible to execute one type of request information and its response information in a plurality of times by these processes, simultaneous execution is possible. Therefore, one type of request information and its response information are processed from a plurality of threads. (Parallel processing) becomes possible.
Furthermore, by prioritizing the specification of the user ID from the higher-level software without allocating the user ID only by the multiple execution determination function of the library, the final stage processing (continuous hardware in the driver running on the second processor). Processing etc.) can be fixed.

Next, the hardware configuration of the present embodiment will be described with reference to the example of FIG. The image forming apparatus 1000 is an example of the electronic device according to the present embodiment. The main components of the image forming apparatus 1000 are the first control means 100, the second control means 200, and the device 300. The first control means 100 controls the second control means 200. The second control means 200 controls the device 300. The image forming apparatus 1000 includes, for example, a copying machine, a fax machine, a scanner, a printer, a multifunction device (an image processing device having any two or more functions of a scanner, a printer, a copying machine, a fax machine, etc.) and the like. be.

The first control means 100 includes a computing device such as a CPU 101, a storage device such as a RAM (Random Access Memory) 102 or a ROM (Read Only Memory) 103, a communication I / F (Interface) 104, an HDD (Hard Disk Drive) 105, or the like. The external storage device and the LAN (Local Area Network) terminal 106 are provided, and these components are connected to the bus 110. The CPU 101 executes the program using the RAM 102 as a work area. A boot loader or the like is stored in the ROM 103. The communication I / F 104 is, for example, a PCIe slot, and is connected to the communication I / F204, which is a PCIe slot provided in the second control means 200, by a signal line. The HDD 105 stores the first OS 17, an application program, and the like. When the power is turned on to the image forming apparatus 1000, the CPU 101 reads the boot loader from the ROM 103 and sets the first OS 17 from the HDD 105 according to the procedure described in the boot loader. Read and execute. The first OS17 is, for example, Linux®. A signal line is connected to the LAN terminal 106, and the CPU 101 communicates with an external information processing device or the like via the LAN.

The second control means 200 includes an arithmetic unit such as CPU 201, a storage device such as RAM 202 and ROM 203, and communication I / F 204, and these components are connected to the bus 210. The CPU 201 executes the program using the RAM 202 as a work area. The second OS 9 is stored in the ROM 203, and the CPU 201 reads the second OS 9 from the ROM 203 and executes it according to an instruction from the first control means 100. The second OS 9 is, for example, an RTOS (Real Time OS), and has a driver function for controlling the device 300.

The image forming apparatus 1000 includes one or more devices 300. The device 300 is a device that forms an image based on image data, such as an image scanner 301, a printer 302, a UI (User Interface) 303, and a compression / decompression device 304. The number of devices may be any number. The image scanner 301 includes, for example, a light source, an optical system, an image pickup element, and the like (not shown), the light source irradiates the document with light, and the reflected light reflected by the document is incident on the image pickup element via the optical system. The image sensor generates and outputs a signal representing the image of the original. The printer 302 includes, for example, a print engine that forms a toner image based on image data, a storage unit that stores a recording medium such as paper, a transport mechanism that transports the recording medium along a transport path (not shown), and the like. An image based on the image data supplied from the first control means 100 to the second control means 200 is printed on a recording medium by an electrophotographic method. The UI 303 includes, for example, a touch panel, a keypad, and the like (not shown), and accepts operations by the user. On the touch panel, a virtual operator for the user to operate the image forming apparatus 1000, information indicating the state of the image forming apparatus 1000, and the like are displayed. The keypad includes a key for instructing the start and stop of the operation of the image forming apparatus 1000, a numeric keypad for inputting a number, and the like. The compression / decompression device 304 compresses the image read by the image scanner 301, or decompresses the received compressed image and converts it into an image that can be printed by the printer 302.

The hardware configuration of the image forming apparatus 1000 shown in FIG. 5 shows one configuration example, and the present embodiment is not limited to the configuration shown in FIG. 5, and the module described in the present embodiment is executed. Any configuration may be possible. For example, some modules may be configured with dedicated hardware (for example, Applied Special Integrated Circuit (ASIC), etc.), and some modules are in an external system and connected by a communication line. Further, a plurality of systems shown in FIG. 5 may be connected to each other by a communication line so as to cooperate with each other.

In the present embodiment, as shown in the example of FIG. 10, the inter-OS communication driver 16 and the inter-OS communication driver 19 exchange commands 29 and status 30 via the command buffer 1029 and the status buffer 1030. The command buffer 1029 and the status buffer 1030 may use the storage area of the RAM 202, or a memory different from the RAM 202 is provided in the second control means 200, and the storage areas of this memory are used as the command buffer 1029 and the status buffer 1030. May be used as. The command buffer 1029 and the status buffer 1030 are, for example, FIFO (First In, First Out) type buffers, and are FULL / NOT FULL / EMPTY / NOT EMPTY information representing the state of each storage area, and are inter-OS communication drivers by the interrupt 28. It has a function of notifying the 16 and the inter-OS communication driver 19.

As an example, an example in which process 1 calls the function 21 shown below will be described. In this example, the process 1 is configured to directly call the function 21 of the library 15, and the error check of the return value 22 of each function is omitted.
int param [4] = [0, 0, 0, 0];
fd = do_open (DRV_1, 0, 0); / * First function call * /
status = do_ioctl (fd, DRV_1_READ_PARAM, param); / * Second function call * /
status = do_close (fd); / * Third function call * /

FIG. 6 is a diagram showing the format of the command 29 in the conventional system. The command 29 is information that is commonly interpreted by the first OS 17 and the second OS 9, and includes a command header 31 and command data 32. When the process 1 calls the function 21, the processing routine of the library 15 corresponding to the function 21 generates the command data 32. The command data 32 is variable-length data including a command ID (Identifier) 39 and a parameter 40. The processing routine sets an identifier representing the type of command 29 in command ID 39 and sets the argument of the function 21 in parameter 40. The processing routine passes the command data 32 generated in this way to the inter-OS communication driver 16.

Here, the third argument of do_ioctl (), which is the second function to be called in the above function call example, is a pointer indicating the logical address of the storage area, but the first control means 100 and the second control means If the logical address is different from that of 200, even if this pointer is passed to the second control means 200 as it is, the second control means 200 cannot access the storage area pointed to by the pointer. At the time of generation, the storage area (4Byte × 4 = 16Byte) pointed to by the pointer is set as the parameter 40 instead of the value of the pointer. In the above example, since the area pointed to by the pointer is initialized with 0, the storage area set in the parameter 40 is also initialized with 0.

The inter-OS communication driver 16 that has received the command data 32 generates a command header 31 that is essential information for inter-OS communication with the inter-OS communication driver 19. The command header 31 includes a task ID 35, a communication path ID 36, a command ID 37, and a command size 38. The inter-OS communication driver 16 sets the identifier of the task 20 (or cotask [1]: 25) on the second OS 9 side that interprets the command data 32 in the task ID 35, and sets the identifier of the communication path 27 of the inter-OS communication as the communication path. The ID 36 is set, the set value of the command ID 39 of the command data 32 is set to the command ID 37, and the size of the command data 32 is set to the command size 38. The inter-OS communication driver 16 generates a command 29 by combining the command header 31 generated in this way with the command data 32, and writes the generated command 29 to the command buffer 1029 by inter-OS communication. Then, the inter-OS communication driver 16 notifies the inter-OS communication driver 19 of NOT EMPTY by the interrupt 28.

Upon receiving the NOT EMPTY notification, the inter-OS communication driver 19 reads the command 29 from the command buffer 1029, and determines the task (or cotask) for processing the command 29 by the task ID 35 of the command header 31. In this example, since the cotask [1]: 25 is the task for processing the command 29, the inter-OS communication driver 19 passes the command 29 to the cotask [1]: 25. The inter-OS communication driver 19 repeatedly passes the command 29 to the cotask [1]: 25 until the command buffer 1029 becomes empty, and when the command buffer 1029 becomes empty, the inter-OS communication driver 16 sends NOT EMPTY. Wait for notification.

Upon receiving the command 29, the cotask [1]: 25 converts the command data 32 into the system call 10 interpreted by the driver 8 and calls the driver 8 via the API 5. Here, as described above, the parameter 40 corresponding to do_ioctl () in the above function call example is not a pointer indicating a logical address, but a storage area (4Byte × 4 = 16Byte) pointed to by the pointer. [1]: 25 allocates the storage area on the memory of the second control means 200, initializes the secured storage area, and sets the pointer of the storage area as the third argument of the system call 10. The driver 8 executes the system call 10 and returns a return value 11 representing the execution result to the cotask [1]: 25. Cotasking [1]: 25 generates status 30 based on this return value 11.

FIG. 7 is a diagram showing the format of status 30 in the conventional system. The status 30 is information that is commonly interpreted by the first OS 17 and the second OS 9, and includes the status header 33 and the status data 34. The status data 34 is variable length data including the status ID 45 and the parameter 46. Cotasking [1]: 25 sets the status ID 45 to an identifier indicating the type of status corresponding to the system call 10. Here, the cotask [1]: 25 sets the status ID 45 so that the command ID 39 corresponding to the status ID 45 can be obtained by masking the most significant bit of the status ID 45 to 1. Cotasking [1]: 25 sets the return value 11 received from the driver 8 in parameter 46. Here, when the return value 11 indicates normal termination, data is written to the storage area pointed to by the pointer set in the third argument of the system call 10 corresponding to the second function do_ioctl () in the above function call example. Therefore, in the cotask [1]: 25, in addition to the return value 11, the data is also set in the parameter 46.

The status header 33 includes a task ID 41, a communication channel ID 42, a status ID 43, and a status size 44. The cotask [1]: 25 sets the setting value of the task ID 35 set in the command 29 to the task ID 41, and sets the setting value of the communication path ID 36 set in the command 29 to the communication path ID 42. Cotasking [1]: 25 sets the setting value of the status ID 45 of the status data 34 to the status ID 43, and sets the size of the status data 34 to the status size 44. The cotask [1]: 25 passes the status 30 generated in this way to the inter-OS communication driver 19. The inter-OS communication driver 19 that has received the status 30 writes the status 30 to the status buffer 1030. Then, the inter-OS communication driver 19 notifies the inter-OS communication driver 16 of NOT EMPTY by the interrupt 28.

Upon receiving the NOT EMPTY notification, the inter-OS communication driver 16 reads the status 30 from the status buffer 1030 by inter-OS communication, and determines the library that processes the status data 34 from the communication path ID 42 of the status header 33. In this example, since the library 15 processes the status data 34, the OS-to-OS communication driver 16 passes the status 30 to the library 15. The inter-OS communication driver 16 repeatedly passes the status 30 to the library 15 until the status buffer 1030 is empty, and when the status buffer 1030 is empty, the inter-OS communication driver 19 notifies NOT EMPTY. Wait for

Upon receiving the status 30, the library 15 converts the status data 34 into the return value 22 interpreted by the process 1 and returns the return value 22 to the process 1. Here, since the status data 34 corresponding to the second function do_ioctl () in the above function call example is set with data in addition to the information to be converted to the return value 22, the library 15 is set to do_ioctl (). The data is written to the address specified by the third argument of ().

FIG. 8 shows an example of the command format used in this embodiment. The command 29 shown in the example of FIG. 8 is the command 29 shown in the example of FIG. 6 with the user ID 47 added. Specifically, the user ID 47 is added after the command ID 39 in the command data (variable length) 32 (before the parameter 40).
When the function 21 can be executed multiple times, the inter-OA communication driver 16 converts the function 21 into a command 29 to which thread identification information (hereinafter, also referred to as a user ID) for identifying a thread is added. Specifically, the inter-OS communication driver 16 determines whether or not the function 21 can be executed multiple times, and if it is possible to execute the function 21 multiple times, the user ID 47 provides thread identification information for identifying the thread that transmitted the function 21. Set to.
In this case, if the thread identification information is added to the function 21, the inter-OA communication driver 16 converts the thread identification information into a command 29 to which the thread identification information is added (the thread identification information is set in the user ID 47).
If the thread identification information is not added to the function 21, the inter-OA communication driver 16 generates the thread identification information and converts the generated thread identification information into a command 29 to which the generated thread identification information is added (the thread identification information is converted into the user). It may be set to ID47).
Further, the inter-OA communication driver 16 may return an error to the thread that called the function when the function 21 cannot be executed multiple times.
Further, when the thread identification information is added to the function 21 and the function 21 cannot be executed multiple times, the inter-OA communication driver 16 invalidates the thread identification information and sends the thread that called the function 21 to the thread. You may want to reply with an error.
Further, the inter-OA communication driver 16 may return an error to the thread that called the function when the thread identification information is not added to the function 21 and the function 21 cannot be executed multiple times. good.

FIG. 9 shows an example of the status format used in this embodiment. The status 30 shown in the example of FIG. 9 is the status 30 shown in the example of FIG. 7 with the user ID 48 added. Specifically, the user ID 48 is added after the status ID 45 (before the parameter 46) in the status data (variable length) 34. Cotasking [1]: 25 (or task 20) sets the thread identification information that identifies the thread that sent the function 21 (the thread that receives the status 30) in the user ID 48.

FIG. 10 shows an example of the system (multiple execution determination function) in the present embodiment.
As described above, there is a PCle18 between the first OS17 and the second OS9, and within the PCle18, communication of the command 29 and the status 30 is performed via the communication path 27. Then, in order to buffer the processing speed difference between the first OS 17 and the second OS 9, there are a command buffer 1029 which is a storage area for temporarily storing the command 29 and a status buffer 1030 which is a storage area for temporarily storing the status 30. The inter-OA communication driver 19 notifies the inter-OS communication driver 16 of the FULL / NOT FULL / EMPTY / NOT EMPTY information indicating the status of the command buffer 1029 and the status buffer 1030 by the interrupt 28.
There is a multiple execution determination module 1033 in the library 15.

FIG. 11 shows an example of the multiple execution discriminating function in the present embodiment.
The multiple execution determination module 1033 of the library 15 refers to the command group data 49 and determines whether or not the function 21 is capable of multiple execution.
The command group data 49 is composed of a plurality of command data 50. There are n types of commands 29 here. Each command data 50 has a data structure as shown in the example of FIG. FIG. 12 shows an example of a configuration breakdown diagram for each command ID of the multiple execution determination function in the present embodiment. As shown in the example of FIG. 12, the command data 50 is composed of a multiple execution number 51 and a lock [m]: 52. A value indicating whether or not the command can be executed in parallel is set in the multiple execution number 51. For example, when it is "1", it indicates that multiple execution is not possible. If the value is "2" or more, it indicates that multiple executions are possible. The valid flag 62 is a matrix, and the size of the matrix is a value set in the number of multiple executions 51. The value in the matrix of the lock [m]: 52 is set to a value indicating whether or not the function 21 is already used. For example, when "2" is set for the number of multiple executions 51, a value indicating that the lock [m]: 52 is used for the lock [1] is set and the lock [2] is used. If a value indicating that the function 21 is not set is set, it indicates that the function 21 can be executed. When both the lock [1] and the lock [2] are set to a value indicating that they are being used, it indicates that the function 21 cannot be executed any more.

<Status discard function>
Next, the status discard function will be described.
If the process 1 is restarted after the command 29 is written and before the status 30 is read, the status 30 read after the restart of the process 1 is discarded.
Further, it may have a flag table for storing a flag indicating ON when the command 29 is written to the storage area and OFF when the process 1 is restarted for each type of the command 29.
Then, after reading the status 30, if the flag stored in association with the type of the command 29 corresponding to the status 30 indicates OFF, the status 30 may be discarded.
Further, each command type may have a counter table that stores a counter indicating the number of times the command 29 is written minus the number of times the status 30 is read corresponding to the type of the command 29.
Then, after reading the status 30, the flag stored in the flag table is valid in association with the type of the command 29 corresponding to the status 30, and is associated with the type of the command 29 corresponding to the status 30. If the counter stored in the counter table does not show 1, the status 30 may be discarded.
In addition, the converted command 29 is retained, and after writing the command 29, the second OS 9 is restarted before the system call 10 of the second OS 9 corresponding to the command 29 is executed by the device 300 controlled by the driver 8. In that case, the retained command 29 may be written to the storage area.
Further, when the status 30 corresponding to the open command is read after the second OS 9 is restarted, the command with the file descriptor included in the status 30 as an argument may be written in the storage area.

FIG. 13 shows an example of an embodiment (unnecessary status discard function) in the present embodiment.
There is an unnecessary status discard module 1331 in the inter-OA communication driver 16.
If any of the processes terminates abnormally after writing the command 29 to the command buffer 1029 (for example, process 1 or library 15 abnormally terminates), the following problems may occur. Here, as an example, a case where the process 1 terminates abnormally will be described. The function 21 called by the process 1 before the abnormal termination is converted into a command 29 by the library 15, this command 29 is written in the command buffer 1029, and NOT EMPTY is notified to the inter-OS communication driver 19. After that, since the second control means 200 continues to operate even if the process 1 terminates abnormally, the command 29 read from the command buffer 1029 is converted into the system call 10, and the driver 8 processes according to the system call 10. It is executed, and the status 30 representing the execution result is generated and written to the status buffer 1030. However, when the process 1 terminates abnormally, the processing by the library 15 also terminates, so that the read method for the communication path 27 is not executed, and the status 30 remains unread from the status buffer 1030.

When the abnormally terminated process 1 is restarted, the library 15 corresponding to the process 1 executes the open method for the communication path 27, the first command 29 after the restart is generated, and this command 29 is sent to the command buffer 1029. Written. After that, the status 30 indicating the execution result of this command 29 is written in the status buffer 1030, and the inter-OS communication driver 16 is notified of NOT EMPTY. However, since the status 30 indicating the execution result of the command 29 written in the command buffer 1029 before the abnormal termination of the process 1 remains in the status buffer 1030, when this status 30 is read by the inter-OS communication driver 16, the command 29 There is a risk that the multi-processor system will malfunction due to a deviation in the correspondence between the status 30 and the status 30. Therefore, in the present embodiment, the unnecessary status disposal module 1331 is provided in the first OS 17. The unnecessary status discard module 1331 that realizes the status discard function is provided in the inter-OS communication driver 16 for each communication path, and the processing by the unnecessary status discard module 1331 is executed for each communication path. The unnecessary status discard module 1331 was read by the task 20 after the process was restarted if the process was restarted after the command 29 was written by the inter-OA communication driver 16 and before the status 30 was read by the task 20. Discard status 30. The processing by the unnecessary status disposal module 1331 is equivalent to the technique described in Patent Document 2.

FIG. 14 shows an example of an unnecessary status discard function in the present embodiment.
The unnecessary status discard module 1331 has a data group 53. The unnecessary status discard module 1331 refers to this data group 53 and discards unnecessary status.
The data group 53 is composed of a plurality of data 58. When multiple executions are performed, two or more data 58 are connected as a list structure. In the example of FIG. 14, the command IDs “3” and “n-1” are executed multiple times. Each data 58 has a data structure as shown in the example of FIG. FIG. 15 shows an example of a configuration breakdown diagram for each command ID of the unnecessary status discard function in the present embodiment. The data 58 is composed of a user ID 54, a valid flag 55, a counter 56, and Next 57, as shown in the example of FIG. Thread identification information is set in the user ID 54. Therefore, it can be managed for each thread. In particular, it is possible to determine whether the status 30 is valid or invalid. The valid flag 55 is a flag indicating whether or not the status 30 indicating the execution result of the command 29 corresponding to the command ID is valid for each command ID. If the valid flag 55 is ON, the status 30 is valid, and if the valid flag 55 is OFF, the status 30 is invalid. The counter 56 represents the number of times the command 29 corresponding to the command ID is written to the command buffer 1029 minus the number of times the command 29 is read from the status buffer 1030 corresponding to the command ID for each command ID. Next 57 is a pointer that points to the next data 58. A list structure is constructed by following this Next57. When the reading of the status is completed normally, the data 58 is deleted, and Next 57 (Next 57 in the previous data 58) pointing to the deleted data 58 is replaced with Next 57 of the deleted data 58. do it.

FIG. 16 shows an example of an embodiment (command reissue function) in the present embodiment.
In the example of FIG. 13, an example in which the first OS 17 side (process 1 or library 15) terminates abnormally is shown, but FIG. 16 shows an example in which the second OS 9 terminates abnormally.
The inter-OA communication driver 16 has a command reissue module 1632. The command reissue module 1632 is a case where the second OS9 terminates abnormally after the inter-OA communication driver 16 writes a command 29 to the inter-OA communication driver 19, and when the second OS9 is restarted, the command reissue module 1632 has already been used. The written command 29 is reissued. The abnormal termination of the second OS 9 corresponds to, for example, the case of shifting to the power saving mode.
The command reissue module 1632 of the inter-OA communication driver 16 has the command group data 60. Then, the command reissue module 1632 reissues the command 29 with reference to the command group data 60. FIG. 17 shows an example of the command reissue function in the present embodiment.
The command group data 60 is composed of a plurality of command data 66 and one fd data 70. When multiple executions are performed, two or more command data 66 are connected as a list structure. In the example of FIG. 17, the command IDs “3” and “n-1” are executed multiple times. Each command data 66 has a data structure as shown in the example of FIG. FIG. 18 shows an example of a configuration breakdown diagram for each command ID of the command reissue function in the present embodiment. As shown in the example of FIG. 18, the command data 66 is composed of a user ID 61, a valid flag 62, a counter 63, a pointer 64 to the issued command holding area, and Next65. Thread identification information is set in the user ID 61. Therefore, it can be managed for each thread. In particular, it is possible to determine whether or not the command 29 needs to be reissued. The valid flag 62 is a flag indicating whether or not the status 30 indicating the execution result of the command 29 corresponding to the command ID is valid for each command ID. If the valid flag 62 is ON, the status 30 is valid, and if the valid flag 62 is OFF, the status 30 is invalid. The counter 63 represents the number of times the command 29 corresponding to the command ID is written to the command buffer 1029 minus the number of times the command 29 is read from the status buffer 1030 corresponding to the command ID for each command ID. The inter-OS communication driver 16 writes a copy of the command 29 written in the command buffer 1029 to a storage area such as the RAM 102. This storage area is referred to as an issued command holding area, and a pointer indicating the logical address of this storage area is a pointer 64 to the issued command holding area. Next65 is a pointer that points to the next command data 66. A list structure is constructed by following this Next65. When the reading of the status is completed normally, the command data 66 is deleted, and Next65 (Next65 in the previous command data 66) indicating the deleted command data 66 is deleted. It may be replaced with Next65 of.

FIG. 19 shows an example of a configuration breakdown diagram of the open command reissue function of the command reissue function in the present embodiment.
The command reissue module 1632 generates fd data 70 for each communication path, and stores the generated fd data 70 in the RAM 102 or the HDD 105. The fd data 70 is a table in which the virtual fd67, the actual fd68, and the pointer 69 to the issued open command holding area are associated with each other. The virtual fd67 is a virtual file descriptor assigned by the first control means 100 to the file opened by the open command. The actual fd68 is a file descriptor assigned by the second control means 200 to the file. The inter-OS communication driver 16 writes a copy of the open command written in the command buffer 1029 to a storage area such as the RAM 102. This storage area is referred to as an issued open command holding area, and a pointer indicating the logical address of this storage area is a pointer 69 to the issued open command holding area.

FIG. 20 shows an example of the initialization processing sequence of the multiple execution determination function (multiple execution determination module 1033).
The processing from step S1 to step S6 is repeated for the command ID (1,1, n). That is, the multiple execution determination module 1033 adds 1 to the command ID loop counter (initial value is 1).
In step S2, the number of multiple executions is set.
The processing from step S3 to step S5 is repeated for the number of multiple executions (1,1, m). That is, the multiple execution determination module 1033 adds 1 to the multiple execution count loop counter (initial value is 1).
In step S4, FALSE is set in the lock (lock [m]: 52 of the command data 50 shown in the example of FIG. 12).
In step S5, the multiple execution number loop counter 1033 determines whether or not the multiple execution count loop counter has reached m, and if the multiple execution count loop counter has not reached m, the process returns to step S3 and reaches m. If so, the process proceeds to step S6.
In step S6, the multiple execution determination module 1033 determines whether or not the command ID loop counter has reached n, returns to step S1 if the command ID loop counter has not reached n, and if n has been reached. If so, the process ends.

FIG. 21 shows an example of a command issuance processing sequence of the multiple execution determination function (multiple execution determination module 1033).
In step S10, the multiple execution determination module 1033 determines whether or not the user ID is specified, and if it is specified, the process proceeds to step S11, and if not, the process proceeds to step S14. Here, the user ID is information that identifies the thread.
In step S11, the multiple execution determination module 1033 determines whether or not the lock is FALSE, proceeds to step S12 in the case of FALSE, and ends the process as an error in other cases. It means that the specified function determines whether or not it can be executed multiple times. In the case of "Yes" (lock is FALSE), multiple execution is possible, and in the case of "No", multiple execution is not possible.

In step S12, the multiple execution determination module 1033 sets TRUE for the lock.
In step S13, the multiple execution determination module 1033 performs a command generation process. The library 15 and the inter-OS communication driver 16 generate the command 29. Specifically, the processing routine of the library 15 corresponding to the function 21 generates command data 32 and passes it to the inter-OS communication driver 16. The inter-OS communication driver 16 that has received the command data 32 generates the command header 31, and generates the command 29 by combining the generated command header 31 with the command data 32.
Specifically, a command is generated according to the format of the command 29 shown in the example of FIG. That is, a command with the user ID 47 added is generated.
If the user ID is not specified (in the case of "No" in step S10), the multiple execution determination module 1033 newly generates the user ID and generates a command to which the user ID 47 is added.

The processing from step S14 to step S16 is repeated for the number of multiple executions (1,1, m). That is, the multiple execution determination module 1033 adds 1 to the multiple execution count loop counter (initial value is 1).
In step S15, the multiple execution determination module 1033 determines whether or not the lock is FALSE, proceeds to step S12 in the case of FALSE, and ends the process as an error in other cases. It means that the specified function determines whether or not it can be executed multiple times. In the case of "Yes" (lock is FALSE), multiple execution is possible, and in the case of "No", multiple execution is not possible.
In step S16, the multiple execution number loop counter 1033 determines whether or not the multiple execution count loop counter has reached m, and if the multiple execution count loop counter has not reached m, the process returns to step S14 and reaches m. If so, the process ends as an error.

FIG. 22 shows an example of the initialization processing sequence of the unnecessary status discard function (unnecessary status discard module 1331).
The processing from step S51 to step S54 is repeated for the command ID (1,1, n). That is, the unnecessary status discard module 1331 adds 1 to the command ID loop counter (initial value is 1).
In step S52, the unnecessary status discard module 1331 sets the user ID 54 in the data 58 to 0 and initializes Next 57 with NULL.
In step S53, the unnecessary status discard module 1331 turns off the valid flag 55 in the data 58 and initializes the counter 56 with 0.
In step S54, the unnecessary status discard module 1331 determines whether or not the command ID loop counter has reached n, returns to step S51 if the command ID loop counter has not reached n, and if n has been reached. If so, the process ends.

FIG. 23 shows an example of the processing sequence in the open method of the unnecessary status discard function (unnecessary status discard module 1331).
In step S55, the unnecessary status discard module 1331 performs the open method processing. The process 1 calls the library 15, and the library 15 executes the open method processing for the communication path 27. Then, as a return value of the open method processing, a file descriptor indicating the communication path 27 is returned to the library 15, and thereafter, the communication path 27 to be processed is specified by this file descriptor.

The processing from step S56 to step S60 is repeated for the command ID (1,1, n). That is, the unnecessary status discard module 1331 adds 1 to the command ID loop counter (initial value is 1).
In step S57, the unnecessary status discard module 1331 turns off the valid flag 55 of the data 58.
In step S58, the unnecessary status discard module 1331 refers to Next 57 of the data 58 to determine whether or not “Next = NULL”, and if “Next = NULL”, proceeds to step S60, and otherwise proceeds to step S60. In the case, the process proceeds to step S59.
In step S59, the unnecessary status discard module 1331 acquires the address of the structure (data 58) from Next 57 of the data 58, and returns to step S57.
In step S60, the unnecessary status discard module 1331 determines whether or not the command ID loop counter has reached n, returns to step S56 if the command ID loop counter has not reached n, and if n has been reached. If so, the process ends.

FIG. 24 shows an example of the processing sequence in the write method of the unnecessary status discard function (unnecessary status discard module 1331).
In step S61, the unnecessary status discard module 1331 performs a command generation process.
In step S62, the unnecessary status discard module 1331 performs a command writing process. The inter-OS communication driver 16 writes the generated command 29 to the command buffer 1029 by inter-OS communication.
In step S63, the unnecessary status discard module 1331 determines whether or not the user ID 54 of the structure (data 58) at the beginning of the corresponding command ID is 0, and if it is 0, the process proceeds to step S64, and other than that. In the case, the process proceeds to step S66. If "Yes" in step S63, it means that the initialization has been performed.
In step S64, the unnecessary status discard module 1331 updates the user ID.

In step S65, the unnecessary status discard module 1331 turns on the valid flag 55 of the data 58, increments the counter 56 by 1, and ends the process.
In step S66, the unnecessary status discard module 1331 refers to the user ID 54 of the data 58, determines whether or not “user ID of the structure = user ID”, and “user ID of the structure = user ID”. In the case of, the process proceeds to step S65, and in other cases, the process proceeds to step S67.
In step S67, the unnecessary status discard module 1331 refers to Next 57 of the data 58 to determine whether or not “Next = NULL”, and if “Next = NULL”, the process proceeds to step S68, and other than that. In the case, the process proceeds to step S69.
In step S68, the unnecessary status discard module 1331 secures the area of the structure (data 58), sets the address to Next57, and proceeds to step S64.
In step S69, the unnecessary status discard module 1331 refers to the user ID 54 of the next data 58, determines whether or not "user ID of the next structure = user ID", and determines whether or not "user ID of the next structure = user ID". If "user ID = user ID", the process proceeds to step S65, and if not, the process returns to step S67.

FIG. 25 shows an example of the processing sequence in the read method of the unnecessary status discard function (unnecessary status discard module 1331).
In step S70, the unnecessary status discard module 1331 performs the status reading process. That is, the unnecessary status discard module 1331 reads the status 30 from the status buffer 1030 by inter-OS communication. Specifically, the inter-OS communication driver 16 waits until the notification of NOT EMPTY from the inter-OS communication driver 19 is received. Upon receiving the NOT EMPTY notification, the inter-OS communication driver 16 reads the status 30 from the status buffer 1030 by inter-OS communication.
In step S71, the unnecessary status discard module 1331 determines whether or not the status reading is successful, and if it succeeds, the process proceeds to step S72, and if not, the process ends.
In step S72, the unnecessary status discard module 1331 checks the valid flag of the corresponding command ID / user ID (valid flag 55 of data 58), proceeds to step S77 if the valid flag is off, and proceeds to step S77 otherwise. The process proceeds to step S73.

In step S73, the unnecessary status discard module 1331 checks the counter of the corresponding command ID / user ID (counter 56 of the data 58), and if the counter is 0, the process proceeds to step S75, otherwise the process proceeds to step S74. move on.
In step S74, the unnecessary status discard module 1331 decrements the counter 56 of the data 58 by 1, and if the counter 56 becomes 0, the process proceeds to step S76, otherwise the process proceeds to step S75.
In step S75, the unnecessary status discard module 1331 discards status 30.
In step S76, the unnecessary status discard module 1331 turns off the valid flag 55 of the data 58 and ends the process.
In step S77, the unnecessary status discard module 1331 checks the counter of the corresponding command ID / user ID (counter 56 of the data 58), and if the counter is 0, the process proceeds to step S79, otherwise the process proceeds to step S78. move on.
In step S78, the unwanted status discard module 1331 decrements the counter 56 by one.
In step S79, the unnecessary status discard module 1331 discards the status 30 and ends the process.

FIG. 26 shows an example of the initialization processing sequence of the command reissue function (command reissue module 1632).
In step S101, the command reissue module 1632 performs an unnecessary status discard function initialization process. Specifically, the process shown in the example of FIG. 22 is performed.
The processing from step S102 to step S104 is repeated for the command ID (1,1, n). That is, the command reissue module 1632 adds 1 to the command ID loop counter (initial value is 1).
In step S103, the command reissue module 1632 initializes the pointer 64 to the issued command holding area of the command data 66 with NULL.
In step S104, the command reissue module 1632 determines whether or not the command ID loop counter has reached n, returns to step S102 if the command ID loop counter has not reached n, and if n has been reached. Then, the process proceeds to step S105.

In step S105, the command reissue module 1632 initializes the pointer 64 to the issued command holding area of the command data 66 with NULL.
In step S106, the command reissue module 1632 sets the virtual fd67 of the fd data 70 to x (positive value) and initializes the real fd68 of the fd data 70 to -1.

FIG. 27 shows an example of a processing sequence in the write method of the command reissue function (command reissue module 1632).
In step S107, the command reissue module 1632 performs a command generation process (a process of converting a virtual fd into a real fd).
In step S108, the command reissue module 1632 performs a command writing process.
In step S109, the command reissue module 1632 performs write method processing of an unnecessary status discard function. Specifically, the process shown in the example of FIG. 24 is performed.

In step S110, the command reissue module 1632 determines whether or not it is an open command, and if it is an open command, the process proceeds to step S111, and if not, the process proceeds to step S112.
In step S111, the command reissue module 1632 secures a holding area, copies the open command, sets the address of the holding area to the pointer 69 to the issued open command holding area of the fd data 70, and ends the process. ..
In step S112, the command reissue module 1632 determines whether or not it is an asynchronous command, proceeds to step S113 if it is an asynchronous command, and ends the process in other cases.
In step S113, the command reissue module 1632 secures the holding area, copies the asynchronous command, sets the address of the holding area in the pointer to the issued asynchronous command holding area of the corresponding command ID / user ID, and processes it. To finish.

FIG. 28 shows an example of a processing sequence in the read method of the command reissue function (command reissue module 1632).
In step S114, the command reissue module 1632 performs the status reading process. The command reissue module 1632 reads the status 30 from the status buffer 1030 by inter-OS communication. Specifically, the inter-OS communication driver 16 waits until the notification of NOT EMPTY from the inter-OS communication driver 19 is received. Upon receiving the NOT EMPTY notification, the inter-OS communication driver 16 reads the status 30 from the status buffer 1030 by inter-OS communication.
In step S115, the command reissue module 1632 performs the read method processing of the unnecessary status discard function. Specifically, the process shown in the example of FIG. 25 is performed.

In step S116, the command reissue module 1632 determines whether or not it is a close command, and if it is a close command, the process proceeds to step S117, and if not, the process proceeds to step S119.
In step S117, the command reissue module 1632 releases the holding area and sets NULL for the pointer 69 to the issued open command holding area of the fd data 70.
In step S118, the command reissue module 1632 resets the actual fd of the command reissue function by -1, and ends the process.

In step S119, the command reissue module 1632 determines whether or not the command is an asynchronous command, and if it is an asynchronous command, the process proceeds to step S120, and if not, the process proceeds to step S121.
In step S120, the command reissue module 1632 releases the holding area, sets NULL as a pointer to the issued asynchronous command holding area of the corresponding command ID / user ID, and ends the process.
In step S121, it is determined whether or not the command reissue module 1632 is an open command and “fd ≧ 0”, and if it is an open command and “fd ≧ 0”, the process proceeds to step S122. In other cases, the process ends.
In step S122, the command reissue module 1632 sets the fd included in the parameter area of the status data to the actual fd of the command reissue function.
In step S123, the command reissue module 1632 converts the fd included in the parameter area of the status data into the virtual fd of the command reissue function, and ends the process.

Each module (process 1, thread [1]: 2, thread [2]: 3, thread [3]: 4, API12, API13, library 15, OA-to-OA communication driver 16, 1st OS17, PCle18, 2nd OS9, Inter-OA communication driver 19, task 20, cotasking [1]: 25, cotasking [2]: 26, API5, API6, driver 8, command buffer 1029, status buffer 1030, multiple execution determination module 1033, unnecessary status discard module 1331, The technique described in the background technique may be adopted as the processing content of the command reissue module 1632, etc.).

Further, the described program may be stored in a recording medium and provided, or the program may be provided by a communication means. In that case, for example, the program described above may be regarded as an invention of "a computer-readable recording medium on which the program is recorded".
The "computer-readable recording medium on which a program is recorded" means a computer-readable recording medium on which a program is recorded, which is used for program installation, execution, program distribution, and the like.
The recording medium is, for example, a digital versatile disc (DVD), which is a standard established by the DVD Forum "DVD-R, DVD-RW, DVD-RAM, etc." and DVD + RW. Standards such as "DVD + R, DVD + RW, etc.", compact discs (CD), read-only memory (CD-ROM), CD recordable (CD-R), CD rewritable (CD-RW), etc., Blu-ray discs (CD-RW) Blu-ray (registered trademark) Disc), optical magnetic disk (MO), flexible disk (FD), magnetic tape, hard disk, read-only memory (ROM), electrically erasable and rewritable read-only memory (EEPROM (registered trademark)) )), Flash memory, random access memory (RAM), SD (Secure Digital) memory card and the like.
Then, the whole or a part of the program may be recorded on the recording medium and stored, distributed, or the like. Further, by communication, for example, a wired network used for a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), the Internet, an intranet, an extranet, or wireless communication. It may be transmitted using a transmission medium such as a network or a combination thereof, or may be carried on a carrier.
Further, the program may be a part or all of other programs, or may be recorded on a recording medium together with a separate program. Further, the recording may be divided into a plurality of recording media. Further, it may be recorded in any mode as long as it can be restored, such as compression and encryption.

1 ... Process 2 ... Thread [1]
3 ... Thread [2]
4 ... Thread [3]
5 ... API
6 ... API
7 ... API
8 ... Driver 9 ... 2nd OS
10 ... System call 11 ... Return value 12 ... API
13 ... API
14 ... API
15 ... Library 16 ... Communication driver between OA 17 ... 1st OS
18 ... PCle
19 ... OA communication driver 20 ... task 21 ... function 22 ... return value 25 ... cotasking [1]
26 ... Cotasking [2]
27 ... Communication path 28 ... Interrupt 29 ... Command 30 ... Status 100 ... First control means 101 ... CPU
102 ... RAM
103 ... ROM
104 ... Communication I / F
105 ... HDD
106 ... LAN terminal 110 ... Bus 200 ... Second control means 201 ... CPU
202 ... RAM
203 ... ROM
204 ... Communication I / F
210 ... Bus 300 ... Device 301 ... Image Scanner 302 ... Printer 303 ... UI
304 ... Compression / decompression device 1000 ... Image forming device 1029 ... Command buffer 1030 ... Status buffer 1033 ... Multiple execution determination module 1331 ... Unnecessary status discard module 1632 ... Command reissue module

Claims (11)

A first control means that executes control by the first OS,
A second control means that executes control by the second OS,
A device controlled by the second control means is provided.
The first control means
A first conversion means for converting a function called by a process running on the first OS into a command commonly interpreted by the first OS and the second OS.
A command writing means for writing a command converted by the first conversion means to the storage area of the second control means, and a command writing means.
When a notification is received indicating that the status indicating the result of execution of the system call of the second OS corresponding to the command written by the command writing means by the second control means has been written in the storage area. A status reading means for reading the status from the storage area, and
A second conversion means for converting the status read by the status reading means into a return value interpreted by the process and returning the return value to the process is provided.
A plurality of threads are executed in the process, and the function is called by the thread.
When the function can be executed multiple times, the first conversion means converts the function into a command to which thread identification information for identifying the thread is added.
The status reading means reads the thread identification information together with the status, and reads the thread identification information.
The second conversion means converts the status into a return value interpreted by the thread according to the thread identification information read by the status reading means .
If the function is not multi-executable, the first conversion means returns an error to the thread that called the function.
Electronics. When the thread identification information is added to the function and the function cannot be executed multiple times, the first conversion means invalidates the thread identification information and sends an error to the thread that called the function. Send back,
The electronic device according to claim 1. The first conversion means returns an error to the thread that called the function when the thread identification information is not added to the function and the function cannot be executed multiple times.
The electronic device according to claim 1. If the process is restarted after the command writing means writes the command and before the status is read by the status reading means, the status read means is read after the process is restarted. The electronic device according to any one of claims 1 to 3 , further comprising a status disposal means for discarding the status. A flag storage means for storing a flag indicating ON when the command is written to the storage area and OFF when the process is restarted for each type of the command is provided.
The status discarding means discards the status when the flag stored in the flag storage means indicates OFF in association with the type of command corresponding to the status after the status is read by the status reading means.
The electronic device according to claim 4. For each type of command, a counter storage means for storing a counter indicating the number obtained by subtracting the number of times of reading the status corresponding to the type of the command by the status reading means from the number of times the command is written by the command writing means is provided.
After reading the status by the status reading means, the status discarding means indicates that the flag stored in the flag storage means is valid in association with the type of the command corresponding to the status, and corresponds to the status. If the counter stored in the counter storage means does not show 1 in association with the command type, the status is discarded.
The electronic device according to claim 5. A command holding means for holding the command converted by the first conversion means, and
When the second OS is restarted after the command writing means writes the command and before the system call of the second OS corresponding to the command is executed by the second control means, the command holding means. The electronic device according to any one of claims 4 to 6 , further comprising a command rewriting means for writing the command held by the user in the storage area. The command rewriting means stores a command in which a file descriptor included in the status is an argument when the status corresponding to the open command is read by the status reading means after the second OS is restarted. Write to,
The electronic device according to claim 7. The device forms an image based on the image data.
The electronic device according to any one of claims 1 to 8. A first conversion means that converts a function called by a process running on the first OS into a command that is commonly interpreted by the first OS and the second OS.
A command writing means for writing a command converted by the first conversion means to a storage area of a second control device that executes the second OS, and a command writing means.
When a notification is received indicating that the status indicating the result of execution of the system call of the second OS corresponding to the command written by the command writing means by the second control device has been written to the storage area. A status reading means for reading the status from the storage area and
A second conversion means for converting the status read by the status reading means into a return value interpreted by the process and returning the return value to the process is provided.
A plurality of threads are executed in the process, and the function is called by the thread.
When the function can be executed multiple times, the first conversion means converts the function into a command to which thread identification information for identifying the thread is added.
The status reading means reads the thread identification information together with the status, and reads the thread identification information.
The second conversion means converts the status into a return value interpreted by the thread according to the thread identification information read by the status reading means .
If the function is not multi-executable, the first conversion means returns an error to the thread that called the function.
Control device. Computer,
A first conversion means that converts a function called by a process running on the first OS into a command that is commonly interpreted by the first OS and the second OS.
A command writing means for writing a command converted by the first conversion means to a storage area of a second computer executing the second OS, and a command writing means.
When a notification is received indicating that the status indicating the result of execution of the system call of the second OS corresponding to the command written by the command writing means by the second computer has been written to the storage area. A status reading means for reading the status from the storage area and
The status read by the status reading means is converted into a return value interpreted by the process, and the return value is returned to the process as a second conversion means.
A plurality of threads are executed in the process, and the function is called by the thread.
When the function can be executed multiple times, the first conversion means converts the function into a command to which thread identification information for identifying the thread is added.
The status reading means reads the thread identification information together with the status, and reads the thread identification information.
The second conversion means converts the status into a return value interpreted by the thread according to the thread identification information read by the status reading means .
If the function is not multi-executable, the first conversion means returns an error to the thread that called the function.
program.

Images