Computer executing plural operating systems
Abstract
(-- 57) summary and a subject -- the operating system which should be operated is changed in consideration of the importance of the task performed on each operating system. Solution means Two or more operating systems performed according to the priority assigned to two or more processes or threads have the notice processing of a priority which notifies the priority of the process which each is performing, or a thread, The priority conversion process which changes into a common priority (normalization priority) within a computer the priority notified from each operating system, The normalization priority acquired by the priority conversion process is compared, and priority comparison processing which performs preferentially the operating system which has a higher normalization priority is performed.
Term
Term ended
Projected expiry passed 19 February 2019, 7.6 years ago.
- Priority and filed
- Published
- Projected expiry
- Today
10 claims: 10 independent, 0 dependent
- 1[Claims] 1. A memory that stores a plurality of operating systems and a plurality of processes or threads executed on the programs of the respective operating systems. A computer having a processing device that executes an operating system based on the priority assigned to each of the above processes or threads. The processing device reads the priority of the process or thread to be executed in each of the above operating systems, converts the read priority into a common priority among the plurality of the above operating systems, and obtains the above conversion result. A computer that determines the operating system to be preferentially executed based on the above, and executes the determined operating system. 【特許請求の範囲】 【請求項1】複数のオペレーティングシステムと、それぞれの上記オペレーティングシステムのプログラム上で実行される複数のプロセスまたはスレッドとを記憶したメモリと、 それぞれの上記プロセス又はスレッドに割り当てられた優先順位に基づいて、オペレーティングシステムを実行する処理装置とを有する計算機であって、 上記処理装置は、それぞれの上記オペレーティングシステムで実行すべきプロセス又はスレッドの優先順位を読み出し、それぞれ読み出された優先順位を複数の上記オペレーティングシステム間で共通の優先順位に変換し、上記変換結果に基づいて優先して実行すべきオペレーティングシステムを決定するとともに、上記決定されたオペレーティングシステムを実行する計算機。
- 2In claim 1, the memory has a priority conversion table for mapping the priorities of processes or threads to be executed by a plurality of the operating systems to the common priorities, and the processor A computer that determines the operating system that should be executed preferentially based on the above conversion table. 【請求項2】請求項1において、上記メモリは複数の上記オペレーティングシステムで実行すべきプロセス又はスレッドの優先順位を上記共通の優先順位にマッピングするための優先順位変換テーブルを有し、上記プロセッサは上記変換テーブルに基づいて優先して実行すべきオペレーティングシステムを決定する計算機。
- 3In claim 1 or 2, the processor determines a priority in each of the operating systems from a common priority among a plurality of operating systems, and a plurality of processes executed in the respective operating systems. A processor that changes the priority of the above process or thread. 【請求項3】請求項1又は2において、上記プロセッサは、複数のオペレーティングシステム間で共通の優先順位から、それぞれの上記オペレーティングシステムにおける優先順位を決定し、それぞれのオペレーティングシステムで実行される複数の上記プロセス又はスレッドの優先順位を変更する計算機。
- 4In claim 3, the memory has a priority inverse conversion table for mapping the common priorities to priorities in their respective operating systems, and the processor reverses the priorities. A computer that changes the priority of a plurality of the above processes or threads based on a conversion table. 【請求項4】請求項3において、上記メモリは、上記共通の優先順位をそれぞれの上記オペレーティングシステムにおける優先順位にマッピングするための優先順位逆変換テーブルを有し、上記プロセッサは、上記優先順位逆変換テーブルに基づいて複数の上記プロセス又はスレッドの優先順位を変更する計算機。
- 5In claims 1 to 4, when a process or thread executes a specified process, the processor raises the priority of the operating system that executes the process or thread, and the process or thread causes the process or thread. A computer that lowers the priority of the operating system when the designated process is completed. 【請求項5】請求項1乃至4において、上記プロセッサはプロセス又はスレッドが指定された処理を実行する場合に、該プロセス又はスレッドを実行するオペレーティングシステムの優先順位を上昇させ、上記プロセス又はスレッドが該指定された処理を終了した場合に、上記オペレーティングシステムの優先順位を下降させる計算機。
- 6With a plurality of processes or threads, A plurality of operating systems that execute the above-mentioned processes or threads and notify the priority of the executing processes or threads. The priority conversion process that converts the priority notified from each of the above operating systems into a common priority among the operating systems, and An information storage medium that stores a priority comparison process that compares the common priorities obtained by the priority conversion process and preferentially executes an operating system having a higher common priority. 【請求項6】複数のプロセスまたはスレッドと、 複数の上記プロセス又はスレッドを実行すると共に、実行しているプロセス又はスレッドの優先順位を通知する複数のオペレーティングシステムと、 それぞれの上記オペレーティングシステムから通知された優先順位をオペレーティングシステム間で共通の優先順位に変換する優先順位変換処理と、 上記優先順位変換処理によって得られた共通の優先順位を比較して、より高い共通の優先順位を有するオペレーティングシステムを優先的に実行させる優先順位比較処理とを記憶した情報記憶媒体。
- 7An operating system execution method for selectively executing a plurality of operating systems. By the priority conversion process, the priority of the process or thread executed in each of the above operating systems is converted into a common priority among the operating systems. An operating system execution method in which an operating system having a higher common priority is preferentially executed by comparing the common priorities obtained by the priority conversion process by the priority comparison process. 【請求項7】複数のオペレーティングシステムを選択的に実行するオペレーティングシステム実行方法であって、 優先順位変換処理によって、それぞれの上記オペレーティングシステムで実行されるプロセス又はスレッドの優先順位をオペレーティングシステム間で共通の優先順位に変換し、 優先順位比較処理によって、上記優先順位変換処理によって得られた共通の優先順位を比較して、より高い共通の優先順位を有するオペレーティングシステムを優先的に実行させるオペレーティングシステム実行方法。
- 8In claim 7, when the priority conversion process converts the priority of each operating system into the common priority, the priorities of different operating systems are changed to a common priority different from each other. How to run the operating system to convert. 【請求項8】請求項7において、上記優先順位変換処理はそれぞれのオペレーティングシステムの優先順位を上記共通の優先順位に変換するにあたって、異なったオペレーティングシステムの優先順位は互いに異なった共通の優先順位に変換するオペレーティングシステム実行方法。
- 9In claim 7 or 8, the priority conversion process converts the priority of the process or thread executed by each of the operating systems to the common priority, and at least interrupts. An operating system execution method that converts three states:the state in progress, the state in which the function of the operating system itself is executing, and the state in which there is no process to be executed into a common priority. 【請求項9】請求項7又は8において、前記優先順位変換処理は、それぞれの上記オペレーティングシステムが実行しているプロセスまたはスレッドの優先順位を上記共通の優先順位に変換するほかに、少なくとも、割込み処理中の状態,オペレーティングシステム自体の機能を実行中の状態,実行すべき処理が存在しない状態という三つの状態を共通の優先順位に変換するオペレーティングシステム実行方法。
- 10In a computer system having a plurality of operating systems that execute a plurality of processes or threads according to a priority assigned to the plurality of processes or threads, and a means for switching the plurality of operating systems. The plurality of operating systems have a priority conversion means for converting the priority of a process or thread executed by each into a common priority in the computer system, and a common priority obtained from the priority conversion means. It has a priority notification means for notifying the means for switching the order to the operating system, and the means for switching the operating system compares the common priority notified from each operating system and has a higher common priority. A computer system characterized by having a priority comparison means for preferentially executing a ranking operating system. 【請求項10】複数のプロセスまたはスレッドを該複数のプロセスまたはスレッドに割り当てられた優先順位にしたがって実行する複数個のオペレーティングシステムと、該複数個のオペレーティングシステムを切替える手段とを有する計算機システムにおいて、該複数個のオペレーティングシステムは、それぞれが実行しているプロセスまたはスレッドの優先順位を計算機システム内で共通の優先順位に変換する優先順位変換手段と、該優先順位変換手段から得られた共通の優先順位を該オペレーティングシステムに切替える手段に通知する優先順位通知手段とを有し、該オペレーティングシステムを切替える手段は、それぞれのオペレーティングシステムから通知された共通の優先順位を比較して、より高い共通の優先順位を有するオペレーティングシステムを優先的に実行させる優先順位比較手段を有したことを特徴とする計算機システム。
Independent claims10
309 paragraphs in 1 section, as filed
Description: TECHNICAL FIELD [Detailed description of the invention]
【0001】
[Technical field to which the invention belongs]
The present invention covers a computer that operates while switching a plurality of operating systems and an operating system switching method thereof, and is particularly related to a switching method of operating systems having different priority systems.
【0002】
[Conventional technology]
As a technology for operating a plurality of operating systems with one computer, a "virtual machine (VM)" has been conventionally known in a large-scale computer. In the prior art, a plurality of user tasks (hereinafter, processes and threads are unified and referred to as tasks) are switched and processed on each of a plurality of virtual computers operating in parallel in the computer. A virtual machine is usually realized as one process in a large computer, but it can also be regarded as one operating system in consideration of the relationship between the virtual computer and the user task.
【0003】
Generally, each virtual machine is given a fixed time slice (CPU allocation time) according to the priority of the virtual machine. Each virtual machine switches and operates user tasks within a given time slice. As a technology for improving the execution efficiency of such a virtual machine technology, there is a "virtual machine execution priority control method in a virtual machine" disclosed in Japanese Patent Application Laid-Open No. 5-197577.
【0004】
The prior art comprises a plurality of virtual machines and a virtual machine monitor for controlling the plurality of virtual machines. The virtual machine notifies the virtual computer monitor of the priority of the task at the start and end of execution of a task having a high execution priority such as a system task. Upon receiving this, the virtual machine monitor changes the execution priority of the virtual machine to the notified priority. By changing the execution priority of the virtual machine to the priority of the tasks executed in the virtual machine, the virtual machine can be controlled efficiently.
【0005】
[Problems to be Solved by the Invention]
With the improvement of the performance of microprocessors, especially embedded microprocessors, and the improvement of operating system functions, multiple different operating systems are operated simultaneously on one computer, and these are dynamically switched for processing. The user needs are appearing.
【0006】
In general, in the fields of machine control of factories and plants, in-vehicle navigation systems, etc., real-time ability to respond immediately to changes in the external environment and reliability that enables continuous operation for a long time are emphasized. For this reason, a real-time operating system (real-time OS) having a high interrupt response , a compact size , and a modular structure is often used. However, while the real-time OS emphasizes real-time performance and reliability, it cannot be said that it has an excellent interface with humans.
【0007】
On the other hand, the business processing operating system (business processing OS) used in a general personal computer (PC) has an excellent interhuman interface such as enabling operations using images. For this reason, there is an increasing demand for using the user interface of the paperwork OS even in fields where the real-time OS has been used in the past. However, since the paperwork OS mainly processes dialogue with humans, processing throughput is more important than interrupt responsiveness, and processing may be executed in an interrupt-disabled state for a relatively long time. In addition, it is hard to say that it is comparable in reliability to a real-time OS with a compact configuration, and it is not suitable for 24-hour continuous operation.
【0008】
However, similar to the method of operating multiple virtual machines (operating systems) in parallel on a large computer, the paperwork OS and real-time OS are operated on the same computer, and these operating systems are switched as necessary. If it can be done, it will be possible to achieve both an excellent user interface and real-time / reliability. Considering the performance improvement of microprocessors, running multiple operating systems on one computer is no longer a technology allowed only for large computers.
【0009】
At this time, considering the importance of each operating system, it is best to always give priority to the real-time OS and operate the paperwork OS only when there are no more tasks to be executed on the real-time OS. It is a simple operating system switching method. However, the importance of individual tasks running on each operating system is simply separated in this way (tasks on a real-time OS are always more important than tasks on a paperwork OS). Not necessarily.
【0010】
Figure 27 shows an example in which simple separation cannot be performed. FIG. 27 shows a configuration example of an in-vehicle navigation system. Here, the system is simplified and the in-vehicle navigation system (1) position recognition task 370 that recognizes the driving position, (2) route search task 371 that derives the shortest route to the target point, (3) buttons, touch panels, etc. It is assumed that the system consists of four tasks: interface task 372, which processes input from, and (4) game task 373, which was started during the driving break. Normally, position recognition tasks and route search tasks that require high-speed responsiveness and reliability are executed on the real-time OS111, and the paperwork OS110, which has an excellent user interface, executes interface tasks, game tasks, and the like. However, in general, route search is a very computationally intensive process and may require a few seconds of computational time. When the simple importance isolation shown above is performed, the processing of the interface task is stopped during this period, and there is a problem that the user does not recognize it no matter how many buttons are pressed.
【0011】
In the in-vehicle navigation system shown in Fig. 27, the interface task is very important, and when it shifts to the executable state, it is necessary to preferentially execute the paperwork OS. However, the prior art "virtual machine execution priority control method in a virtual machine" is premised on the same function of each virtual machine (operating system). In general, a real-time OS responds to changes in the environment at high speed, and therefore often has a considerably higher priority level than a paperwork OS. In extreme cases, on the real-time OS, the smaller the "numerical value" of the priority (closer to 0), the higher the priority, and on the paperwork OS, the larger the "numerical value" of the priority, the higher the priority. In some cases, the opposite meaning is given. In such a case, even if the two operating systems notify the priority, it is not possible to determine which operating system should be started preferentially. Therefore, in the above-mentioned prior art, it is not possible to unify and manage the paperwork OS and the real-time OS having different functions.
【0012】
An object of the present invention is an operating system to be operated in a multi-operating system control unit for operating a plurality of different operating systems on one computer, considering the importance of tasks performed on each operating system. Is to select and switch, so that important tasks are preferentially executed.
【0013】
[Means for solving problems]
In order to achieve the above object, in the present invention, a plurality of operating systems that execute a plurality of tasks according to the priority assigned to each task and a computer that switches and executes the plurality of operating systems are shown below. Perform processing.
【0014】
(1) Performs priority monitoring processing to check the priority of tasks executed by each operating system. Alternatively, a priority notification process for notifying the priority of the task being executed by oneself is performed in each operating system. In the paperwork OS and real-time OS, it may not be possible to add priority notification processing internally. At this time, it is necessary to perform the former priority monitoring process.
【0015】
(2) Priority conversion processing is performed to convert the priority of the running task obtained from each operating system to the common priority in each operating system (hereinafter, the common priority is referred to as "normalization priority". It is called "rank".). (3) The normalization priority of each operating system obtained by the priority conversion process is compared, the operating system to be operated is determined, and the priority comparison process for executing the switching of the operating system is performed.
【0016】
According to the present invention, the priority notification process is provided in each operating system, and each time the operating system switches tasks, the priority of the task is notified.
【0017】
Since the task switching function forms the core of the operating system, it is often impossible to incorporate a priority notification means into a commercially available operating system. However, in general, the operating system keeps the management information of the running task in the memory of the computer, and a part of this management information is the execution priority of the task. In addition, in order to speed up the task switching process, the priority of the currently executing task may be stored in a specific variable (priority holding variable). The priority monitoring process reads task management information or priority holding variables to check the priority of tasks executed by each operating system. The priority monitoring process confirms the priority at the timing of an external interrupt, timer interrupt, or the like.
【0018】
The priority conversion process converts the priority of the running task obtained from each operating system into a common normalization priority in the computer. Therefore, the priority conversion process may have a priority conversion table corresponding to each operating system. The priority conversion table is a correspondence table for extracting the normalization priority from the priority specific to each operating system. Although it is possible to convert individual operating system priorities to normalized priorities with simple formulas, it is better to use a priority conversion table for fast and flexible operating system switching. For example, by appropriately determining the value of the normalization priority to be stored in the priority conversion table, it is possible to perform the conversion so that the normalization priorities obtained from the individual operating systems are not equal to each other.
【0019】
The priority comparison process obtains the normalization priority of each operating system from the priority conversion process, and switches the operating system if there is an operating system with a higher normalization priority than the operating system currently operating. Do.
【0020】
BEST MODE FOR CARRYING OUT THE INVENTION
Examples of the present invention will be described with reference to the drawings.
【0021】
FIG. 1 shows the overall configuration of the first embodiment of the present invention. Usually, a computer is composed of a processor 100, a memory 101, an input / output control device 102, a disk device 104, a display 105, and the like. The processor 100, the memory 101, and the input / output control device 102 are connected by the processor bus 103. Processor 100 is a microprocessor for operating a plurality of operating systems. The memory 101 stores the business processing OS 110, the real-time OS 111, the tasks 112 to 117 running on each operating system, and the operating system switching program 118, which are operating systems. These programs are read and executed by processor 100.
【0022】
A disk device 104 for storing program data and a display 105, which is a screen display device, are connected to the input / output control device 102. Further, when a computer for factory / plant control or an embedded computer is realized, a real-time control network 106 may be connected to the input / output control device 102. Input / output devices such as sensors and actuators are connected to the real-time control network 106. Note that any or all of the input / output devices 104 to 106 of the disk device 104, the display 105, and the real-time control network 106 connected to the input / output control device 102 may be omitted depending on the system configuration. The input / output control device 102 is connected to the processor 100 by an interrupt signal line 107, and can notify the completion of input / output operation and the like. In FIG. 1, for the sake of explanation, the interrupt signal line 107 and the processor bus 103 are described as separate devices, but in reality, the interrupt signal line 107 is a part of the processor bus 103. A timer device 108 is provided inside the processor 100 to generate an internal interrupt at regular intervals. The interrupt from the timer device 108 is used for timekeeping of the operating system.
【0023】
The processor 100 is equipped with a function that can mask external interrupts notified by the interrupt signal line 107 and internal interrupts from the timer device 108 and the like. The interrupt mask is a function that delays the entry of a specific interrupt until the program cancels the interrupt mask. Generally, there are the following three types of interrupt mask functions.
【0024】
(1) All interrupt mask: Mask all interrupts.
【0025】
(2) Individual interrupt mask: Allows each interrupt to be masked.
【0026】
(3) Interrupt level mask: Set the level for each interrupt and mask interrupts below the specified level.
【0027】
Depending on the type of processor 100, it is often configured by either the combination of (1) and (2) above or the combination of (1) and (3). When a processor composed of the latter combination is adopted, the interrupt level is assigned according to the importance of the corresponding input / output device. For example, the interrupt from the real-time control network 106 is set to a higher level than the interrupt from the disk device 104, the display 105, and the like.
【0028】
In this embodiment, there are two operating systems, the paperwork OS110 and the real-time OS111, in the computer. This operating system uses the memory processor resources allocated to it to execute tasks 112 to 114 and tasks 115 to 117, respectively. Here is an example with 2 operating systems and 6 tasks (3 for each operating system), but implement operating systems and tasks that are more or less than these numbers. It is also possible to do. In this embodiment, a dynamic change in the number of operating systems is not assumed, but it is possible for each operating system to dynamically create / delete tasks. Further, in this embodiment, the paperwork OS110 and the real-time OS111 will be described, but the technique described in the present invention can be applied to any kind of operating system. Tasks 112 to 114 are paperwork tasks executed by the paperwork OS, and tasks 115 to 117 are real-time tasks executed by the real-time OS. The paperwork OS 110 and the real-time OS 111 each independently define task priorities. In the embodiment shown in FIG. 1, under the paperwork OS110 environment, tasks 112 to 114 have priorities 0,7,31, respectively, and under the real-time OS111 environment, tasks 115 to 117 have priorities, respectively. It has 0,99,255. In this embodiment, the task means a general term for a process or a thread. A process means a program that operates with a separate memory space. For this reason, one process cannot usually change the data of another process. A thread is a program that operates by sharing the memory space of a process. Therefore, there is no data protection function between threads operating in the same process.
【0029】
Within each operating system, there are priority notification modules 120,121. The priority notification modules 120 and 121 are executed at the time of task switching of each operating system, and notify the operating system switching program 118 of the priority of the task to be executed next.
【0030】
In general, the paperwork OS and the real-time OS often have different priority systems. Real-time operating systems provide high-speed response to important interrupts by having a relatively large number of priority levels. On the other hand, the paperwork OS adopts a method of improving throughput by using a relatively small priority level. Also, depending on the type of operating system, the smaller the priority value (closer to 0), the higher the priority, and the larger the priority value, the higher the priority. Therefore, it is meaningless to compare the priorities obtained from the priority notification modules 120 and 121 as they are. After that, in the paperwork OS110, the higher the priority value, the higher the task priority (task 114 has the highest priority in FIG. 1), and in the real-time OS111, on the contrary, the lower the priority value. The higher the priority of the task, the higher the priority of the task (in FIG. 1, task 115 has the highest priority). In addition, the priority in the paperwork OS 110 can be specified in the range of 0 to 31, and the priority in the real-time OS 111 can be specified in the range of 0 to 255.
【0031】
In order to eliminate the difference in the priority system between the two operating systems, the operating system switching program 118 has the priority conversion modules 122 and 123 and the priority comparison module 124 as components. The priority conversion modules 122 and 123 convert the priorities obtained from the paperwork OS110 and the real-time OS111 into normalization priorities, which are common comparison criteria in the system, respectively. It is not possible to compare the priorities of each operating system as they are, but once both are converted to normalized priorities, the priorities of the tasks performed by both operating systems can be compared. Here, the normalization priority may be exactly the same as the priority of one operating system. In this case, the priority of the operating system becomes the normalization priority as it is. The priority comparison module 124 has a role of comparing the normalization priorities obtained from both operating systems and switching to an operating system having a higher normalization priority for execution.
【0032】
Figure 2 shows an example of the internal configuration of the processor 100. The cache memory 131 is a buffer storage device that temporarily stores data or instructions on the memory 101. The CPU 130 is an arithmetic circuit, and sequentially reads and executes instructions existing in the memory 101 or the cache memory 131. When executing an instruction, a general-purpose register 132 for temporarily holding the operation result, a program counter 133 for specifying the instruction address, and a status register 134 for holding the execution state are used. The CPU 130, cache memory 131, general-purpose register 132, program counter 133, and status register 134 are connected to each other by the data bus 136, which is a plurality of signal lines for data transfer, and the address bus 137, which is a plurality of signal lines for addressing. Has been done.
【0033】
The interrupt signal line 107 and the timer device 108 are connected to the interrupt controller 135. The interrupt controller 135 has a role of generating an interrupt status signal 138 for the CPU 130. The interrupt status signal 138 is a signal indicating what kind of interrupt is currently being generated for the processor 100. Normally, the status register 134 has information about the current interrupt mask, and determines whether or not to accept the interrupt specified by the interrupt status signal 138. When accepting an interrupt, the interrupt controller 135 rewrites the values of the program counter 133, the status register 134, and the like, and executes the corresponding interrupt processing program.
【0034】
The configuration of the status register 134 is shown in FIG. Here, the case where the processor 100 is equipped with the full interrupt mask function and the interrupt level mask function is shown. In FIG. 3, the status register 134 has an interrupt block bit 140 and an interrupt mask level field 141. If the interrupt block bit 140 is ON, all interrupts to processor 100 are masked. The interrupt mask level field 141 indicates the current interrupt mask level value, and interrupt levels lower than this are not accepted. In FIG. 3, the interrupt mask level field 141 is 4 bits long. Therefore, a total of 16 types of mask levels can be specified (normally, interrupt level 0 means "no interrupt has occurred", and setting interrupt mask level 0 means "no interrupt mask is performed". By changing the number of bits in the interrupt mask level field 141, the number of types of interrupt levels that can be accepted can be increased or decreased.
【0035】
FIG. 4 shows the configuration of the status register 134 when the processor 100 is equipped with the full interrupt mask function and the individual interrupt mask function. In this example, the status register 134 is actually composed of two registers (execution state register 142 and interrupt mask register 143). Similar to FIG. 3, the interrupt block bit 140 is provided in the execution status register 142. The interrupt mask bits 144 to 147 in the interrupt mask register 143 correspond to different interrupts, and if any of the interrupt mask bits is turned ON, the corresponding interrupt will not be accepted. The status register shown in FIG. 3 is a special type of the status register shown in FIG. For example, the state where only the interrupt mask bit 144 is ON is set to level 1, the state where two interrupt mask bits 144 and 145 are ON is level 2, and the state where three interrupt mask bits 144 to 146 are ON. Can be made to correspond to levels 3, ..., and so on. Therefore, the present invention will be described below with the status register 134 having the configuration shown in FIG.
【0036】
In a general processor, when an interrupt is received, the interrupt block bit 140 is automatically rewritten to ON by the hardware, and the address of the interrupt processing program is stored in the program counter 133. If necessary, the interrupt processing program can rewrite the interrupt block bit 140 to OFF to allow interrupt acceptance. In addition, the operating system and the task can temporarily rewrite the contents of the interrupt block bit 140 and the interrupt mask register 143 to wait for the reception of a specific interrupt. The interrupt mask function is used to realize exclusive control and to prevent the same interrupt from occurring again during execution of interrupt processing.
【0037】
Next, the software configuration of the present invention realized on such hardware will be described. Figure 5 shows the internal configuration of paperwork OS110 and real-time OS111. In the figure, all the components are stored in the memory 101. Both the paperwork OS and the real-time OS manage the information of executable tasks in the form of queues 150 and 151. Executable queues 150 and 151 may be provided for each priority, but in this embodiment, all executable tasks are managed by one queue. It should be noted that even if there is only one executable queue or if it is provided for each priority, it does not affect the contents of the present invention. Since each task takes three types of states, (a) running state, (b) executable state, and (c) waiting state, the operating system separates the waiting state task, stopped state task, etc. in addition to the executable task. Manage in the queue. Note that in FIG. 5, the description of these queues is omitted. The task management tables 160 to 165 managed by the executable queues 150 and 151 store the priority of tasks to be executed, the values of program counters, status registers, and general-purpose registers at the time of task execution.
【0038】
When managing executable tasks in one queue, the task management tables registered in the executable queue are arranged in descending order of priority. That is, the management table of the task to be executed next is configured to be at the top of the queue. As described above, the paperwork OS 110 described in this embodiment has a priority from 0 to 31, and the larger the priority value, the higher the priority. In addition, the real-time OS111 has a priority from 0 to 255, and the smaller the priority value, the higher the priority. Therefore, in the paperwork OS, the management table 162 corresponding to the task 114 (priority "31") is placed at the head of the executable queue 150, and the management table 161 of the task 113 (priority "7") is subsequently arranged. , Task 112 (priority "0") is arranged in the order of management table 160. Conversely, in a real-time OS, the management table 163 corresponding to task 115 (priority "0") is placed at the top of the executable queue 151, and then the management table 164 of task 116 (priority "99"). , Task 117 (priority "255") is arranged in the order of management table 165.
【0039】
Each operating system also has interrupt handlers 152,153 that perform interrupt processing, system call programs 156,157 that provide services to tasks, and reschedulers 154,155 that perform task switching. Reschedulers 154 and 155 are activated when task switching must be performed due to task creation / deletion / stop / restart, or when an external interrupt / internal interrupt occurs. Reschedulers 154 and 155 are called after storing the execution environment (registers, etc.) of the task that was executed immediately before in the task management table, determine the task to be newly executed, and retrieve the execution environment from the task management table. By setting this in the program counter, status register, general-purpose register, etc., the selected task is executed.
【0040】
The reschedulers 154 and 155 have priority notification modules 120 and 121 inside. The priority notification modules 120 and 121 are started immediately before setting the execution environment of the task to be newly executed in the register, and notify the priority conversion modules 122 and 123 in the operating system switching program 118 of the priority of the task.
【0041】
FIG. 6 shows the internal configuration of the operating system switching program 118. The priority conversion modules 122 and 123 own the priority conversion tables 170 and 171 in order to change the priority in each operating system to the normalized priority. In this embodiment, the normalization priority is an integer in the range of 0 to 255, and is defined as "the larger the value of the normalization priority, the higher the normalization priority". Of course, it is also possible to change the range of the numerical values of the normalization priority, or to define that "the smaller the numerical value of the normalization priority, the higher the normalization priority".
【0042】
As mentioned above, the paperwork OS 110 has a priority from 0 to 31. At this time, the priority conversion table 170 becomes an array having 32 entries. Each array element has an integer in the range 0 to 255 and satisfies the following inequality (here, the name of the array is prioBusiness).
【0043】
i> jprioBusiness [i]> prioBusiness [j] (However, 0 i, j 31) Both the priority of the paperwork OS110 and the normalization priority are said to be higher as the numerical value is larger, so this condition must be satisfied.
【0044】
Similarly, if the real-time OS 111 has a priority from 0 to 255, the priority conversion table 171 becomes an array having 256 entries. Each array element has an integer in the range 0 to 255 and satisfies the following inequality (the name of the array is prioRealtime).
【0045】
i> jprioRealtime [i] <prioRealtime [j] (However, 0 i, j 255) The reason why the direction of the inequality sign is different from that of the paperwork OS is that in the real-time OS, the smaller the priority value, the higher the priority.
【0046】
In FIG. 6, when it is determined that the task 114 can be executed next on the paperwork OS 110, the priority numerical value "31" is notified from the priority notification module 120. The priority conversion module 122 can obtain the numerical value "124" of the normalization priority by using the priority conversion table 170. On the contrary, when the task 115 can be executed next on the real-time OS 111, the priority notification module 121 notifies the numerical value "0" of the priority in the real-time OS. The priority conversion module 123 uses the priority conversion table 171 to obtain the normalized priority numerical value "255". Here, in this embodiment, it should be noted that the numerical value of the normalization priority does not exceed "124" no matter how high the priority of the task of the paperwork OS 110 is. This is an extreme example of how to set the priority conversion table, and the purpose is to give priority to the tasks on the real-time OS as much as possible (even the tasks on the real-time OS have low priority). For things, tasks on the paperwork OS may take precedence). However, of course, it is also possible to change the configuration of the priority conversion table 170 so that the priorities of the two operating systems are converted to normalized priorities as equally as possible.
【0047】
The normalization priority converted by the priority conversion modules 122 and 123 is notified to the priority comparison module 124. The priority comparison module 124 holds the notified business processing OS normalization priority 172 and the real-time OS normalization priority 173. In this case, the numerical value of the paperwork OS normalization priority 172 is "124", and the numerical value of the real-time OS normalization priority 173 is "255".
【0048】
As described above, the priority notification modules 120 and 121 exist in the rescheduler and are executed when the task is switched. Since only one task is executed during the period from task switching to the next task switching, the normalization priority for the operating system does not change during this period unless the task priority changes dynamically. Since the priority notification modules 120 and 121 always notify the priority when switching tasks, the paperwork OS normalization priority 172 and the real-time OS normalization priority 173 held in the priority comparison module 124 are actually. It is a numerical value that reflects the priority of tasks in each operating system of.
【0049】
The priority comparison module 124 compares the numerical values of the normalization priority 172,173 of each operating system held with each other, and preferentially executes the operating system having the higher normalization priority. In the example of FIG. 6, the real-time OS 111 having a higher normalization priority is executed.
【0050】
In addition to the priority conversion modules 122 and 123 and the priority comparison module 124, the operating system switching program 118 has a common interrupt handler 174 that distributes generated interrupts to each operating system, and an OS-to-OS communication function that executes cooperative processing between operating systems. It has module 175, an OS context switching module 176 that switches the execution environment of two operating systems, and an interrupt mask level calculation module 177 that changes the interrupt mask according to the task priority. Details of this program will be described later.
【0051】
Figure 7 shows the processing flow of the rescheduler 154 in the paperwork OS 110. The real-time OS111 rescheduler 155 also performs the same process. In general, the rescheduler 154 cannot execute the task currently being executed at (1) at the end of timer interrupt processing, (2) at the end of external interrupt processing, (3) at the time of system call execution, or the task being executed. This module is started after saving the register of the running task to the task management table when a task with a higher priority becomes executable. System calls that may start the rescheduler 154 include (a) task creation / end / stop / restart (for example, when a task with a higher priority than you is generated), and (b) execution of exclusive control. -In addition to termination (such as when shifting to the exclusive control waiting state), there are (c) changing the priority of tasks (such as when lowering the priority of oneself).
【0052】
The rescheduler 154 first retrieves the highest priority task management table from the executable queue 150 (process 181). Here, all tasks may be in a waiting state or a stopped state, and there may be no executable task. This is determined in process 182.
【0053】
If there is no executable task, the priority conversion module 122 is notified that it is in the idle state (process 184). At this time, since there is no executable task, it shifts to the idle loop (process 186). An idle loop is a program that does nothing until a process to be executed appears. It should be noted here that in process 184, the idle status was notified to the priority conversion module 122. If the paperwork OS 110 is in the idle state, the priority comparison module 124 preferentially executes the real-time OS 111. Therefore, the idle loop is not actually executed in process 186 unless both operating systems enter the idle state at the same time. When the paperwork OS110 is executed again, there is some processing to be executed, so the idle loop is immediately exited and the process 181 is immediately entered.
【0054】
If it is determined that there is a task to be executed in process 182, the priority of the task to be executed next is fetched from the task management table and notified to the priority conversion module 122. If the notified priority is lower than the priority of the real-time OS111 (comparison by normalization priority), it will be switched to the real-time OS111 at this point. When switching from real-time OS111 to paperwork OS110, process 183 is performed unless the task to be executed becomes unexecutable or a task with a higher priority becomes executable due to interrupt processing or the like. It will be re-executed immediately after (start the task selected in process 181). As a matter of course, when the currently executing task becomes unexecutable or a task having a higher priority than the running task becomes executable, the rescheduler 154 itself is restarted. In process 185, the process of the selected task is executed by returning the register from the task management table and registering it in the register of the processor 100.
【0055】
Here, in the rescheduler 154, processes 183 and 184 correspond to the priority notification module 120. The priority notification module 121 is similarly embedded in the rescheduler 155.
【0056】
Next, FIG. 8 shows the processing flow of the priority conversion module 122 corresponding to the paperwork OS 110. The priority conversion module 122 is called from the priority notification module 120 and immediately executes the priority conversion process. First, it is determined whether or not the priority notification module 120 has notified the idle status (process 190). The idle state can also be considered to have a lower priority than any priority, so here we have a normalization priority number of (-1) so that it is lower than any normalization priority. I think it is. In process 193, this numerical value (-1) is notified to the priority comparison module 124. If it is not in the idle state, the corresponding entry is read from the priority conversion table 170 (process 191), and this is notified to the priority comparison module 124 (process 192). The same applies to the processing of the priority conversion module 123 corresponding to the real-time OS 111.
【0057】
FIG. 9 shows the processing flow of the priority comparison module 124. The priority comparison module 124 first determines whether it is the normalization priority from the paperwork OS 110 or the normalization priority from the real-time OS 111 (process 200). If it is the normalization priority of the paperwork OS 110, the obtained normalization priority is stored in the paperwork OS normalization priority 172 (process 201). If the normalization priority is from the real-time OS 111, the normalization priority is stored in the real-time OS normalization priority 173 (process 202).
【0058】
Since the normalization priority is notified only when one of the normalization priorities may have changed, here, the paperwork OS normalization priority 172 and the real-time OS normalization priority are notified. Compare the numbers of rank 173 (process 203). In this embodiment, it is assumed that the operating system having a large normalization priority value is preferentially started. Therefore, if the value of the normalization priority of the paperwork OS110 is larger than the value of the normalization priority of the real-time OS111, the operating system to be executed next is set to the paperwork OS110 (process 204). In other cases, the real-time OS111 shall be executed next (process 205). Here, even if the normalization priority of the paperwork OS 110 and the real-time OS 111 are the same, the real-time OS 111 is executed. There is no problem even if this is changed and the paperwork OS110 is executed when the normalization priorities are equal to each other. In setting the contents of the priority conversion tables 170 and 171, it is also one of the methods to simplify the system that the normalization priorities obtained from each operating system are not equal to each other.
【0059】
Next, in process 206, it is determined whether or not the newly executed operating system is equal to the operating system that has been executed so far. If you want to execute a different operating system, ask the OS context switching module 176 to save / restore the operating system execution environment (process 207).
【0060】
FIG. 10 shows the details of the interrupt handlers 152, 153, the common interrupt handler 174, the inter-OS communication function module 175, and the OS context switching module 176 (the interrupt mask level calculation module 177 will be described in detail in another drawing).
【0061】
The interrupt handlers 152 and 153 own interrupt stacks 214 and 215, respectively, as areas for storing registers and the like when an interrupt occurs and holding temporary variables. When an interrupt occurs, the register value immediately before the interrupt occurs must be saved, and this register value must be restored after the interrupt processing is completed. Therefore, interrupt stacks 214 and 215 are required. Depending on the type of processor 100 used, there is also a function that automatically switches the register when an interrupt occurs and returns to the register before switching after the interrupt processing is completed. However, when considering a system capable of multiple interrupts, an interrupt stack is required even if such hardware is used (when an interrupt with higher urgency occurs during interrupt processing, a new interrupt is required. It is necessary to preferentially execute the interrupt processing that occurred in, and then return to the original interrupt processing).
【0062】
The interrupt handlers 152 and 153 also have interrupt stack pointers 216 and 217 as pointers for indicating to what extent the interrupt stacks 214 and 215 have been used. The interrupt handlers 152 and 153 use the interrupt stack and the interrupt stack pointer to save the execution environment (registers, etc.) before the interrupt occurs, and execute necessary interrupt processing. After the interrupt processing is completed, the execution environment before the interrupt is restored and the execution of the originally running program is continued.
【0063】
The common interrupt handler 174 has a role of distributing the generated interrupt to the interrupt handlers 152 and 153. Therefore, the common interrupt handler 174 owns the execution OS storage variable 210 as an area for storing whether the currently executing operating system is the business processing OS 110 or the real-time OS 111. For example, assuming that the paperwork OS is executing the process at the time shown in FIG. 10, in this case, the "paperwork OS" is stored in the execution OS storage variable 210. Of course, it is very inefficient for the execution OS storage variable 210 to store the character string "business processing OS", so it is preferable to store it in an integer format such as: -business processing OS-> 0-real-time OS-> 1. The common interrupt handler 174 further has an interrupt handling table 211 indicating which operating system the generated interrupt corresponds to. The interrupt handling table 211 is a correspondence table showing which operating system each interrupt should be processed by. In this embodiment, as shown in FIG. 4, there are 32 types of interrupt factors. Therefore, the interrupt support table 211 is also composed of 32 entries (0 to 31). In the example of Fig. 10, interrupt factor 0 is the paperwork OS, interrupt factor 1 is the real-time OS, ..., interrupt factor 31 is the real-time OS, and so on, which operating system should be used for processing. Is defined. For efficiency, the contents of the interrupt support table 211 should be stored in the integer format instead of the character string format, as in the execution OS storage variable 210.
【0064】
Depending on the type of computer, one input / output device may be shared by two operating systems (for example, when both the paperwork OS110 and the real-time OS111 output characters and images to the display). In order to realize such a system, it is necessary to be able to dynamically change the operating system of the interrupt distribution destination. This is the reason why the distribution destination operating system is obtained from the interrupt support table 211 instead of being fixed in this embodiment. By changing the contents of the interrupt support table 211 according to the usage status of the I / O device, the interrupt distribution destination can be changed dynamically.
【0065】
The common interrupt handler 174 uses the execution OS storage variable 210 to determine the type of operating system currently running, and if this does not match the distribution destination operating system obtained from the interrupt support table 211, the OS context switching module. Ask 176 to switch. After the operating systems match or the switching of the operating system is completed, the interrupt handler of the corresponding operating system is requested to process. The execution OS storage variable 210 is also referred to by the OS context switching module 176. As described above, the internal structure of each module in the operating system switching program 118 is not necessarily occupied by each module, and each module can be shared as needed.
【0066】
The OS context switching module 176 is started when the operating system must be switched as a result of priority comparison or as a result of an interrupt. To switch between the two operating systems, you must own an area to store these execution environments (ie, register values). Here, a save context 212 for the paperwork OS is prepared as an area for saving the execution environment of the paperwork OS, and a save context 213 for the real-time OS is prepared as an area for saving the execution environment of the real-time OS. The OS context switching module 176 saves the execution environment in the storage context corresponding to the currently running operating system, then reads the execution environment from the other storage context and sets it in the register of processor 100. This makes it possible to switch operating systems.
【0067】
The inter-OS communication function module 175 is a program for tasks on two operating systems to communicate and cooperate with each other. Here, it is assumed that there are a shared memory 218 that can be used by both the paperwork OS 110 and the real-time OS 111, and a lock acquisition module 219 and a lock release module 220 for exclusive control between operating systems. The shared memory 218 is a part of the memory 101 and is an area that can be referred to by both operating systems. The memory other than the shared memory 218 is basically divided into an area for paperwork OS, an area for real-time OS, and an area for operating system switching program, which are occupied by paperwork OS110, real-time OS111, and operating system switching program 118, respectively. Is used. When tasks on two operating systems use shared memory 218, exclusive control is usually used to maintain the consistency of data on shared memory 218. When the application program performs exclusive control across operating systems, the functions provided by the lock acquisition module 219 and the lock release module 220 are used.
【0068】
At this time, attention must be paid to a situation called priority inversion. The priority inversion phenomenon generally means the following states.
【0069】
(1) Task α, which has a low priority, is started first to acquire a lock.
【0070】
(2) Next, task β, which has a high priority, is started and shifts to the lock wait state. (3) Next, task γ, which is a medium priority, is started, and task α (low priority) is switched to task γ (medium priority).
【0071】
At this time, the execution of the task γ hinders the execution of the task α, and as a result, the time until the high priority task β acquires the lock is extended. The priority inversion phenomenon is usually solved by using a priority inversion method or a priority inheritance method.
【0072】
The priority increase method is a method of raising the priority of the task that acquired the lock to a certain level. As a result, the priority of the task α for which the lock has been acquired is temporarily higher than that of the task γ (medium priority), and even if the task γ is started, the task α is executed until the lock is released. After this, the task β, which has a high priority, acquires the lock and continues the process.
【0073】
The priority inheritance method is a modification of the priority increase method to provide flexibility. In the priority inheritance method, if the priority of the task (in the example, task β) that has transitioned to the lock waiting state is higher than that of the task that has acquired the lock (task α), this priority is inherited by the task that is acquiring the lock. It is a method to make it. Here, the task α inherits the priority of the task β only while the lock is being acquired. In some cases, such as when exclusive control is performed by low-priority tasks, it is not always necessary to raise the priority to a certain level, and the priority inheritance method is a method that can deal with such a situation.
【0074】
The lock acquisition module 219 and the lock release module 220 described in this embodiment can implement such a priority increase or priority inheritance method between operating systems. Priority increase / inheritance between operating systems is performed using normalization priority.
【0075】
Hereinafter, among the modules shown in FIG. 10, the processing flows of the OS context switching module 176, the common interrupt handler 174, the interrupt handler 152, the lock acquisition module 219, and the lock release module 220 will be described. Since the interrupt handler 153 has the same processing flow as the interrupt handler 152, the description thereof will be omitted.
【0076】
FIG. 11 shows the processing flow of the OS context switching module 176.
【0077】
The OS context switching module 176 is called only when the operating system must be switched, and a check to see if switching is necessary is performed before the call. Therefore, first check only which operating system you should switch to (Process 230). Here, when switching from the paperwork OS110 to the real-time OS111 (when the current executing operating system is the paperwork OS110 and the priority of the real-time OS111 is high), it is used in the storage context 212 for the paperwork OS. Save the value of the middle register (process 231). Next, by restoring the execution environment from the storage context 213 for the real-time OS and setting it in the register (process 232), the real-time OS 111 can be re-executed from the previously saved state. When switching from the real-time OS 111 to the paperwork OS 110, conversely, the value of the register in use is saved in the real-time OS save context 213 (process 233), and then the register is restored from the paperwork OS save context 212. (Processing 234). In either case, finally, the type of operating system after switching is written to the execution OS storage variable 210 (process 235).
【0078】
FIG. 12 shows the processing flow of the common interrupt handler 174. Generally, in a computer controlled by a single operating system, all interrupts are processed once by a module called an interrupt handler, and then distributed to each program. However, in a computer that operates a plurality of operating systems as described in this embodiment, the common interrupt handler accepts all interrupts and distributes them to the interrupt handlers of the corresponding operating systems. .. In allocating interrupts to each operating system, when an interrupt occurs, an operating system other than the interrupt target may be executing processing. In this case, it is necessary to switch to an operating system that supports interrupts, and the common interrupt handler also has such a role.
【0079】
After the interrupt occurs, the common interrupt handler 174 first extracts the contents of the execution OS storage variable 210 and checks whether the currently executing operating system is the paperwork OS 110 or the real-time OS 111 (process 240). .. Next, the interrupt support table 211 is used to obtain which operating system the generated interrupt corresponds to (process 241). For example, if the interrupt support table 211 in FIG. 10 is used, the paperwork OS110 is generated when the interrupt "0" is generated, and the real-time OS111, ..., and the interrupt "31" are generated when the interrupt "1" is generated. If it does occur, you can get a corresponding operating system, such as real-time OS111. Here, it is checked whether or not the operating system to be interrupted is equal to the running operating system (process 242).
【0080】
If the interrupt generated is not for the currently running operating system, the operating system must be switched once. This switching process is performed by requesting the OS context switching module 176 (process 243). Next, it is checked whether the interrupt target operating system is the paperwork OS 110 or the real-time OS 111 (process 244), and if the target is the paperwork OS 110, the interrupt handler 152 of the paperwork OS is started (process 245). If an interrupt to the real-time OS 111 has occurred, the interrupt handler 153 of the real-time OS will be started (process 246). In general, interrupt handlers 152 and 153 call reschedulers 154 and 155 when task switching must be performed by interrupt processing, and do not return control to the common interrupt handler 174. However, if task switching does not occur, the interrupt handler processing ends as it is. At this time, the interrupt handlers 152 and 153 return control to the common interrupt handler (described later in FIG. 13), and the common interrupt handler resumes operation from process 247. Process 247 is a process for checking whether or not the operating system has been switched when an interrupt occurs. If the operating system is switched by process 243, it is necessary to switch the operating system again and return to the original execution environment. The fact that task switching does not occur means that the normalization priorities of both operating systems have not changed, and it is necessary to return to the execution state before the interrupt occurred. Therefore, the OS context switching module 176 is requested again to execute the switching process (process 248).
【0081】
When the interrupt handler of each operating system executes the reschedulers 154 and 155, control does not return to the processing 247 of the common interrupt handler as described above. In this case, the reschedulers 154,155 notify the priority conversion modules 122,123 of the priority of the new task. As a result, the priority comparison module 124 determines whether or not to switch the operating system.
【0082】
The configuration of the common interrupt handler 174 can be changed as shown in FIG. 28. The common interrupt handler 174 shown in FIG. 29 owns the interrupt priority correspondence table 380 in addition to the components of the common interrupt handler shown in FIG. The interrupt priority correspondence table 380 is a correspondence table showing what normalization priority the interrupt handler must operate. In the example of FIG. 29, the interrupt handler corresponding to the interrupt factor 0 must operate at the normalization priority 255, and the interrupt handler corresponding to the interrupt factor 31 must operate at the normalization priority 224. Must be. When the common interrupt handler 174 starts the interrupt handler of each operating system, the normalization priority of the operating system is updated according to the interrupt priority correspondence table 380, and the original normalization priority is given after the interrupt handler ends. Restore the ranking. In this example, it is assumed that the common interrupt handler 174 has the interrupt priority correspondence table 380, but the interrupt priority correspondence table 380 is provided in the priority conversion modules 122 and 123, and the priority conversion is requested from the common interrupt handler 174. It is also possible to adopt a configuration.
【0083】
If the normalization priority can be assigned to interrupts as shown in FIG. 29, the normalization priority can be assigned to all operating states of each operating system. For example, an operating system generally has the following four types of operating states.
【0084】
(1) idle state (2) Task execution status (3) Processing status of the operating system itself (for example, initialization processing) (4) Interrupt processing status It is also possible to assign normalization priorities to all of these. In this case, generally considered, the interrupt processing state must operate with the highest priority, and the highest normalization priority is assigned. Next, the normalization priority is assigned in the order of the processing state of the operating system itself, the task execution state, and the idle state.
【0085】
FIG. 13 shows the processing flow of the interrupt handler 152 of the business processing OS called from the common interrupt handler 174. First, the in-use register is saved on the interrupt stack 214 (process 250), and interrupt processing is executed (process 251). Here, it is checked whether or not the operating system is rescheduling (that is, whether or not the process of rescheduler 154 is being executed) (process 252). Rescheduling means that the task to be executed next is being selected and the task is not actually being executed. Therefore, if you want to simplify the processing of the operating system, in this case, you can restart the rescheduling from the beginning. That is, when it is determined that rescheduling is in progress, the save register of the interrupt stack is discarded (process 257), and the rescheduler 154 is started from the beginning (process 258). Even if an interrupt occurs during rescheduling, it may not be necessary to reselect the task to be executed. This method may not be efficient because rescheduling will be performed from the beginning even in this situation. Therefore, it is also possible to use a method of registering a process (for example, task start / end) that occurs during rescheduling and affects the execution of the rescheduler 154 in a queue or the like. In this case, the processes registered in the queue are collectively executed before the end of the rescheduler 154 or in the priority notification module 120. When this method is adopted, it is not necessary to redo the rescheduling that was executed halfway every time an interrupt occurs. However, after collectively executing the processes registered in the queue, it is necessary to recheck whether rescheduling is required again.
【0086】
In this embodiment, the former method will be used for simplification. However, when using the latter method, (a) Flag indicating whether rescheduling is in progress (b) Processing queue Should be prepared. In a system call provided by the operating system, a process that affects the execution of the rescheduler 154 is registered in the queue if it is being rescheduled. Further, a module that collectively executes the processes registered in the queue is inserted into the process flow of the rescheduler 154.
【0087】
If the interrupt handler 152 determines that it is not being rescheduled, the operating system is performing some task at that time. Therefore, first of all, it is determined whether or not task switching is necessary (process 253). If task switching is not necessary (if the currently executed task has the highest priority and can be executed), the processing of the interrupt handler 152 is terminated as it is. Therefore, the register value saved on the interrupt stack 214 is restored (process 254), and control is returned to the common interrupt handler (process 255). When it is determined that task switching is necessary, the value of the register saved on the interrupt stack 214 is copied to the task management table (process 256), and the save register on the interrupt stack is discarded (process 257). After this, the rescheduler 154 is started (process 258). If the processor 100 has a function that can refer to the data on the memory 101 and increase or decrease the value of the interrupt stack pointer 216 at the same time, the process 256 and the process 257 can be executed together.
【0088】
Next, the processing flow of the lock acquisition module 219 and the lock release module 220 will be described. Here, an example of using the priority increasing method will be described, and an example of using the priority inheritance method will be described later. Here, the task that requested lock acquisition / release and the operating system that manages it are called own task and own operating system, and the other operating system is called another operating system.
【0089】
FIG. 14 shows the processing flow of the lock acquisition module 219 using the priority increase method. The lock acquisition module 219 first checks whether a task of another operating system is acquiring a lock (process 260), and if not, sets its own operating system to be the owner of the lock. (Processing 261). If a task on another operating system is acquiring a lock, the task is put into a wait state until the lock is released (process 263). At this time, another operating system must be given priority to execute, and the lock must be released promptly. Therefore, the normalization priority of another operating system stored in the priority comparison module 124 is changed to be higher than that of the own operating system (process 262). If the task is moved to the waiting state in process 263, the rescheduler is started in the local operating system. As a result, the rescheduler calls the priority notification module, priority conversion module, and priority comparison module in sequence, and switches to another operating system with a higher normalization priority.
【0090】
FIG. 15 shows a processing flow of the lock release module 220 when the priority increase method is used. First, it releases its own lock (Process 270). Next, it checks whether another operating system is waiting for lock acquisition (process 271). If it is not waiting for lock acquisition, the normalization priority has not been raised. Therefore, the process of the lock release module 220 is terminated as it is. However, if another operating system is waiting for lock acquisition, the normalization priority should be raised in order to solve the priority inversion phenomenon. Therefore, the normalization priority of the local operating system is returned to the original value (process 272), and then the task waiting for lock acquisition in another operating system is moved to the executable state (process 273). If task switching occurs by making the task waiting for lock acquisition executable, the rescheduler of another operating system is started, and as in the case of the lock acquisition module described above, the priority comparison module 124 is finally executed. Ru. This compares the importance of the operating system using the original normalization priority and selects the operating system with the higher normalization priority.
【0091】
Next, an example of using the priority inheritance method will be described. In this case, each operating system must be equipped with priority setting modules 280,281 that change the priority of tasks according to the normalization priority, as shown in FIG. In addition, the priority conversion modules 122 and 123 must be equipped with a function of converting the priority to the normalization priority and a function of converting the normalization priority to the priority. Therefore, the priority conversion modules 122 and 123 have a priority inverse conversion table 282,283 containing the normalized priority as an index and the priority of each operating system as the content.
【0092】
The operating system generally has a function of changing the priority of tasks as a system call. The priority setting modules 280 and 281 convert the given normalization priority into the priority corresponding to each operating system, and change the priority of the task by using a task priority change system call or the like. The reverse priority conversion table 282,283 has a role of supporting the function of the priority setting module 280,281. In this embodiment, since the normalization priority is 0 to 255, the priority inverse conversion table 282,283 is an array having 256 entries. Further, since the priority range of the paperwork OS 110 is 0 to 31, each array element of the priority inverse conversion table 282 has an integer in the range of 0 to 31 and has the following inequality. Satisfied (name the array revBusiness).
【0093】
i> jrevBusiness [i] revBusiness [j] (However, 0 i, j 255) Since the real-time OS 111 has a priority of 0 to 255 and the smaller the priority value is, the higher the priority is. Therefore, each array element of the priority inverse conversion table 283 is any of 0 to 255. It has an integer of and satisfies the following inequality (the name of the array is revRealtime).
【0094】
i> jrevRealtime [i] revRealtime [j] (However, 0 i, j 255) By the way, in this embodiment, since the numerical value of the normalization priority is 0 to 255 and the numerical value of the priority of the real-time OS is 0 to 255, the correspondence between the normalization priority and the priority of the real-time OS is associated. It can be done one-on-one. Therefore, the priority inverse conversion table 283 can be uniquely derived from the priority conversion table 171. However, since the numerical value of the priority of the paperwork OS is 0 to 31, the priority inverse conversion table 282 cannot be uniquely determined. In this case, for example, the priority of the paperwork OS corresponding to the normalization priority "1" cannot be derived from the priority conversion table 170. Therefore, for the normalization priority that cannot be uniquely determined, the priority of the paperwork OS is appropriately determined so as to satisfy the above inequality.
【0095】
Of the priority conversion modules 122, the processing flow of the priority reverse conversion function is shown in FIG. Here, the priority of the paperwork OS corresponding to the specified normalization priority is taken out from the priority reverse conversion table 282 (process 290), and the priority is notified to the priority setting module 280 (process 291). The priority conversion module 123 also has a similar priority reverse conversion function.
【0096】
The processing flow of the priority setting module 280 for this is shown in FIG. The priority setting module 280 first requests the priority conversion module 122 to convert the normalization priority to the priority of the paperwork OS (process 292). Next, the priority of the task is changed by using the priority change system call of the paperwork OS (process 293). The same applies to the processing of the priority setting module 281 in the real-time OS 111.
【0097】
Next, the method of realizing the priority inheritance method using these priority reverse conversion functions and priority setting modules will be described.
【0098】
FIG. 19 shows the processing flow of the lock acquisition module 219 that uses the priority inheritance method. The lock acquisition module 219 first checks whether another task is acquiring the lock (process 300), and if not, sets the own task to be the owner of the lock (process 301). .. If another task is acquiring the lock, it is necessary to shift the task to the wait state until the lock is released (process 304). At this time, the task during lock acquisition must be preferentially executed so that the lock can be released promptly. Compare the normalization priority of the task acquiring the lock with the normalization priority of the own task (process 302), and if the normalization priority of the task acquiring the lock is low, let the task inherit the priority of the own task (process 302). Process 303). Priority inheritance can be performed by requesting the priority setting module of the operating system that executes the task for which the lock is being acquired to set the priority by specifying the normalization priority of the own task. If the normalization priority of the task being locked is already higher than the normalization priority of the own task, there is no need to inherit the priority, and the task can be immediately moved to the waiting state.
【0099】
FIG. 20 shows a processing flow of the lock release module 220 using the priority inheritance method. First, it releases its own lock (process 310). Next, it checks whether another task is waiting for lock acquisition (process 311). If it is not waiting for lock acquisition, it means that normalization priority inheritance has not been performed, and the processing of the lock release module 220 ends as it is. However, if another task is waiting for lock acquisition, normalization priority inheritance should have been performed. Therefore, request the priority setting module to return the normalization priority of the own task to the original value (process 312), and then move the task waiting for lock acquisition to the executable state (process 313). ..
【0100】
Although the description is omitted in this embodiment, if an interrupt occurs during execution of the lock acquisition module 219, lock release module 220, etc., and task switching occurs, the data indicating the lock owner will be inconsistent. It can occur. Therefore, normally, the interrupt mask function suppresses the occurrence of interrupts during the execution of these processes.
【0101】
The program modules and processing flows shown in FIGS. 16 to 20 make it possible to use the priority inheritance method in exclusive control between operating systems. Actually, by using the processing flows shown in FIGS. 19 and 20, it is possible to inherit the normalization priority within one operating system.
【0102】
Figure 21 shows the internal structure of the interrupt mask level calculation module 177. The interrupt mask level calculation module 177 is a function that converts the normalization priority into an interrupt mask level and masks a specific interrupt if the normalization priority is above a certain level. This is a function based on the idea that a task having a certain level of normalization priority or higher must be executed with priority over interrupt processing. Therefore, if a system call or the like has a function of masking interrupts, the system can be sufficiently established even if this function does not exist. However, as an advantage of the interrupt mask level calculation module 177, the interrupt mask may be automatically executed when the normalization priority exceeds a certain value.
【0103】
To execute the interrupt mask, the interrupt mask level calculation module 177 owns the interrupt mask conversion table 320. The interrupt mask conversion table 320 is a conversion table for obtaining the interrupt mask value from the normalization priority. As shown in FIG. 4, this embodiment targets a computer architecture that can individually mask 32 types of interrupt factors, so that each entry in the interrupt mask conversion table 320 has 32-bit length data. However, as shown in FIG. 3, the 4-bit interrupt mask level can be used to reduce each entry in the interrupt mask conversion table 320 to a 4-bit length. Here, in the embodiment shown in FIG. 21, for example, the interrupt mask value corresponding to the normalization priority "0" is 0x00000000, and the interrupt mask value corresponding to the normalization priority "255" is 0xffffffff. This means that if the normalization priority is "0", all interrupts are allowed, and if the system is operating with the highest normalization priority, all interrupts are masked. The priority comparison module 124 notifies the interrupt mask level calculation module 177 of the normalization priority of the currently running operating system, so that the necessary interrupt mask can be automatically performed.
【0104】
Figure 22 shows the processing flow of the interrupt mask level calculation module 177. Here, first, the interrupt mask value corresponding to the normalization priority is extracted from the interrupt mask conversion table 320 (process 330). Next, the obtained interrupt mask value is set in the interrupt mask register 143 or the like, and the interrupt mask is executed (process 331).
【0105】
The first embodiment of the present invention has been described above. By using this embodiment, it is possible to switch operating systems according to the priority of the tasks executed by each operating system. In this embodiment, the priority notification module must be incorporated in each operating system and modified to notify the change of priority at each rescheduling. However, it is often not possible to make such modifications, such as when using a commercial operating system. Hereinafter, a second embodiment of the present invention for dealing with this will be described.
【0106】
FIG. 23 is a block diagram showing a second embodiment of the present invention. The paperwork OS110 and the real-time OS111 shall hold the priority of the currently executing task (execution priority 340,341), respectively. For each operating system, the numerical priority stored in the task management tables 162,163 at the head of the executable queues 150 and 151 shown in FIG. 5 is the execution priority 340,341. In addition, when there are a plurality of executable queues for each priority, generally, a pointer indicating where the highest priority executable queue exists at the present time or a variable indicating the highest priority numerical value itself. (Priority holding variable) is often prepared. In the former case, the execution priority 340,341 can be obtained by following the executable queue from the pointer and referring to the task management table, and in the latter case, reading the priority holding variable itself.
【0107】
A new priority monitoring module 344 is provided in the operating system switching program 118. The other modules, the priority conversion module 122,123, the priority comparison module 124, the common interrupt handler 174, the inter-OS communication function module 175, the OS context switching module 176, and the interrupt mask level calculation module 177 are the first embodiments. It has the same configuration and processing flow as the contents explained in. Within each operating system, there are no priority notification modules 120,121.
【0108】
The priority monitoring module 344 owns the paperwork OS execution priority storage value 342 and the real-time OS execution priority storage value 343. The priority monitoring module 344 is started periodically to monitor the execution priority 340,341 of each operating system. Here, if the memorized execution priority 342 or 343 and the current execution priority 340 or 341 are different, it is recognized that the priority has changed, and a new execution is performed in the priority conversion module 122 or 123. Notify the priority.
【0109】
Figure 24 shows the processing flow of the priority monitoring module 344. First, the execution priority 340 of the paperwork OS is read out and compared with the execution priority storage value 342 of the paperwork OS (process 350). This makes it possible to recognize whether or not the priority of the paperwork OS has changed. If the priority has not changed, nothing is executed and the process proceeds to process 353. If the priority has changed, the execution priority 340 of the paperwork OS is registered in the paperwork OS execution priority storage value 342 (process 351), and then the priority is registered in the paperwork OS priority conversion module. Notify 122 (process 352). The same processing is performed for changes in the execution priority of the real-time OS111. First, the real-time OS execution priority 341 and the real-time OS execution priority storage value 343 are compared (process 353), and if there is no change in the priority, the process ends. If the priority has changed, the real-time OS execution priority 341 is registered in the real-time OS execution priority storage value 343 (process 354), and this is notified to the real-time OS priority conversion module 123 (process 355). ..
【0110】
It should be noted that control does not return to the priority monitoring module 344 when the operating system is switched as a result of notifying the priority conversion module of the priority. Therefore, it can be said that the monitoring method shown in FIG. 24 always gives priority to the change in the priority of the paperwork OS 110. In order to make the monitoring of both operating systems equal, count the number of startups of the priority monitoring module 344, and (1) monitor the priority change of the paperwork OS110 if the number of startups is odd. (2) If the number of boots is even, it is necessary to change the processing flow to monitor the priority change of real-time OS111.
【0111】
It should be noted that the priority monitoring module 344 is started "on a regular basis" to monitor changes in priority. In order to realize periodic processing, the priority monitoring module 344 may be started by a timer interrupt. Here, focusing on the fact that all interrupts including timer interrupts and external interrupts are collectively processed by the common interrupt handler 174, a method of embedding the priority monitoring module 344 in the common interrupt handler 174 will be described. Figure 25 shows the processing flow of the common interrupt handler 174 in which the priority monitoring module 344 is embedded. In the figure, the processes 240 to 248 are all equal to FIG. Startup of priority monitoring module 344 (process 360) may cause an operating system switch. Therefore, it must be embedded after the execution of the interrupt handler (processing 245,246). When the interrupt handlers 152 and 153 return control to the common interrupt handler 174, the priority change is automatically monitored and the operating system is switched if necessary. If the priority monitoring module 344 determines that it is not necessary to switch the operating system, the processing of the common interrupt handler 174 is terminated as it is.
【0112】
In the second embodiment of the present invention, there is no means for notifying the priority conversion module of the priority change immediately after rescheduling. That is, the change in priority is checked at regular intervals, and the operating system is not switched immediately in response to the change in priority. Therefore, the second embodiment of the present invention can realize a computer without modification inside the operating system, but is characterized in that the switching efficiency is inferior to that of the first embodiment.
【0113】
The second embodiment of the present invention satisfies the condition that the internal parts of both operating systems are not modified. For example, a condition occurs that the real-time OS111 can be modified but the paperwork OS110 cannot be modified. Sometimes. In this case, as a third embodiment of the present invention, it is also possible to realize a computer in which the priority notification module 121 is mounted inside the real-time OS 111, and the priority monitoring module 344 monitors only the priority change of the paperwork OS 110. It is possible (Fig. 26).
【0114】
Also, instead of incorporating the priority notification module inside the rescheduler, the priority notification module is installed in the part that is started regularly, such as inside the timer interrupt processing module of each operating system, as a substitute for the priority monitoring module 344. It is also possible to do.
【0115】
When the present invention described above is applied to the in-vehicle navigation system shown in FIG. 27, it is possible to accept input from the user even when a route search task having a long processing time is operating. That is, in this case, the interface task is given a higher normalization priority than the route search task. At this time, if the user presses a button and the interface task operates, the business processing OS that operates the task with higher normalization priority is switched, and as a result, the long-processing route search task is operating. Interface tasks will also be executed.
【0116】
Further, even in a virtual machine that executes a plurality of operating systems, by applying the present invention, operating systems having different priority systems can be executed according to the priority of tasks to be executed.
【0117】
From the above, according to the present invention, it is possible to construct a computer having both the user interface of the business processing OS and the reliability of the real-time OS.
【0118】
All of the first to third embodiments have a configuration in which priority conversion is performed inside the operating system switching program 118. However, since the priority conversion modules 122 and 123 individually correspond to the paperwork OS110 and the real-time OS111, respectively, these may be installed inside each operating system. A fourth embodiment with such changes is shown in FIG.
【0119】
In this embodiment, first, the priority conversion modules 122,123 convert the priority in each operating system into the normalized priority. In response to this, the priority notification modules 120 and 121 notify the priority comparison module 124 of the normalization priority of each operating system.
【0120】
In this embodiment, the interfaces between the paperwork OS 110, the real-time OS 111, and the operating system switching program 108 are all performed according to the normalization priority. In the first to third embodiments, when the executable task exists, the priority of the task is notified, and when the executable task does not exist, the idle state is notified. In these cases, the idle state or the state in which the operating system itself has to perform some processing cannot be freely mapped to the normalization priority. In this embodiment (fourth embodiment), since the priority is converted into the normalized priority in each operating system, it is possible to freely map the states other than the task execution to the normalized priority.
【0121】
[Effect of the invention]
According to the present invention, in a computer in which a plurality of operating systems are operated by a single processor, operating systems can be switched according to the priority of tasks executed by each operating system, and more important tasks are prioritized. Can be executed. Further, in the present invention, the priority conversion module converts the priority into the normalized priority, thereby comparing the priorities between the operating systems. Therefore, even a computer that executes operating systems having different priority systems can be executed. , Real-time performance and efficiency are not impaired.
[Simple explanation of drawings]
[Figure 1]
It is a figure which shows the system configuration in the 1st Example of this invention.
[Figure 2]
It is a figure which shows the hardware configuration of a computer.
[Fig. 3]
It is a figure which shows the status register when the interrupt level mask function is equipped.
[Fig. 4]
It is a figure which shows the status register when the individual interrupt mask function is equipped.
[Fig. 5]
It is a figure which shows the operating system internal structure in detail.
[Fig. 6]
It is the first figure which shows the internal structure of an operating system switching program in detail.
[Fig. 7]
It is a figure which shows the processing flow of a rescheduler.
[Fig. 8]
It is a figure which shows the processing flow of a priority conversion module.
[Fig. 9]
It is a figure which shows the processing flow of a priority comparison module.
[Fig. 10]
It is a second figure which shows the internal structure of an operating system switching program in detail.
[Fig. 11]
It is a figure which shows the processing flow of the OS context switching module.
[Fig. 12]
It is a figure which shows the processing flow of a common interrupt handler.
[Fig. 13]
It is a figure which shows the processing flow of an interrupt handler.
[Fig. 14]
It is a figure which shows the processing flow of the lock acquisition module in the priority raising method.
[Fig. 15]
It is a figure which shows the processing flow of the lock release module in the priority raising method.
[Fig. 16]
It is a figure which shows the priority setting module internal structure in detail.
[Fig. 17]
It is a figure which shows the processing flow of the priority reverse conversion function in a priority conversion module.
[Fig. 18]
It is a figure which shows the processing flow of a priority setting module.
[Fig. 19]
It is a figure which shows the processing flow of the lock acquisition module in the priority inheritance method.
[Fig. 20]
It is a figure which shows the processing flow of the lock release module in the priority inheritance method.
[Fig. 21]
It is a figure which shows in detail the internal structure of an interrupt mask level calculation module.
[Fig. 22]
It is a figure which shows the processing flow of the interrupt mask level calculation module.
[Fig. 23]
It is a figure which shows the system configuration in the 2nd Example of this invention.
[Fig. 24]
It is a figure which shows the processing flow of a priority monitoring module.
[Fig. 25]
It is a figure which shows the processing flow of the common interrupt handler which starts a priority monitoring module.
[Fig. 26]
It is a figure which shows the system configuration in the 3rd Example of this invention.
[Fig. 27]
It is a figure which shows the example of task distribution among operating systems.
[Fig. 28]
It is a figure which showed another structure of a common interrupt handler.
[Fig. 29]
It is a figure which shows the system configuration in the 4th Example of this invention.
[Explanation of symbols]
100 ... processor, 101 ... memory, 102 ... I / O controller, 103 ... processor bus, 104 ... disk device, 105 ... display, 106 ... real-time control network, 107 ... interrupt signal line, 108 ... timer device, 110 ... paperwork OS, 111 ... real-time OS, 112 ~ 117,370 ~ 373 ... task, 118 ... operating system switching program, 120,121. .. Priority Notification Module, 122,123 ... Priority Conversion Module, 124 ... Priority Comparison Module, 130 ... CPU, 131 ... Cache Memory, 132 ... General Purpose Register, 133 ... Program Counter, 134 ... status register, 135 ... interrupt controller, 136 ... data bus, 137 ... address bus, 138 ... interrupt status signal, 140 ... interrupt block bit, 141 ... Interrupt mask level field, 142 ... execution state register, 143 ... interrupt mask register, 144 ~ 147 ... interrupt mask bits, 150,151 ... executable queue, 152,153 ... interrupt handler, 154,155 .. .Rescheduler, 156,157 ... system call program, 160 ~ 165 ... task management table, 170,171 ... priority conversion table, 172 ... paperwork OS normalization priority, 173 ... real-time OS normal Priority, 174 ... common interrupt handler, 175 ... inter-OS communication function module, 176 ... OS context switching module, 177 ... interrupt mask level calculation module, 210 ... execution OS storage variable, 211 ... interrupt-enabled table, 212 ... paperwork OS storage context, 213 ... real-time OS storage context, 214,215 ... interrupt stack, 216,217 ... interrupt stack pointer, 218 ... shared memory , 219 ...Lock acquisition module, 220 ... Lock release module, 280,281 ... Priority setting module, 282,283 ... Priority reverse conversion table, 320 ... Interrupt mask conversion table, 340,341 ... Execution priority, 342. .. Paperwork OS execution priority storage value, 343 ... Real-time OS execution priority storage value, 344 ... Priority monitoring module, 380 ... Interrupt priority correspondence table.
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| US8707317B2 | Cited by | United States of America | Applicant |
| CN102047225A | Cited by | China | Search report |
| US8468533B2 | Cited by | United States of America | Applicant |
| JP2005327269A | Cited by | Japan | Search report |
| WO2011148563A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| KR20170118182A | Cited by | Republic of Korea | Search report |
| JP2009181578A | Cited by | Japan | Examiner |
| JP2006012122A | Cited by | Japan | Search report |
| WO2009157178A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| JP2017507417A | Cited by | Japan | Search report |
| KR20170118182A | Cited by | Republic of Korea | Examiner |
| JP5770721B2 | Cited by | Japan | Examiner |
| US8271976B2 | Cited by | United States of America | Applicant |
| US7844446B2 | Cited by | United States of America | Applicant |
| US9830178B2 | Cited by | United States of America | Applicant |
| WO2013132648A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US7707576B2 | Cited by | United States of America | Applicant |
| US9460270B2 | Cited by | United States of America | Applicant |
| JP5405320B2 | Cited by | Japan | Search report |
| JP2019125242A | Cited by | Japan | Search report |
| US8489862B2 | Cited by | United States of America | Applicant |
| JP2017507417A | Cited by | Japan | Search report |
| JP5323828B2 | Cited by | Japan | Search report |
| US7496494B2 | Cited by | United States of America | Applicant |
| WO2009133669A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US8782639B2 | Cited by | United States of America | Applicant |
| US10628171B2 | Cited by | United States of America | Applicant |
| JP2016129047A | Cited by | Japan | Search report |
| JP2015195053A | Cited by | Japan | Search report |
| KR20190035971A | Cited by | Republic of Korea | Search report |
| US8504752B2 | Cited by | United States of America | Applicant |
| JP2006018813A | Cited by | Japan | Examiner |
| JP2009175971A | Cited by | Japan | Search report |
| JP2012185541A | Cited by | Japan | Examiner |
| CN102473118A | Cited by | China | Search report |
| JP2004514987A | Cited by | Japan | Search report |
| US9063868B2 | Cited by | United States of America | Applicant |
| JP2017507417A | Cited by | Japan | Search report |
| JP5770721B2 | Cited by | Japan | Search report |
| US8719834B2 | Cited by | United States of America | Applicant |
| US8347296B2 | Cited by | United States of America | Applicant |
| US11321098B2 | Cited by | United States of America | Applicant |
| WO2009147802A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| JP2017507417A | Cited by | Japan | Search report |
| JPWO2013132648A1 | Cited by | Japan | Examiner |
| US9218287B2 | Cited by | United States of America | Applicant |
| WO9812635A1 | Cites | World Intellectual Property Organization (WIPO) | Search report |
| JPH04367037A | Cites | Japan | Search report |
| JPH05108380A | Cites | Japan | Search report |
| JPH07282013A | Cites | Japan | Search report |
| JPH1055284A | Cites | Japan | Search report |
14 members in 8 offices
Priority claims2
| Document | Office | Kind | Date |
|---|---|---|---|
| 4103299 | Japan | A | |
| JP19990041032 | – | – | – |
Members14
| Document | Office | Kind | |
|---|---|---|---|
| CN1264078A | China | A | |
| EP1031924A2 | European Patent Office (EPO) | A2 | |
| JP2000242512AThis record | Japan | A | |
| KR20000076691A | Republic of Korea | A | |
| TW490638B | Taiwan Province of China | B | |
| EP1031924A3 | European Patent Office (EPO) | A3 | |
| US2005149933A1 | United States of America | A1 | |
| KR100759280B1 | Republic of Korea | B1 | |
| JP4072271B2 | Japan | B2 | |
| EP1031924B1 | European Patent Office (EPO) | B1 | |
| AT444523T | Austria | T | |
| ATE444523T1 | Austria | T1 | |
| DE60043032D1 | Germany | D1 | |
| US7810096B2 | United States of America | B2 |
14 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Cancellation because of no payment of annual feesLAPS | LAPS | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of change of attorneyJAPANESE INTERMEDIATE CODE: A7421RD01 | RD01 | |
| Re-examination (zenchi) completed and case transferred to appeal boardAppealJAPANESE INTERMEDIATE CODE: A912A912 | A912 | |
| Transfer to examiner for re-examination before appeal (zenchi)AppealJAPANESE INTERMEDIATE CODE: A911A911 | A911 | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Decision of refusalJAPANESE INTERMEDIATE CODE: A02A02 | A02 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 |
Numbers
- Publication
- 2000-242512
- Publication, DOCDB
- 2000242512
- Publication, EPODOC
- JP2000242512
- Application
- 11041032
- Application, DOCDB
- 4103299
- Application, EPODOC
- JP19990041032
Titles3
- English
- [Title of Invention] A computer that executes a plurality of operating systems.
- English
- The computer which performs two or more operating systems
- Japanese
- 【発明の名称】複数のオペレーティングシステムを実行する計算機
Classification
- CPC, 2
- G06F9/4843
- G06F9/45533
- IPC, 3
- G06F9 46
- G06F9 455
- G06F9 48