JP2001282558A - Multi-operating computer system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a multi-operating computer system realizing the communication of a processing request among a plurality of operating systems with simple modification. SOLUTION: When the processing request is transmitted by communication between the operating systems 301 and 351, the operating system receiving the processing request interruption-processes the processing request from the other operating system by an interruption handler 305.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] 1. Field of the Invention [0002] The present invention relates to a multi-operating computer system that operates a single processor by switching a plurality of operating systems.

[0002]

2. Description of the Related Art As a technique for operating a plurality of operating systems (hereinafter referred to as "OS") on one computer system, a "virtual machine (Virtual Machine)" conventionally used in large computers.
Hereinafter, "VM") is known. In the VM technology, there is a VM control program that manages the entire computer system, and exclusively manages the hardware of the computer system.

[0003] In order to provide each OS operating on a computer system with the same state as if the hardware were exclusively managed, a VM control program executes hardware emulation. Emulation of hardware communication paths is also provided, and communication paths exist between OSs.

[0004] When communication is performed across a plurality of OSs or when synchronization is performed across a plurality of OSs (hereinafter, both are collectively referred to as “inter-OS communication”), a task or a task operating on each OS is required. A dedicated subprogram that operates on each OS performs communication using a communication path and is realized. Each O
In S, the access to this communication path is performed only during a time slot allocated so that the OS is executed in advance.

On the other hand, even in a smaller computer system, a plurality of OSs can be operated by one computer system due to the improvement in CPU capability. Japanese Patent Application Laid-Open No.
49385. In this technique, an OS switching program saves and restores contexts such as register contents for each OS, and switches OSs. At this time, the OS switching program handles the hardware interrupt that triggers the switching, but the operating OS actually operates for access to other hardware. Further, in a computer system using such a multiple OS coexistence technology,
Japanese Patent Laid-Open No. 11-855 discloses a method for realizing inter-OS communication.
Techniques at 46 are known.

[0006]

Among the conventional techniques, in the case of the former VM technique, all the hardware processes are emulated, and the communication path between the VMs simulates the communication path of the hardware. Therefore, processing overhead increases. Therefore, it is not suitable for a small-scale computer system with limited resources such as CPU power and memory capacity.

On the other hand, in the case of the latter conventional technology, in the case of the OS coexistence technology, the computer system to which the technology is applied has the following problems.

In the prior art, when a program for switching OS makes a certain processing request to each OS, the OS
The processing module in S is directly called. If an OS operating on the computer system is to be modified based on an OS originally operating solely on the computer system, it is necessary to modify the task switching portion in the OS. This requires a complete understanding of all processes related to task switching of the OS, which is extremely difficult.

This will be specifically described with reference to a conventional computer system shown in FIG.

In FIG. 31, a first OS 301 and a second O
S351 is operating on a single computer system while being switched by the OS switching unit 201. First OS
The task A 302 operating on the OS 301 is the second OS 351
It is waiting for a message to be transmitted from the task P352 operating above.

When the message is transmitted from the task P, the inter-OS communication module 206 instructs the first OS 301 to restart the operation of the waiting task A 302. At this time, the OS context switching module 202 restores the operation context to that of the first OS 301 and calls the callback routine 306.
At this time, the callback routine 306 determines that the task A30
It is necessary to send a request to restart the scheduler 309 to the scheduler 309.

However, the callback routine 306
This does not exist when the first OS 301 operates alone, and the scheduler 309 does not originally know it.
Therefore, the process of saving the context of the task on the first OS 301 that was operating immediately before the callback routine 306 was called, the status change process in which the scheduler 309 treats the task as interrupted, and the like,
It must be newly added so as not to be inconsistent with the state management of the existing scheduler.

A method is also conceivable in which the callback routine 306 does not directly operate the scheduler 309 and calls a system call 308 for resuming the task A 302.
Is accompanied by various restrictions (for example, the state of the stack to be used), and after all, it is necessary to completely understand the internal processing of the OS and create a state satisfying the restrictions.

In order to solve the above-mentioned problem, a configuration as shown in FIG. 32 may be considered.

In FIG. 32, the callback routine does not directly restart the requested task A, but records the request in the request table 341 in the OS, and returns the processing to the OS switching unit 201 once. On the first OS, there is a routine 342 that is started periodically. This routine fetches a request from the request table 341 and executes the task A302.
Issue a system call 308 requesting restart of the system. In this case, the periodic startup routine 342 assumes a device driver or a task to be incorporated in the OS, and the conditions for issuing a system call are prepared in advance, and there is no need to be aware of the internal processing of the OS.

However, even if the operation is switched to the OS, only the task that was operating immediately before is restarted. Actual processing is not performed until the periodic start routine 342 is executed, and the task A 302 is restarted. Will be delayed. For this reason, the original purpose of switching and operating a plurality of OSs with small overhead cannot be achieved.

As described above, since the scheduler manages the whole of the OS, it is necessary to modify the scheduler so that communication between the OSs can be performed in consideration of other procedural consequences. Become.

An object of the present invention is to provide a multi-operating computer system capable of communicating processing requests between a plurality of operating systems by a simple modification of the operating system.

[0019]

A feature of the present invention is that when a processing request is transmitted between a plurality of operating systems by communication, the operating system that has received the processing request performs processing from another operating system. The request is interrupted.

According to the present invention, since the operating system interrupts the processing request, it is only necessary to add one communication handler function to the operating system. It can be done with simple modifications.

[0021]

Embodiments of the present invention will be described below with reference to the drawings.

FIG. 1 shows an embodiment of the present invention.

In FIG. 1, the computer system includes a processor 101, a memory 102, an input / output control device 103, an input / output device 105, a real time clock (Real Time C).
lock. Hereinafter, this is referred to as “RTC” 107). The processor 101, the memory 102, the input / output control device 103, and the RTC 107 are connected by a processor bus 104.

The processor 101 is a microprocessor for operating a plurality of operating systems (hereinafter, referred to as “OS”). The memory 102 stores an operating system switching program 201 (hereinafter, referred to as an operating system switching program).
On the first OS, the first operating system 301 (hereinafter, referred to as a “first OS”), the second operating system 351 (hereinafter, referred to as a “second OS”), Tasks 302 and 303 that operate, tasks 352 and 353 that operate on the second OS, and a first OSRP that performs processing on the first OS in response to a request from the second OS
The C server 304 holds a second OSRPC server 354 that performs processing on the second OS in response to a request from the first OS. These programs 201, 301 to 304, 35
1 to 354 are read and executed by the processor 101.

The input / output control device 103 includes a processor 1
01 or the memory 102, an input / output device 105 for inputting or outputting data is connected. As the input / output device 105, a disk device for storing data, a display as a screen display device, a keyboard as an input device for a user, or a network connection device for exchanging data with another computer system and so on. Which input / output devices are connected or not all are determined by the system configuration.

The input / output control device 103 is connected to the interrupt signal line 10
6, it can be connected to the processor 101 to notify completion of input / output operation and the like. Although FIG. 1 illustrates that the interrupt signal line 106 and the processor bus 104 are different devices, the interrupt signal line 106 is actually a part of the processor bus 104. A timer device 108 is provided inside the processor 101, and generates an interrupt at regular intervals. The interrupt from the timer device 108 is used for time measurement of the OSs 301 and 351 and the like.

Depending on the type of the processor 101, the input / output control device 103, the input / output device 105, the RTC
Some or all of 107 may be incorporated into the processor 101. In addition, the timer device 10
8 may not exist inside the processor 101 but may be connected to the outside of the processor 101 via the processor bus 104.

The processor 101 receives an interrupt from the outside of the processor (hereinafter referred to as "external interrupt") notified by the interrupt signal line 106 and an interrupt from inside the processor such as the timer device 108 (hereinafter, "internal interrupt"). ) Can be masked. The interrupt mask is a function of delaying the entry of a specific interrupt until the program releases the interrupt mask.

Generally, there are the following three types of interrupt mask functions. (1) All interrupt mask: Masks all interrupts. (2) Individual interrupt mask: Masks individual interrupts. (3) Interrupt level mask: A level is set for each interrupt, and interrupts below a specified level are masked.

Depending on the type of the processor 101, the processor 101 is often provided with either the combination of the above (1) and (2) or the combination of the above (1) and (3). If a processor equipped with the latter combination is employed, the interrupt level is assigned according to the significance of the corresponding interrupt factor. For example, there is a configuration of a computer system in which an interrupt from a network input / output device having a high real-time property is set to a higher level than an interrupt of another disk device or the like.

In this embodiment, two OSs 301 and 351 exist in the computer system. OS 301, 351
Uses the memory processor resources allocated to each of the programs 302 to 304 and the program 3
52 to 354 are executed. The RPC servers 304 to 354 are actually composed of two tasks on the OS. Thus, as an embodiment, an example is shown in which the number of OSs is 2 and the number of tasks is 8 (4 for each OS).
It is also possible to implement more or less OSes or tasks than these numbers. The number of OSs can be obtained by dynamically generating and deleting tasks.

It should be noted that a plurality of operating OSs are all treated as equivalent. Therefore, in the following, only the description of a single OS will be omitted.
However, it is assumed that it has the same configuration or performs the same operation.

Each of the OSs 301 and 351 has an OS switching unit 2
There are callback routines 306 to 356 that are called directly from the inside of O.01, complete the requested processing, and return to the OS switching unit 201. The OS switching unit 201 calls a callback routine for processing requests to the OSs 301 and 351 that need to immediately execute the processing request. As an example of the processing request, there is a process of suppressing an interrupt from an input / output device managed by the OS immediately before the OS is forcibly stopped.

The OS switching unit 201 is provided with an OS context switching module 202.
The OS operating on the processor 101 is switched according to an instruction from each module in the processor 01. Also, the OS switching unit 201 includes the respective OSs 301 and 35 from the OS switching unit 201.
There is a delay request management module 203 that manages a processing request for the first OS 301, and a first OS delay request queue 204 and a second OS 3
A second OS delay request queue 205 is provided to accumulate processing requests for the OS 51. An example of a processing request is O
When there is a task using the inter-OS message communication function provided by the S switching unit and waiting to receive a message, there is a process of restarting the operation of the task when the message is transmitted.

The delay request management module 203
Processing requests are stored in the S delay request queue 204 or the second OS delay request queue 205, and the OS
When an appropriate condition for processing the interrupt is satisfied, the same state as when the interrupt has occurred in the OS through the OS context switching module 202 is generated, and an interrupt for notifying the OS of the existence of the delay request is generated. Let it. Hereinafter, a processing request made via the delay request management module 203 is referred to as a “delay request”, and an interrupt for notifying the presence of the delay request management module is referred to as a “delay request interrupt”. On each of the OSs 301 and 351, there are provided delay request interrupt handlers 305 to 355 which receive a delay request interrupt, take out a request from the delay request queues 204 to 205, and perform corresponding processing.

The inter-OS communication module 206 has different O
A function for exchanging messages between tasks of S
A function for synchronizing between different OSs (hereinafter, referred to as "inter-OS message communication") (hereinafter, referred to as "inter-OS semaphore") is provided. In the inter-OS message communication function, the operation of a task may be interrupted in order to wait for a message to be transmitted because it does not yet exist. In the inter-OS semaphore function, the semaphore that is to be acquired is acquired first. The operation of the task may be interrupted to wait for the release of the semaphore. In either case, it is necessary to resume the operation of the task as soon as the waiting condition is satisfied. When the above condition is satisfied, the inter-OS communication module 206 requests the delay request management module 203 to add a delay request for task restart.

The OS state management module 207 is provided for each OS.
It has a function of managing states such as start and stop of the 301 and 351 and accepting a state transition request and instructing each of the OSs 301 and 351. For example, from a certain task to a certain OS
When a shutdown request is received for
The request is added to the delay request management module 203 to add a shutdown processing request to the request as a delay request.

The RTC management module 208 includes the RTC 1
07 and a time setting process to the RTC 107. Each of the OSs 301 and 351 has the RTC 107
These processing requests are sent to the RTC management module 208 instead of directly reading and writing the time to the RTC. For example, when there is a time setting processing request from one OS 301 to the RTC 107, a delay request is added to the other OS 351 so as to adjust the time to the RTC 107 and correct it.

The RPC server 30 of each OS 301 and 351
4 and 354 each receive a processing request sent from another OS using the OS message communication function, execute processing on the OS, and send back a processing result using the OS message communication function. .

FIG. 2 shows an example of the internal configuration of the processor 101.

In FIG. 2, a cache memory 122 is a buffer storage device for temporarily storing data or instructions in the memory 102. The CPU 121 is an arithmetic unit that sequentially reads and executes instructions existing in the memory 101 or the cache memory 122. When executing an instruction, a general-purpose register 123 for temporarily holding an operation result, a program counter (hereinafter, referred to as “PC”) 124 for specifying an instruction address, and a status register (hereinafter, “SR”) for holding an execution state Call) 125 is used.

As the timer device 108, three timer devices 1081 to 1083 are provided. Timer device 108
Are set to three for the description of the interrupt processing described later, but it is sufficient that at least one exists in implementing the present invention.

The interrupt signal from the interrupt signal line 106 and the timer device 108 is connected to an interrupt controller 126. When an external interrupt or an internal interrupt occurs, the interrupt controller 126 refers to information on an interrupt mask inside the SR 125 and determines whether or not to accept the interrupt.

When accepting an interrupt, the interrupt controller 1
26 records the cause of the interrupt in the interrupt cause register 130, saves the current value of the PC 124 in a save program counter (hereinafter, referred to as “SPC”) 126, and rewrites the value into the interrupt address register 129. . In addition, SR12
5 is saved in the save status register (hereinafter referred to as “SS
R ”) and then rewrite. SR12
The rewriting contents of No. 5 will be described later. As a result, the interrupt processing program existing at the address registered in the interrupt address register 130 is started. The interrupt processing program refers to the interrupt factor recorded in the interrupt factor register 130 and executes a process corresponding to the interrupt factor.

Note that, depending on the type of the processor 101 used, the address of the interrupt processing program can be stored in the memory, and the address of the storage location can be set in a register in the processor.

Instead of setting the value indicating the interrupt factor in the interrupt factor register 130 depending on the type of the processor 101 to be used, a different address of the interrupt processing program can be used for each interrupt factor. In this case, the value indicating the factor is recorded in a specific general-purpose register by the interrupt processing program for each interrupt factor, and then the process jumps to the common interrupt processing program. If the general-purpose register is referred to instead of referring to the factor recorded in the processor, interrupt processing exactly the same as that of the processor shown in FIG. 2 can be performed.

CPU 121, cache memory 122,
The registers 123 to 125 and 127 to 130 are connected to each other by a data bus 131 for performing data transfer and an address bus 132 for specifying addresses.

FIG. 3 shows a case where the processor 101 is equipped with a full interrupt mask function and an interrupt level mask function.
It is a structural example of SR125. The SR 125 has an interrupt block bit 141 and an interrupt mask level field 142. When the interrupt block bit 141 is ON, all interrupts to the processor 101 are masked. The interrupt mask level field 142 indicates the current interrupt mask level value, and interrupts of an interrupt level lower than this value are not accepted.

In the example of FIG. 3, the interrupt mask level field 142 has a 4-bit length, and a total of 16 types of mask levels can be designated. Normally, the interrupt level 0 means “no interrupt has occurred”, and the interrupt mask level is 0.
Is set to "do not perform interrupt masking", so there are practically 15 types.

By changing the number of bits in the interrupt mask level field 142 of the processor 101, the types of interrupt levels that can be used can be increased or decreased. When the privilege mode bit 149 is ON, the program is operating in the privilege mode, and all operations on the processor 101 are possible. On the other hand, when the privilege mode bit 149 is OFF, the running program operates in the non-privileged mode, and some functions, such as access to the control register and the memory management register, are prohibited.

Generally, an OS operates in a privileged mode. On the other hand, tasks that operate on the OS include those that operate in the privileged mode and those that operate in the non-privileged mode, depending on the type of the OS.

FIG. 4 shows the case where the processor 101 is equipped with the all interrupt mask function and the individual interrupt mask function.
It is a structural example of R125. The SR 125 is actually composed of two registers (the execution status register 143 and the interrupt mask register 144), and the SSR 127 also has an area for storing these two registers. 3, an interrupt block bit 141 is provided in the execution state register 143. The interrupt mask bits 145 to 148 in the interrupt mask register 144 respectively correspond to different interrupts. When any one of the interrupt mask bits is turned ON,
The interrupt corresponding to the bit is not accepted.

The example of the SR shown in FIG. 3 can be regarded as a special example of the SR in FIG. For example, a state where only the interrupt mask bit 145 is ON is set to level 1, a state where two of the interrupt mask bits 145 and 146 are ON is level 2, and three of the interrupt mask bits 145 to 147 are ON. Can be made to correspond to levels 3,.... Therefore, the status register 12
5 is described as having the configuration shown in FIG.

When an interrupt is accepted, the interrupt controller 1
26 rewrites the SR 125. In a general processor, the interrupt block bit 141 and the privilege mode bit 149 are rewritten to ON.

The OS, the device driver, and the task operating in the privilege mode can rewrite the contents of the interrupt block bit 141 and the interrupt mask register 144, and can set the interrupt mask level. As a result, it is possible to prohibit the occurrence of the same interrupt or an interrupt having a lower priority during execution of the interrupt processing, or to realize exclusive control.

Hereinafter, the operation will be described in detail.

In this embodiment, a plurality of operating OSs are all treated as equivalent. Therefore, in the following description, there is a portion that describes only the operation on one OS or the operation from one OS to another OS, but these processes are similarly applied to other OSs. It is possible.

FIG. 5 shows a detailed functional block diagram of the software. However, some components are not shown in FIG. 5 and are shown in FIGS. 6 to 8. Figure 5
All components described in FIG.
02 is executed by the processor 101. In the following description, detailed operation of each component will be described by dividing into several operation patterns on the computer system. Each drawing after FIG. 9 shows a processing flow of each component and a data structure used in the processing.

First, the operation in the case where the tasks on each OS are operating while switching by the scheduling function of the OS will be described.

The first OS 301 has a system call program 308 for providing a service to a task, and a scheduler 309 for switching tasks. Also, the task operating on the first OS 301 is the OS switching unit 2
01 has an OS switching unit use library 310 in which functions for using the process of No. 01 are stored.

FIG. 5 shows a configuration in which the task A 302 uses the OS switching unit library 310, but it can be used by other tasks. Task A302 is O
The processing is requested by calling a function provided by the S switching unit library 310. Called OS switching library 3
The functions in 10 operate as part of task A302,
The requested processing is realized by calling a processing function of the OS switching unit 201 or calling a necessary system call 308.

It is to be noted that the task operates as a part of the task because the task is operating in the dedicated logical memory space or the task is operating in the non-privileged mode.
If the S switching unit library 310 cannot directly call the function of the OS switching unit 201, a part of the functions of the OS switching unit use library may be replaced by a device driver or the like.
You can put it inside.

The scheduler 309 secures a task management block 321 in the memory corresponding to each task existing on the first OS 301, and manages each task.

FIG. 9 shows an example of the internal structure of the task management block.
FIG. 10 shows an example of the management structure of the task management block.
Inside the task management block 321, a queue connection pointer 3211 for connecting and managing a plurality of task management blocks to a queue, a status flag 3212 indicating the status of the task, the PC at the time when the task was interrupted,
R, a register save area 3213 for storing general-purpose register values and the like. In addition, it may include information such as a reason for interruption and a priority.

The scheduler 309 connects and manages task management blocks corresponding to executable tasks to executable task queues (322, 323, etc.) for each priority. Therefore, the number of executable task queues is equal to the number of priorities. However, by adding a rule that the task management blocks of higher priority tasks are connected more forward, it is also possible to manage the tasks with a single executable task queue.

Waiting for completion of processing for the input / output device 105,
Alternatively, a task management block corresponding to a task whose processing is suspended due to waiting for resumption by a synchronous processing mechanism in the first OS 301 such as a mutex semaphore event is connected to the execution suspended task queue 324 and managed. It should be noted that a different queue may be managed for each execution interruption reason. In order to connect a task management block to each of these queues, a queue connection pointer 3211
Is used.

The scheduler 309 has a system call 3
When the process of step 08 or the process of the interrupt handler 307 to be described later is completed, if the task currently being executed is no longer executable, or if a task with a higher priority than the currently executed task becomes executable, , To switch the execution task. The system calls that may activate the scheduler 309 include (A) task creation / termination / stop / restart (for example, when a task having a higher priority than itself is created); End (for example, when shifting to the exclusive control wait state) (c)
For example, there is a task priority change (for example, when its own priority is lowered).

The processing flow of the scheduler 309 is shown in FIG.
Shown in The scheduler 309 saves the register of the task that was being executed in the register save area 3213 in the task management block of the task (process 401), and searches the executable task queue in descending order of priority (process 402). ).

If there is no task management block, it is determined in step 403, and the inter-OS priority management module 211 is notified of the idle state (step 405). Since there is no executable task, the process shifts to an idle loop (step 408), and nothing is performed until a task to be executed appears.

On the other hand, if there is a task management block, the priority of the task is notified to the inter-OS priority management module 211 (process 404). However, the priority to be notified uses the priority determined uniformly for all OSs, and the notification is performed by converting the priority managed in the first OS 301 by a predetermined correspondence. I do.

In the inter-OS priority management module 211, (A) the notified priority and (A) other OS
Then, the priority of the task that was operating before the OS was interrupted is compared. (Hereinafter, (A) and (A) will be collectively referred to simply as “priority of the OS”.) If the notified priority is higher than or the same as the priority of the second OS 351, the process 404 proceeds immediately. Return to

On the other hand, the notified priority is the second OS 351
If the priority is lower than the priority of the first OS 3
01 is interrupted and switched to the second OS 351. After that, when the priority of the task operating on the second OS 351 decreases and the priority of the first OS 301 becomes higher, the process 404 ends and returns. Come. The task management block selected here is removed from the queue (process 406), the contents of the register save area 3213 are restored to the registers of the processor 101 (process 407), and the process of the selected task is resumed. When the task is newly created, the initial register value is registered in the register save area 3213, and the task is newly activated by the same processing.

FIG. 12 shows a processing flow of the inter-OS priority management module 211. The inter-OS priority management module 211 has a variable for recording the last priority notified by each OS. The value held by this variable is the O
This variable is hereinafter referred to as “OS
Called "priority variables." When the notification of the priority is received from the schedulers 309 to 359 of the OS, the contents of the OS priority variable corresponding to the OS are updated to the notified value (process 411), and all the OS priority variables are compared, and The OS having the higher priority is selected as the OS that operates next (process 412).

When a plurality of OS priority variables have the same maximum value, any one of the OSs corresponding to the OS priority variables may be selected. Further, when the OS whose last priority is notified is included in the plurality of OSs, the OS is selected to reduce the switching overhead.

After selecting the next operating OS, the delay request management module 203 is called (process 413). Since the processing in the case where the delay request is present will be described later, the description will be continued here on the assumption that the delay request has not existed. Processing 4
If the OS selected in step 12 is the last operating OS, that is, if the OS whose last priority was notified has the highest priority, the process 413 returns. Schedulers 309 to 359
Then, the process returns (step 414). As a result, the scheduler of the OS restarts to execute the selected task.

On the other hand, if the OS selected in the process 412 is different from the last operating OS, the delay request management module 203 calls the OS context switching module 202 to switch the operating OS. The process 413 does not return. The scheduler 309 or 35 of any OS
9 does not call the OS priority management 211, the OS priority variable corresponding to the OS is set to a fixed value, so that all tasks on the OS operate at the priority of the fixed value. It is possible to manage the priorities between OSs assuming that the OSs are operating.

FIG. 13 shows a processing flow of the OS context switching module 202. The OS context switching module 202 is called from another component in the OS switching unit 201, switches the operating OS, and creates the same state as the interrupt if necessary. The OS context switching module 202 secures and manages a context save area for each OS on the memory 102. Here, O
Only the part that processes the OS switching request from the inter-S priority management module 211 will be described.

Both the processing 421 and the processing 422 in FIG. 13 are determined to be NO, and the current value of each register of the processor 101 is saved in the context save area of the OS that was operating immediately before (hereinafter referred to as “switching source OS”). (Processing 425), and restores the values in the context save area of the OS to be operated (hereinafter referred to as “switching destination OS”) to the registers of the processor 101 (processing 426). Thereafter, the PC is restored to the stored value (process 428), and the operation resumes from the interruption point of the switching destination OS.

The process 425 will be described in more detail. Registers changed by each module in the OS switching unit 201 after entering the OS switching unit 201 are not the current values but O
The value at the time of entering the S switching unit 201 is stored. Thus, when the operation of the OS is restarted, the state before switching to the OS switching unit 201 can be completely restored.

When the process 425 is executed as a result of explicitly calling a module in the OS switching unit 201 in the form of a function call, the return address from the call function is stored as the value of the PC, and the return is performed. The return value of the call function may be stored as the value of the register indicating the value, and the values at the time of entering the OS switching unit 201 may be stored in other registers as described above. As a result, the O
When the operation of S is restarted, the calling function is executed from the state in which it returned.

According to the above-described operation, the tasks on each OS operate while sequentially switching the OSs in accordance with the priority order determined uniformly over all the OSs.

Second, the operation when an interrupt is made will be described. The interrupt described here is the above-mentioned external interrupt or internal interrupt, and the delay request interrupt will be described later.

As an interrupt processing program when an interrupt is accepted, the common interrupt handler 212 shown in FIG. 5 is called. That is, the address of the common interrupt handler 212 is set in the interrupt address register 129.
Assignment is performed assuming that the processing is performed by either the first OS 301 or the second OS 351 for each interrupt factor. Based on the assignment, the common interrupt handler 212 requests the OS context switching module 202 to generate an interrupt state for the OS.

OS context switching module 202
Calls the interrupt handlers 307 to 357 of the OS to execute the interrupt processing. Each interrupt handler issues a system call as necessary, and as a result, the scheduler may be executed and task switching may occur. For example, when the processing of the input / output device 105 is completed, an interrupt occurs,
This is a case where the suspension of the task waiting for completion of the process is released and the task is restarted. As another example, the internal time of the OS is updated due to the occurrence of an interrupt from the timer device 108, the currently executing task is interrupted to perform round-robin scheduling, and another task waiting to be executed with the same priority is performed. May be task switched. In this computer system, it is also possible to define that some interrupt factors are processed by an internal component of the OS switching unit 201.

When the interrupt is accepted, the interrupt handlers 305 to 355 on the OS that immediately performs the processing or the internal components of the OS switching unit 201 are called. Therefore, in order to prevent an interrupt having a lower necessity for the process than the process being executed from occurring during the execution of the process and preventing the interrupted process from being interrupted by the interrupt handler, , It is necessary to raise the interrupt mask level value.

FIG. 14 shows the processing flow of the common interrupt handler 212. The common interrupt handler 212 has an interrupt assignment table 231 shown in FIG. 15, and stores the value of the interrupt factor register 131 and the OS that should process the interrupt corresponding to the value of the interrupt factor register 231. The combination is recorded. In the case of the example shown in FIG.
Is set to 200 (hexadecimal) and 20
(Hexadecimal number). Also, in the following description, 200 (hexadecimal) is the timer device 1 “1”.
081 ”, 220 (hexadecimal) is an interrupt from timer device 2“ 1082 ”, 240 (hexadecimal) is a value set when an interrupt from timer device 3“ 1083 ”is accepted. I do. Here, the contents of the interrupt assignment table 231 are fixed, but the contents can be dynamically changed in response to a request from each OS or a task running on each OS.

The common interrupt handler 212 is called when an interrupt occurs, and operates with interrupts disabled. First, processor 1
With reference to the interrupt factor register 131 of 01, an interrupt factor is acquired (process 441). Next, an OS that processes the interrupt is acquired from the interrupt assignment table 231 (process 442).
Here, when the assignment is the OS switching unit 201 (process 443), the module that processes the interrupt in the OS switching unit 201 is called and the process is executed (process 445), and the process is used after the end. After returning the register to its original state, the processor's interrupt return instruction (ReTurn from)
Exception. Hereinafter, the operation is returned to the operation at the time of the occurrence of the interrupt due to “RTE” (process 446).

Here, the relationship between the interrupt factor and the module (the function to be called) in charge of the processing in the OS switching unit 201 is based on the assumption that a separate allocation table exists. It is also possible to record as part of On the other hand, if the assignment is not the OS switching unit 201, the OS context switching module 202 is requested to make the OS into an interrupt occurrence state (process 444).

In the OS context switching module 202, as shown in FIG. 13, the value of the work register used in the process is restored to the content at the time when the interrupt occurred (process 423). Here, if the OS operating at the time of occurrence of the interrupt is different from the OS (process 424), the register of the switching source OS is saved as described above (process 42).
5), restore the register of the switching destination OS (process 42)
6). Then, the interrupt handlers 307 to 3 of the OS
By setting the address 57 to the PC, the execution of the interrupt handler is started (process 429).

In the case of the contents of the interrupt assignment table 231 shown in FIG. 15, when an interrupt from the timer device 1 “1081” occurs, an interrupt is generated in the first OS 301 and the timer device 2 “1082” If an interrupt occurs, the second O
An interrupt is generated in S351. Also, the timer device 3 "1
083 ”, the OS switching unit 201
It is assumed that the internal OS state management module 207 is called. The contents of the interrupt processing performed by the OS state management module 207 will be described later.

In this embodiment, it is assumed that there are three timer devices, and each OS or OS switching unit 201 is called in response to each timer interrupt. However, only one timer device is used. Even when there is no interrupt, the same effect can be obtained by treating each of the OSs or the OS switching unit 201 as an interrupt in a predetermined order each time an interrupt from the timer device occurs.

Incidentally, a value that does not exist in the interrupt assignment table 231 may be set in the interrupt factor register 131. Also, the assigned OS in the interrupt assignment table 231
May be set as "invalid" as the fourth value. In these cases, the common interrupt handler 212 simply ignores the RTE (process 446) and ignores it, or treats it as a serious hardware error and performs processing such as error display, error recording, or computer system shutdown. , Either.

FIG. 16 shows a processing flow of the interrupt handler 307 of the first OS 301. The interrupt handler 307 is also called in a state where interrupts are prohibited, and first saves the current register contents to the interrupt stack (process 451). The interrupt factor is acquired from the interrupt factor register 131 (step 452), the interrupt mask level is set so that an interrupt having the same level as the interrupt or a lower level is not generated, and then the interrupt prohibition is released. (Step 453). After the process 453, it becomes possible to accept an interrupt with a higher interrupt level and to call and process an interrupt handler (this is called "multiple interrupts"). Then, each process corresponding to the interrupt factor is executed (process 454).

In the case of a general OS, the process 454 is configured so that a user can arbitrarily perform a process in the form of a device driver or the like. The method is clearly specified. Also, depending on the OS, processing 45
4 can also be dynamically changed during operation.
When each process is completed, the interrupt is prohibited again (process 455), and when multiple interrupts are being processed (process 456), or when scheduling has not occurred as a result of the interrupt process (process 4).
Step 57) restores the register saved on the interrupt stack in step 451 (step 460), and returns to the processing at the time of occurrence of the interrupt by the RTE instruction (step 461). On the other hand, if scheduling becomes necessary due to issuance of a system call or the like in the interrupt process, the register saved on the interrupt stack in process 451 is saved in the task management block of the task that has been operating up to that point. Region 3213
And the interrupt stack is discarded (process 458). Then, the process jumps to the scheduler 309 and interrupt handler 3
07 is terminated.

According to the operation described above, when an interrupt is accepted, the interrupt is processed by the interrupt handler while switching the OS as necessary.

Third, the operation of the inter-OS communication, particularly the operation of the inter-OS message communication function will be described.

FIG. 17 shows an outline of message communication between OSs. OS message communication is performed by the OS communication module 2
06 is provided as a function. A buffer area called a message queue exists in the inter-OS communication module 206. An ID number is assigned to the message queue to identify each.

FIG. 17 shows two message queues 241 with ID = 1 and a message queue 242 with ID = 2. In FIG. 17, the task P352 transmits the message 243 via the OS switching unit library 360. The content of the message is the message queue 24
1 once, and then the task A 302 extracts (receives) the message through the OS switching unit library 310.

As in the case of the messages 244 and 245 in FIG. 17, the message queue can hold a plurality of messages until a reception request is issued. In this case, each time a message is received, the FIFO (First In
Only one message is fetched and returned by the First Out method.

When the message of task A 302 is received prior to the message transmission of task P 352, there is no message to be taken out in message queue 241, that is, it is empty. In this case, two operations can be selected by the designation from the task A302. The first is an operation in which a message does not exist and an error occurs. The second is an operation in which the execution of the task A302 is stopped until the message is transmitted, and when the message is transmitted, the execution of the task A302 is resumed to retrieve the message. The second operation is as follows.
This is called “waiting for reception”.

The message communication between the tasks on the different OSs is realized by the above procedure. Note that the same OS message communication function is used by using the OS message communication function described here.
It is also possible to perform message communication between tasks operating on the above.

FIG. 18 shows a processing flow of the message reception processing (processing 470) of the OS switching unit library 310.
In the following description, only the case where it is specified to wait for reception when the message queue is empty will be described. In this process, an event that is one of the synchronization functions of the first OS 301 is used. Here, it is assumed that each event has an ID for identifying the event (hereinafter, referred to as “event ID”). It is assumed that each event has two states, a signal state and a non-signal state, and a system call for changing these states is provided. Also, it is assumed that an arbitrary task can wait for a signal state to be reached for an arbitrary event, and the operation is suspended without performing any CPU processing such as polling while waiting.

In the message receiving process 470, first, the OS
The reception request is made to the inter-communication module 206 by designating the ID number of the message queue and the task ID of itself (process 471). If the message queue is not empty (process 472), the process returns to the calling source together with the content of the fetched message (process 473). The same applies when an error is returned from the inter-OS communication module 206.

On the other hand, if the message queue is empty, the inter-OS communication module 206 returns a return value indicating that the process is suspended, so that the event is created in a non-signal state, and the event ID and the task ID of the own task are created. After registering with the delay request handler 305, the process waits until the event is signaled (process 474).

The event is changed to a signal state by the delay request handler 305 when a message is transmitted or some error state occurs. When the event is signaled, a message reception request is made to the inter-OS communication module 206 again, the message is taken out (process 476), the used event is deleted, and the process returns to the caller (process 47).
7). The same applies when an error is returned in the process 476. In the process 476, a “re-request flag” indicating that the request is a re-issue of a reception request after waiting for reception is added.

The inter-OS communication module 206 distinguishes the process waiting for reception by the flag from other reception requests for the message queue of the ID, and causes the process waiting for reception to take out the message. In the event waiting process of process 474, a timeout is set. If a timeout occurs (process 47)
5) A notification is sent to the inter-OS communication module 206 indicating that there are no more requests waiting to be received (process 478), the used event is deleted, and the caller returns with a timeout error. (Process 47
9).

In the above description, an event is generated and deleted each time reception standby occurs. However, an event is created in advance for each task, or several events are created and used. It is also possible to use those that are not used sequentially.

FIG. 19 shows a processing flow of the message reception processing (processing 480) of the inter-OS communication module 206.
Here, only the case where the message queue is empty and the case where the reception standby is designated is described.

The inter-OS communication module 206 has two variables, a reception waiting flag and a reception delay request issuance flag, for each message queue. The reception waiting flag is a flag indicating that there is a task waiting to receive a message because the message queue is empty, and stores the operation OS and the task ID of the task waiting to receive the message. Have been. The reception delay request issuance flag is a flag indicating that the message is transmitted after the reception standby is performed, and the message is waiting for the message to be taken out by a re-reception request from the task waiting for reception. It is.

First, when a message reception request is received, the reception waiting flag of the message queue is checked (step 48).
1) If it is waiting, an error return is made (Process 4)
82). That is, a plurality of tasks cannot wait for reception at the same time.

Next, if the reception delay request issuance flag is not set, it is checked whether a message exists in the queue (process 484), and if it exists, one message is taken out in a FIFO manner, and the message is processed in this process. Is copied to a buffer prepared by the caller of the process (step 48).
5). On the other hand, if the message does not exist, the operation OS and task ID of the requesting task are set in the reception waiting flag of the queue (step 486), and the process returns with a return value of “processing pending” indicating that reception standby has been accepted. (Step 487).

On the other hand, if the reception delay request issuance flag is set, it indicates that the message was transmitted after waiting for reception. If there is a message reception request for the queue from a task other than the task waiting for reception, that is, if the reception request does not have a “re-request flag” (process 488), the request is returned as an error (process 488). 490). On the other hand, a reception processing request from the task waiting for reception (processing 47 in FIG. 18).
6), the reception delay request issuance flag is set to OF.
F (process 489), the above-described message fetch process 485 is performed.

FIG. 20 shows a processing flow of the message transmission processing (processing 500) of the inter-OS communication module 206.

First, the transmitted message is copied to a designated queue (process 501). Next, the reception waiting flag of the queue is checked (process 502), and if it is not waiting for reception, the process directly returns to the calling source (process 506). On the other hand, if the reception waiting flag is set, the task ID recorded in the flag is taken out, the flag is cleared (process 503), and the reception delay request interrupt flag of the queue is turned on (step 503). Process 504). Then, it requests the delay request management module 203 to add a task restart delay request to the task with the task ID extracted in the process 503 so as to restart the operation of the task waiting for reception (process 505).

The delay request management module 203 may accumulate the delay request and return immediately, or may issue a delay request interrupt through the OS context switching module 202 and shift the processing to the delay request interrupt handler. is there. In the latter case, when the OS to which the task that has requested this transmission process belongs resumes the operation of the task, the process 50
The PC is evacuated so as to recover to the point of return of step 5.
As a result, in any case, a return to the caller is performed (process 506).

The processing flow of the delay request management module 203 is shown in FIGS.

The delay request management module 203 is called in roughly two situations. The first is when a new delay request occurs. In this case, the request is temporarily stored in the delay request queues 204 to 205 corresponding to the request destination OS (process 512). Second, each module in the OS switching unit 201 is connected to the OS context switching module 20.
2 requests OS switching, the common interrupt handler 2
Except for the interrupt generation request from T.12, the request is made via the delay request management module 203. Processing 5 in this case
12 is skipped (process 511).

The delay request management module 203, as shown in FIG.
09 to 210. When this flag is OFF, it indicates that a delay request interrupt is issued once to the OS and the processing of the delay request interrupt handler for the interrupt has not been completed. Further, the delay request management module 203 has a variable for recording the delay request interrupt level for each OS, and sets the delay request interrupt level for the OS in advance.

The delay request management module 203 first sets the delay request interrupt level of the first OS to
Compared with the interrupt mask level of 01, if the interrupt mask level is higher, the subsequent processing for the first OS is skipped (process 513). Next, the delay request interrupt permission flag 209 for the first OS is checked.
The subsequent processing for S is skipped (processing 514).
Since the delay request interrupt handler 305 continues the processing until all the delay requests in the first OS delay request queue 204 are taken out, it is not necessary to newly notify the occurrence of the delay request until the processing is completed.

Therefore, the determination of the process 514 is made in order to suppress the occurrence of the meaningless delay request interrupt and the accompanying OS switching. Subsequently, the first OS delay request queue 2
04 (step 515), and if there is a request, the delay request interruption permission flag 209 for the first OS 301 is turned off (step 519), and the delay request is sent to the delay request interrupt handler 305. (Step 520).

The actual generation of the delay request interrupt is performed by the OS context switching module 202. When there is a request to generate a delay request interrupt, it is determined in the process 422 in the process flow shown in FIG. 13 and is handled in the same manner as an interrupt generation request from the common interrupt handler. At this time, in processing 423, a value indicating a predetermined delay request interrupt is set in the interrupt factor register 130. This value uses a value that is not set by other interrupt factors. First OS30
1 and the second OS 351 can have the same value or different values. The interrupt handler 307 confirms that the value indicating the delay request interrupt is set in the interrupt factor register 130, and activates the delay request interrupt handler 305 as the interrupt processing 454.

Now, let us return to the description of the delay request management module 203. If a delay request interrupt has not been generated for the first OS 301, it is determined whether or not a delay request interrupt should be generated for the second OS 351 as well (steps 516 to 518). If it is determined that a delay request interrupt should occur to the second OS 351, the first OS 301
Processing 519 and processing 520 are performed in the same manner as described above.

If no delay request interruption has occurred in either the first OS 301 or the second OS 351, the reason why the delay request management module 203 was called is checked by the same determination as in the process 511, and a new delay If the call is made when a request occurs, the process returns to the caller (process 52).
2) If the OS context switching module 202 is requested to switch the OS, the process jumps to the OS context switching module 202 (process 523).

In the above description, the occurrence of the delay request interrupt is fixedly determined in the order of the first OS 301 and the second OS 351. However, another order may be used. For example, it is conceivable that the higher the interrupt level of the delay request interrupt is performed first, and when the delay request is added, the OS of the added request is performed first.

Although the state of the delay request interrupt enable flag and the comparison between the delay request interrupt level and the interrupt mask level determine whether or not an interrupt occurs, other criteria should be added. Is also possible. For example, the operation priority of an OS that can generate a delay request interrupt is determined in advance, and the delay request interrupt is generated only when the current value of the priority of the OS is lower than the predetermined priority. You can make it.

Next, a processing flow of the delay request interrupt handler 305 of the first OS 301 is shown in FIG. As described above, the delay request interrupt handler 305
7 operates as one of the interruption processes 454. As described in the interrupt handler 307, during the processing of the delay request interrupt handler 305, it is possible to receive an interrupt having a higher interrupt level than the interrupt level of the delay request interrupt to the first OS 301.

The delay request interrupt handler 305 fetches one delay request from the delay request queue 204 (process 53).
1). If it is found that no delay request remains (process 532), the first OS delay request interrupt permission flag 209 is turned on (process 533), and the process is completed.

If the delay request can be taken out, the type of the request is determined (step 534), and the corresponding processing is performed. In the case of the OS-to-OS message communication described above, a request for resuming a task that has been waiting to be received (hereinafter, referred to as a “task resumption request”) is obtained by transmitting a message. In this case, since the task ID of the task to be restarted is attached as a parameter to the task restart request, the task ID corresponding to the task ID is restarted from the set of the task ID and the event ID recorded when waiting for reception. And issues a system call to make the event into a signal state (process 535).

When the event becomes a signal state, the message receiving process (process 470) of the OS switching unit use library 310 that was being executed by the task is restarted, and the transmitted message is taken out. The delay request interrupt handler 305 repeats the request fetch (process 531) until there are no more requests in the delay request queue 204.

Note that most of the processing of the delay request interrupt handler 305 described here can be configured as a task that operates on the first OS 301 instead of the interrupt handler. That is, the delay request interrupt handler 305
The process ends only by notifying the process task of the occurrence of the interrupt. Upon receiving the notification, the processing task executes the processing of the delay request interrupt handler 305 described above. Until the processing 533 for turning on the first OS delay request interrupt permission flag 209 is executed, the delay request interrupt does not occur again, so that the conflict management between the delay request interrupt handler and the processing task is performed. No need to do.

In the description so far, the delay request interrupt handler 305 directly operates the delay request queue 204 and the delay request interrupt permission flag 209. Since the delay request management module 203 also accesses these queues and flags, contention management is required. First OS 301
The delay request interrupt handler 305 which is the above component
In order to manage conflicts between the OS and the delay request management module 203 as a component on the OS switching unit 201, complicated processing is required. To solve this, the delay request management module 203 prepares a request fetch process from the delay request queue 204 and an operation process of the delay request interrupt permission flag 209, and the delay request interrupt handler 305 calls these processes. It should be in the shape.

By the operation described above, a message communication function between tasks operating on different OSs is realized.

Fourth, other processing using the delay request will be described. As described above, since the delay request interrupt handler 305 can issue a system call of the OS, it can be used as means for realizing various processing requests from the OS switching unit 201 to each OS.

First, use of the inter-OS communication in another process will be described. When the message queue of the inter-OS message communication is full, it is possible to implement a process of waiting for a transmission request for the message queue until there is a space for storing a message in the message queue. in this case,
This can be realized by using the delay request of the task restart request as in the case of the message reception standby described above.

However, in the case of the transmission standby, unlike the reception standby, a plurality of requests may be simultaneously standby. In such a case, it is necessary to simultaneously issue a plurality of task restart requests when a large message is taken out of the message queue. In this case, it is possible to request the delay request management module 203 to add all requests collectively and store the requests in the delay request queue.

However, even if the plurality of requests are for a plurality of OSs and all of the OSs are in a state where a delay request interrupt can be issued, the delay request interrupt is issued to only one of the OSs. Unable to issue, other OS
Is delayed until the delay request management module 203 is called again.

Next, as one of the functions of the inter-OS communication module 206, a case will be described in which an inter-OS semaphore for performing conflict management between tasks operating on different OSs is implemented.

The inter-OS semaphore can be realized basically in the same manner as the transmission / reception processing of the inter-OS message communication. That is, if the acquisition of the semaphore is successful, the acquisition process returns immediately, while if the acquisition is waiting, the process returns with the process suspended. In the semaphore release processing, if there is a semaphore acquisition standby task, a task restart delay request for the task may be performed.

On the other hand, there is a case where priority inheritance is implemented as an additional function of the semaphore between OSs. This is OS
If the execution priority of the task waiting to acquire the semaphore is higher than the priority of the task that has already acquired the semaphore, the priority of the task that has already acquired the semaphore is temporarily changed. This function raises the task that is waiting to be acquired to the execution priority. For this purpose, the inter-OS communication module 206 sends a
You must ask for a task priority change. This request can be realized by adding a delay request for changing the priority of a task and issuing a task priority change system call at the time of taking out the request in the delay request interrupt handler 305.

Next, the operation of the OS when the system time is changed will be described. As described above, each OS uses RTC
RTC instead of reading and writing the time directly to 107
These requests are made to the management module 208. Second OS
When the system time managed in 351 is changed, a setting request is made to the RTC management module 208 so that the new system time after the change is reflected in the RTC 107.

FIG. 25 shows a processing flow in this case.
If the request matches, the time is actually set in the RTC 107 (process 551), and the OS is stored in the delay request management module 203.
A request is issued to issue a delay request for a “time change request” to the first server (process 552). As shown in FIG. 24, when the extracted delay request is a “time change request”, the delay request interrupt handler 305 acquires the time of the RTC 107 (process 536), and sets the system time to this value. A system call to be set is issued (process 537).

However, during the execution of the process 537, the RTC management module 208
Must be set in advance so that this RTC setting process is not called. Note that if there is a system call that matches the system time with the RTC time, the processing 536 and the processing 537 can be collectively replaced with the system call. Further, as a simpler processing, processing 53
Instead of executing step 6, it is also possible to add data of the time to be set to the parameter accompanying the delay request of “time change request” in the process 522.

Further, a request from the OS state management module 207 can be realized as a delay request.
The processing flow of FIG. 24 includes, as an example, a delay request processing of a “shutdown request”. If the extracted delay request is a “shutdown request”, the delay request interrupt handler 305 issues a system call to start shutdown (process 538). In addition to the shutdown request, when the operating state of a certain OS changes,
For example, when the OS is started, when the OS is shut down, or when the OS is abnormally stopped, a delay request for notifying this can be made to another OS. When the delay request interrupt handler 305 receives such a delay request for notifying a change in the state of the OS, the delay request interrupt handler 305 starts a task for handling the state change, and changes an event for notifying the state change to a signal state. It is possible to do.

In FIG. 5, the delay request queues 204 and 205
Is shown so that only one exists for each of the OSs 301 and 351. However, as described above, a queue is prepared for each level of importance of each delay request, and the queue is divided and stored in the corresponding queue. It is possible.

An example of the configuration of such a delay request queue is shown in FIG.
Shown in In the case of the configuration of FIG. 6, the first OS delay request queue 2
04 is a level 1 delay request queue 2041, a level 2 delay request queue 2042, a level 3 delay request queue 204
3 as an aggregate. The level 1 delay request queue 2041 receives a processing request such as a shutdown request from the OS state management module 207, the level 2 delay request queue 2042 receives a time change request from the RTC management module 208, and the level 3 delay request queue 2043 receives a task. Processing requests such as a restart request from the inter-OS communication module 206 are accumulated.

Here, the delay request interrupt handler 305
By taking out delay requests in order from the queue with the smallest level, each request is processed with priority in the order of level 1, level 2, and level 3. When the delay request fetching process is implemented in the delay request management module 203, the delay requests are fetched in order from the queue having the lowest level in the process. In FIG. 6, the delay request queue is composed of three queues, but it is also possible to change the number of queues and give priority to each queue.
It is also possible to make the interrupt level of the delay request interrupt different for each queue, or to change the operation priority of the OS that can generate the delay request interrupt.

As described above, the OS switching unit 201
A delay request is used as means for realizing various processing requests for S301 and S351. However, the delay request is not suitable depending on the processing content, and the processing needs to be performed by a callback routine called from the OS switching unit 201.

FIG. 30 shows an example of a criterion for determining whether to use the delay request or the callback routine. In the case of the criterion shown in FIG. 30, the delay request is used when there is a possibility that scheduling may occur due to the processing, or when the processing time is long and it is desired to permit the OS switching or the occurrence of the interrupt during the processing. The callback routine is used for necessary processing, processing when the interrupt processing of the OS is not performed normally, or short processing in which scheduling does not occur due to the processing. For example, the OS state management module 20
7, when the OS is forcibly stopped, the OS
You should use a callback routine without using deferred requests, as it can be used if is not working properly. However, it is possible to process a long process by a callback routine, and it is also possible to process a short process in which scheduling does not occur in a process result by a delay request.

By the operation described above, each process using the delay request is realized.

Fifth, a monitoring timer function (Watch Dog) for each OS of the OS state management module 207 is described.
Timer. Hereinafter, the operation will be described as “WDT”.

FIG. 7 is a functional block diagram of software related to the WDT function.

The OS state management module 207 has a first O
WDT counter 217 for S301 and second OS3
51 manages the WDT counter 218. These counters 217 and 218 are cleared to 0 when the WDT function for the OS 301 or 351 is started.
Also, when there is a request from the task, the WDT counter for the OS on which the task is running is cleared to zero. A 0 clear request from a task has the meaning of notifying that the task is operating, and is hereinafter referred to as “survival notification”. The common interrupt handler 212 accepts the occurrence of an interrupt from the timer device 1083 that occurs at a fixed cycle, and calls the OS state management module 207.

FIG. 26 shows a processing flow of the timer interruption processing (processing 560) of the OS state management module 207.

In the processing, first, the value is added to the WDT counter for the first OS 301 and the second OS 351 by 1 (steps 561 and 562). And WDT for the first OS
When it is determined that the counter 217 is larger than the count value corresponding to the timeout period of the first OS 301 specified in advance (process 563), the callback routine 306 of the first OS 301 is called to input / output the first OS 301. The occurrence of an interrupt from the device is suppressed (step 564), and the first O
Switching to S is prohibited (step 565). Second OS
The same processing is performed for (steps 566 to 568).

By the processing described here, a function for confirming the normality of the operation of the OS is provided. If the priority of the task for performing the existence notification is set to be high, the OS itself or the task having a very high priority (for example, the task for performing the overall processing on the OS) cannot operate. Considered abnormal.

On the other hand, if the priority of the task for which the existence notification is made is set low, the processing time is not allocated to any one of the tasks having the priority higher than the priority. Then, the operation of the OS is detected as abnormal. The priority of the task that performs the existence notification depends on the importance of each task operating on the OS and the O
The determination is made in consideration of the state of S and the processing contents of the task for performing the overall processing on the OS.

In this embodiment, when an abnormality is detected in the WDT, the operation of the OS is immediately stopped.

On the other hand, when an abnormality is detected, first, the OS is requested to stop in a proper shutdown procedure, and if there is no notice of shutdown completion within a predetermined time, the OS can be forcibly stopped. It is. To do so, the processing 5 when the WDT timeout time is exceeded
A delay request for a shutdown request to the OS is issued instead of 64 to 567, and switching to the OS is not prohibited (steps 565 to 568). In the subsequent timer interrupt processing, the WDT counter addition 56
Continue from 1 to 562.

Here, the timer is not incremented when the shutdown notification is received from the OS, but when the addition is continued without the notification and the second timeout period is exceeded, the timer is not incremented. Callback routine for performing the interrupt mask of (steps 564 to 567 in FIG. 26) and prohibition of switching to the OS (step 565)
Or 568). The procedure for forcibly stopping the OS when the shutdown completion notification is not received within the predetermined time described above is described in the following.
The present invention can be applied to all cases in which a shutdown request is issued to each OS other than when the WDT times out.

Further, it is also possible to add a procedure for automatically calling the boot process of the OS after detecting the abnormality and stopping the OS and restarting the OS. In this case, a variable for recording the number of restarts of each OS is prepared in the OS state management module 207 in order to prevent repetition of abnormality detection and restart due to defective logic of the task on the OS, and the number of restarts is specified. It is possible to add a function to suppress automatic restart when the number of times exceeds the number.

It is possible to add a function of clearing the number of restarts at a specified time interval or after a specified time has elapsed since the last restart. In addition, when an abnormality is detected again within a specified time after a request for restart, a function for suppressing automatic restart can be added by regarding that normal restart cannot be performed. It should be noted that the automatic restart process described here can be applied commonly when an abnormal termination of each OS is detected, in addition to when the WDT times out.

By the processing described above, the operation of the OS operation management module for improving the reliability of the computer system, in particular, the operation of the WDT function is realized.

Sixth, the operation of the inter-OS remote procedure call function (Remote Procedure Call, hereinafter referred to as “RPC function”) will be described.

FIG. 8 is a configuration diagram of software related to the inter-OS RPC function. A task on the first OS 301 that uses the inter-OS RPC function calls a processing function prepared in the RPC use library 311. RPC Library 3
The RPC 11 on the second OS 351 uses the inter-OS message communication function of the inter-OS communication module 206.
It requests the server 354 for processing. The message queue 219 used at this time is dedicated to sending a processing request to the RPC server 354 of the second OS 351, and its message queue ID is the RPC use library 311.
Shall know in advance.

The RPC server 354 is actually composed of a combination of an RPC management task 3541 and an RPC execution task 3542. The RPC execution task 3542 executes the requested function (procedure). Since this function is being executed in a normal task environment, a system call 358 can be issued. It is also possible to specify the system call itself as the request function. R
After the requested processing is completed, the PC management task 3541 executes an RPC dedicated to the task A302 that has issued the processing request.
The processing result is notified using the result notification message queue 220.

FIG. 27 shows a processing flow of the initialization processing (processing 580) of the RPC use library 311. This initialization process is called only once when each task uses RPC for the first time. When the task that has called this process makes a subsequent RPC process request, it creates an RPC result notification message queue 220 for receiving the process result (process 581).

FIG. 28 shows a processing flow of the RPC execution processing (processing 590) of the RPC utilizing library 311. The task performs processing 590 by passing the name of the function to be executed and the parameters.
Call. In the process 590, the function name and the parameter as specified by the request source and the initialization process 58 are sent to the RPC request message queue 219 of the second OS 351.
The message queue ID of the RPC result notification message queue 220 created in step 0 is transmitted as one request message (step 591). Then, it waits for a message notifying the result to be sent to the RPC result notification message queue 220 (process 592).

The RPC management task 354 of the second OS 351
FIG. 29 shows the processing flow of No. 1. Management tasks are always RP
It is waiting to receive the C request message queue 219, and takes out the message as soon as it arrives (process 601). When the request message is taken out, the RPC execution task 3542 is activated (process 602), and the execution function name and the parameter are passed to the RPC execution task 3542 to instruct the start of the execution (process 603). And PRC execution task 35
It waits for the execution completion message to be sent from 42 (process 604). The message here is
It is realized by using either the synchronization function or the communication function provided as a function of the second OS 351.

The PRC execution task 3542 resolves the address of the requested function by calling the system call of the second OS 351 that returns the address of the function from the function name, and executes the function. When the execution is completed, an end message including the return value of the function is sent to the RPC management task 3541. Here, since the requested process and the validity check of the parameters are not performed, the process may not be completed or the PRC execution task 3542 may be stopped.

The RPC management task 354 of the second OS 351
No. 1 sets a timeout in the execution completion message waiting process 604, and if the PRC execution task 3542 does not end normally as described above, a timeout occurs (process 605). In this case, the PRC execution task 3542 is forcibly stopped (step 608), and a timeout error result message is transmitted to the RPC result notification message queue 220 of the process requesting task.

On the other hand, if the PRC execution task 3542 finishes the processing normally and the end message is sent,
The PRC execution task 3542 is stopped (process 606), and a result message including the return value included in the end message is transmitted to the RPC result notification message queue 220 of the process requesting task (process 607).

The RPC execution process of the RPC utilization library 311 (process 590) resumes operation upon arrival of the result notification message, and returns to the process caller together with the result (process 593). Here, when a certain task calls the RPC execution processing 590, the execution of the task is interrupted until this processing ends.

The RPC management task 3541 only executes a predetermined process and does not end abnormally regardless of the content of the requested process. Further, since a timeout has been set for the RPC execution task 3542, it must be executed. A message of some processing result is sent. That is, the RPC specified in the function corresponding to process 590
It is expected that the process will return when the process is completed or the timeout occurs, and the process on another OS can be performed without being aware of the process of communicating between different OSes or the error process associated with communication. I can do it. Here, the timeout time is a fixed value held by the RPC server, but the timeout time may be specified for each individual RPC processing request.

In the configuration of the RPC server described here,
If an error occurs in the RPC execution task 3542 and the operation is forcibly stopped, the system waits until a timeout occurs in the RPC management task 3541. However, if the OS has a function of notifying the stop of the task, A configuration is also possible in which this notification is detected and an error notification is immediately sent.

In the configuration of the RPC server, the function address resolution is performed by the RPC execution task 3542. This is performed by the RPC management task 3541, and the
A configuration in which a resolved address is passed to the C execution task 3542 is also possible. Furthermore, the function address once resolved is
Record in the table placed in PC management task 3541,
When the same function is executed again, the address is obtained from the table, thereby reducing the overhead of the address resolution process. Instead of resolving a function address by a system call, a method of resolving the address in advance at the time of building the RPC management task 3541 and storing the address in the recording table is also possible.

The RPC server executes the RPC execution task 354.
The number of RPC execution tasks 3542 is one, but a plurality of RPC execution tasks 3542 may be simultaneously activated in order to simultaneously execute a plurality of RPC requests. However, in this case, it is necessary to wait for the execution completion message with a timeout for all the activated RPC execution tasks 3542. For example, a process of separately starting the same number of management subtasks as the activated RPC execution task 3542 and waiting for an execution completion message from one RPC execution task 3542 is required. Conversely, as a simple configuration, a method in which the processing of the RPC execution task 3542 is part of the RPC management task 3541 is also possible. In this case, if an exception occurs during execution of the request function, error recovery means provided by the OS (means such as a signal mechanism and structured exception handling)
To continue the operation of the task, and report the occurrence of an error as the RPC result notification message queue 220 of the process requesting task.
Must be sent to

By the processing described above, the operation of the inter-OS RPC function for easily calling the processing on different OSs is realized.

As described above, a processing request is communicated between a plurality of operating systems. Since the operating system interrupts the processing request, the operating system has one communication handler function. Communication of processing requests between operating systems can be performed by simple modification of the operating system simply by adding.

Although the above embodiment has been described with a hardware configuration, a CD-ROM is used as a program processing procedure.
It is obvious that the present invention can be implemented in a storage medium such as a ROM and using an arithmetic processing device such as a computer.

[0180]

According to the present invention, the operating system interrupts a processing request.
By simply adding one handler function for communication to the operating system, communication of processing requests between operating systems can be performed by a simple modification of the operating system.

[Brief description of the drawings]

FIG. 1 is a diagram showing a configuration of an embodiment of the present invention.

FIG. 2 is a diagram illustrating a hardware configuration of a computer system.

FIG. 3 is a diagram showing a status register when an interrupt level mask function is provided.

FIG. 4 is a diagram showing a status register when an individual interrupt mask function is provided.

FIG. 5 is a functional block diagram showing details of a software configuration.

FIG. 6 is a diagram illustrating a configuration example of a delay request queue.

FIG. 7 is a functional block diagram showing details of a software configuration.

FIG. 8 is a functional block diagram showing details of a software configuration.

FIG. 9 is a diagram illustrating an example of an internal structure of a task management block.

FIG. 10 is a diagram illustrating a management example of a task management block.

FIG. 11 is a diagram showing a processing flow of a scheduler.

FIG. 12 is a diagram illustrating a processing flow of an inter-OS priority management module.

FIG. 13 is a diagram illustrating a processing flow of an OS context switching module.

FIG. 14 is a diagram showing a processing flow of a common interrupt handler.

FIG. 15 is a diagram illustrating an example of the structure of an interrupt assignment table.

FIG. 16 is a diagram showing a processing flow of an interrupt handler.

FIG. 17 is a diagram illustrating an operation of an inter-OS message communication function.

FIG. 18 is a diagram depicting a processing flow of a message reception processing of an OS switching unit utilization library;

FIG. 19 is a diagram depicting a processing flow of a message receiving processing of the inter-OS communication module;

FIG. 20 is a diagram depicting a processing flow of a message transmission processing of the inter-OS communication module;

FIG. 21 is a first diagram illustrating a processing flow of the delay request management module.

FIG. 22 is a second diagram illustrating the processing flow of the delay request management module.

FIG. 23 is a third diagram illustrating a processing flow of the delay request management module.

FIG. 24 is a diagram showing a processing flow of a delay request interrupt handler.

FIG. 25 is a diagram depicting a processing flow of an RTC setting processing of the RTC management module;

FIG. 26 is a diagram depicting a processing flow of a timer interruption processing of the OS state management module;

FIG. 27 is a diagram depicting a processing flow of an initialization processing of an RPC-based library;

FIG. 28 is a diagram depicting a processing flow of an RPC execution processing of an RPC utilization library;

FIG. 29 is a diagram depicting a processing flow of an RPC management task;

FIG. 30 is a diagram showing an example of criteria for selecting a delay request and a callback.

FIG. 31 is a configuration diagram showing a conventional technique of an inter-OS communication function.

FIG. 32 is a configuration diagram showing another example of the conventional technology of the inter-OS communication function.

[Explanation of symbols]

101 processor, 102 memory, 103 input / output control device, 104 processor bus, 105 input / output device, 106 interrupt signal line, 107 RTC, 108 timer device, 121 CPU, 122 cache memory 123, a general-purpose register, 124, a program counter, 125, a status register, 126, an interrupt controller, 127, a save program counter, 128, a save status register, 129, an interrupt address register, 130, an interrupt factor register, 131, Data bus,
132: address bus, 141: interrupt block bit,
142: interrupt mask level field; 143: execution status register; 144: interrupt mask register;
48: interrupt mask bit, 149: privilege mode bit,
201: operating system switching program, 2
02: OS context switching module, 203: delay request management module, 204: first OS delay request queue, 205: second OS delay request queue, 206: inter-OS communication module, 207: OS state management module, 2
08 RTC management module, 209 first OS delay request interrupt permission flag, 210 second OS delay request interrupt permission flag, 211 inter-OS priority management module, 21
2 ... common interrupt handler, 217 ... first OS WDT counter, 218 ... second OS WDT counter, 219 ... R
PC request message queue, 220... RPC result notification message queue, 231.
242: message queue, 301: first OS, 351
... Second OS, 302, 303, 352, 353 ... Task, 304, 354 ... RPC server, 3541 ... RPC
Management task, 3542 ... RPC execution task, 305.3
55: delay request interrupt handler, 306, 356: callback routine, 307, 357: interrupt handler, 30
8, 358: system call, 309, 359: scheduler, 310, 360: OS switching unit use library,
311, 361: RPC library, 321: task management block, 322, 323: executable task queue, 324: execution suspended task queue

Continued on the front page (72) Inventor Nao Kato 5-2-1 Omikacho, Hitachi City, Ibaraki Prefecture Inside Omika Works, Hitachi, Ltd. (72) Inventor Tadashi Uwaki 5-2-1 Omikacho, Hitachi City, Ibaraki Prefecture F-term (reference) in Hitachi, Ltd. Omika Works 5B098 BA06 BB05 EE06 GA02 GA04 HH01 HH04

Claims (8)

[Claims] 1. A multi-operating computer system in which a plurality of operating systems are switched to operate one processor and a processing request is issued between the plurality of operating systems. Is a multi-operating computer system in which processing requests from other operating systems are interrupted. 2. A single processor is operated by switching a plurality of operating systems based on an interrupt request,
In the multi-operating computer system configured to make a processing request among the plurality of operating systems, the operating system that has received the processing request may include an interrupt handler that interrupts a processing request from another operating system. Features a multi-operating computer system. 3. A single processor is operated by switching a plurality of operating systems based on an interrupt request,
In the multi-operating computer system configured to make a processing request among the plurality of operating systems, a processing request requested by the operating system is temporarily stored in a delay request queue, and the operating system that has received the processing request is another A multi-operating computer system comprising a delay request interrupt handler for taking out a processing request from the operating system from the delay request queue. 4. A processor that generates an interrupt request and selects one of a plurality of operating systems to operate, and a switching unit that switches the plurality of operating systems based on an interrupt request from the processor. Communication means for communicating a processing request between the plurality of operating systems, wherein the operating system interrupts a processing request from another operating system. 5. A processor which generates an interrupt request and operates by selecting an operating system, a switching means for selecting and switching a plurality of operating systems based on the interrupt request of the processor, and Communication means for communicating a processing request between operating systems, wherein the operating system comprises an interrupt handler for interrupting a processing request from another operating system. 6. A processor which generates an interrupt request and operates by selecting an operating system, a switching means for selecting and switching a plurality of operating systems based on the interrupt request of said processor, Communication means for communicating a processing request between operating systems, and a delay request queue for temporarily storing the processing request transmitted by the operating system, the operating system receiving the processing request, A multi-operating computer system comprising a delay request interrupt handler for taking out the processing request from the delay request queue. 7. A multi-operating computer system in which a plurality of operating systems are switched to operate one processor and a processing request is transmitted between the plurality of operating systems by communication. A storage medium storing a program in which an operating system interrupts a processing request from another operating system. 8. A single processor is operated by switching a plurality of operating systems based on an interrupt request,
An operating system that temporarily stores a processing request transmitted by the operating system in a delay request queue and receives the processing request in a multi-operating computer system configured to transmit the processing request between the plurality of operating systems by communication; Storing a program for causing a processing request from another operating system to be fetched from the delay request queue.