WO1996031824A1

WO1996031824A1 - Operating system

Info

Publication number: WO1996031824A1
Application number: PCT/JP1995/000690
Authority: WO
Inventors: Tadashi Kamiwaki; Kunihiko Tsunedomi; Takanori Yokoyama; Kenichi Kurosawa; Tomoaki Nakamura; Ryoukichi Yoshizawa
Original assignee: Hitachi, Ltd.
Priority date: 1995-04-07
Filing date: 1995-04-07
Publication date: 1996-10-10

Abstract

An operating system in which real time processing is achieved using a microkernel to perform some of system functions as processes. Although device drivers, file systems, network processings, etc., are included in a kernel program in the prior art, a server program (251) treats them as ordinary processes. This server program is registered to a port (281) as a queue of messages. When the process of a user program (211) transmits the message, priority of the process registered to the port is set to that of the process transmitted.

Description

Specification

Operating System Technical Field

The present invention relates to an operating system suitable for performing real-time processing in a system in which a part of the function of the operating system is realized as a server process using a microphone-kernel technology.

Since the conventional さが S includes all processes such as memory management, process management, device driver, file system management, and communication processing in the kernel program executed in the system mode, its size is large. It was getting very big. This has been a major problem in terms of debugging and maintaining kernel programs. In addition, inside the kernel program, there are many parts called critical sections that cannot be switched. If a low-priority process is executing this part, it cannot run even if a high-priority process occurs. Therefore, force

—The channel program is large. S will inevitably reduce real-time performance.

In recent years, attention has been focused on technologies that leave only process management, inter-process communication, and exception processing in kernel programs, and implement device drivers, file systems, network processing, and other processing that were previously in kernel programs using ordinary processes. Have been. This OS is called the micro kernel ss, the remaining small kernel is called the micro kernel, and the process that implements the external functions is called the server process. Also, all conventional functions are powerful —The S inside the flannel program is called monolith 0 S. With the microphone mouth kernel 〇s, the functions realized in the server process can be debugged by the same method as the user's process, so that the development efficiency of 〇S can be improved. In addition, because the force channel itself has become smaller, the critical section is also smaller, improving real-time responsiveness. The microkernel II S is described in “Distributed Operating System J Mamoru Maekawa et al., Kyoritsu Shuppan Co., Ltd.'s P20-P24. This microkernel II S was modified for real-time processing. For details, see "Real—Time Mach: Towards a Predicate table Real—Time System" by H. Tokuda, T. Nakajima, and P. Rao, from Proc. Usenix Mach Workshop, October 1990, pp. 1 One 1 (This is a statement.

In a monolithic OS, when a user process wants to use the 〇S function, it issued a system call that provides that function. On the other hand, in 機能 S of the microkernel, most of the functions are realized in the server process, so only limited functions such as process creation and inter-process communication are provided as system calls. Therefore, when using the other functions, the user process sends a message requesting the server process to provide the functions using the system call of inter-process communication. The server process performs the requested processing, and if necessary, returns the result to the user process again using inter-process communication. In the past, operating systems (hereinafter abbreviated as OS) have been giving priorities to processes that are the unit of execution. This is to ensure that the execution of important and urgent operations is not alienated by the execution of insignificant operations. In particular, in a real-time system that must return results within a certain time limit for external events, this priority control Plays an important role. In the microkernel II S, the priority can be set for both the user process and the server process.

However, the problems of monolithic OS, as described above, are that it is difficult to obtain real-time performance of in-kernel processing, and that debugging and maintenance are difficult. The MicroKernel 〇s solves these problems. However, in the conventional microkernel OS, the parts of the message communication and the server process were not sufficiently realized in real time.

In addition, in the microkernel S, when a user process requests processing from the system, the request is communicated to the server process by message communication performed by the kernel. In the conventional microkernel, since the message communication mechanism in the kernel is not real-time, a request sent by a high-priority user process is sent to a message queue by a low-priority user process. Accordingly, an object of the present invention is to automatically control the priority of message communication in which a user process issues a request to a server process.

Also, with the conventional microkernel 〇S, it is possible to load a priority on the server process, but this priority is fixed without being changed by a request from the user process. Therefore, there is a problem that a request from a low-priority user process and a request from a high-priority user process are processed by a server process of the same priority. Another object of the present invention is to provide means for automatically changing the priority of a server process according to the priority of a request from a user process.

If the server process is a device driver, requests for devices in the server process may form a queue. This wait As for the matrix, since priorities were not taken into account in the conventional 、 S, a request with a high priority was sometimes waited.

Therefore, an object of the present invention is to provide means for controlling the priority of an IZO request queue of a server process which is a device driver. Disclosure of the invention

To automatically control the priority of message communication from the user process to the server process, the microkernel adds the priority of the user process that sent the message to the message. If messages need to be enqueued in the message queue, arrange the messages in priority order with the microchannel.

Also, in order to automatically change the priority of the server process according to the priority of the request from the user process, when the server process receives the request message, it inherits the priority added to the message. It was to so.

In order to control the priority of the I0 request queue of the server process, which is a device driver, the IZO request queue is rearranged according to the priority added to the request message.

The user process can use the functions of the micropower cell by executing the trap instruction. The message communication function of the microkernel is also started by executing the trap instruction. When the microkernel is requested to send a message, the microkernel checks the priority of the requested process from the process management table, writes it to the message management table, and then writes the message. —Insert the management table into the message queue. At this time, the queues are inserted so that the order of the queues is in descending order of priority. The server process also requests the microkernel by using a trap command to retrieve a message from the message queue. At this time, the microkernel takes out the top message management table from the message queue and passes it to the server process, while writing the priority added to the message into the server process's process management table. When the server process receives the message, it also reads the priority information attached to the message. If the server process is a device driver, this priority information is used to control the IZ〇 queue. BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is an example of a real-time system provided by the present invention. FIG. 2 is an example of the register 101 of the processor in FIG. FIG. 3 shows an example of the algorithm of the user process in FIG. 1, and FIG. 4 shows an example of the algorithm of the write program which is one of the system call shared libraries 23 in FIG. . FIG. 5 shows an example of the algorithm of the message transmission program send_msg in FIG.

FIG. 6 shows an example of the trap handler algorithm which is a part of the microkernel 27 in FIG. 1, and FIG. 7 shows the inside of the microkernel which is a part of the microkernel 27 in FIG. An example of the algorithm for send_msg processing is shown.

FIG. 8 shows an example of an algorithm of a file server parent program which is a part of the file server 24 of FIG. 1, and FIG. 9 shows a file of FIG. An example of the algorithm of the file server child program which is a part of the file server 24 is shown.

FIG. 10 shows an example of an algorithm of the rcv_msg function for requesting the microphone port kernel to receive the message shown in FIG.

FIG. 11 shows an example of an algorithm for rev-msg processing in a micro force unit which is a part of the microkernel 27 of FIG.

FIG. 12 shows an example of an algorithm of a device driver server acceptance program which is a part of the device driver 25 of FIG. 1, and FIG. 13 shows an insertion of a write request which is a part of the device driver 25. FIG. 14 shows an example of an algorithm of a program for inserting a read request which is a part of the device driver 25. FIG. 15 shows an example of an algorithm of the program of the device driver 2 shown in FIG. 5 shows an example of an algorithm of an output program which is a part of FIG.

FIG. 16 shows an example of the library file system structure used in the algorithm of FIG. 4, and FIG. 17 shows an example of the library message structure used in the algorithm of FIG. Is shown.

FIG. 18 shows the configuration of the system call table 62 of FIG.

FIG. 19 shows an example of the structure of a message structure for a micro force kernel used by the micro kernel 27 of FIG. 1. FIG. 20 shows the structure of the micro kernel 27 of FIG. This is the structure of the port to which this message is connected.

FIG. 21 shows the configuration of the trap vector table 65 of FIG. FIG. 22 shows the configuration of the process management table 291, which is included in the microphone opening kernel 27 shown in FIG. FIG. 23 shows an example of the configuration of the IZO request structure 2551 in the device driver 25 of FIG. BEST MODE FOR CARRYING OUT THE INVENTION

Hereinafter, the present invention will be described in more detail with reference to the drawings.

FIG. 1 is an example of a real-time system provided by the present invention. In the embodiment described here, 1 is a real-time system. 10 is a processor, 101 is a register, and 102 is a computing unit. The processor is connected to 13 memories and 11 I-nodes via 12 buses. There is a program counter in the register of 101, and the processor reads the instruction from the address in the memory indicated by the program counter, and executes the instruction in the arithmetic unit of 102. The data required for the operation is taken from the 101 register and the 13 memory. The result of the operation is also stored in a register or memory. Various programs and data are stored in the memory 13. They can be broadly divided into four parts. The first is 21 to 22 user programs. These are arbitrary programs and data written by the user. The second is a few system call shared libraries. This is a library of functions that the user program calls when requesting processing from the system. The third is a 27 microphone mouth kernel. This is the operating system program and its data that are executed in system mode. Finally, there are 24 to 26 server programs. These are part of the operating system processing, but are not required to be executed in the system mode, and are executed in the user mode. Among the user programs of 2 1, the user programs of 2 1 1 and 2 1 2 Data and the stack used by 2 13 user programs.

The system call shared library of 23 has various system call call functions 231-234. In the microkernel 27, 2 7 1 and 2 7 2 are an in-kernel message sending program and an in-kernel message receiving program, respectively. Using these programs, user programs and server programs send messages to each other. Reference numerals 282 to 282 denote queues for incoming messages called ports. 341 to 346 are message structures for managing messages. 291-1 to 2995 are process management tables for managing processes. A process is a unit of execution in an operating system that performs multiple processes in a time-sharing manner. In these process management tables, there is an area for saving the value of register 101 of processor 10 and the values of the registers in these tables can be loaded and restored in the processor registers. Thus, multiple processes can be executed in a time-sharing manner. Reference numeral 31 denotes an execution queue, and the processes managed by the process management tables 292 to 294 in the queue are waiting to be executed by the port processor. 32 is a block queue, and the processes in this queue are waiting for something to happen, such as waiting for the end of 1 node. If the waiting event occurs, the process is moved to the 31 execution queue. The process managed by the process management table of 291 is currently running. Each process management table has an area for storing the priority. In the 291 process management table, 291 1 is the priority. When scheduling occurs, the process with the highest priority among the running process and the process in the execution queue is executed. 274 is the scheduling program that does this. 273 is a trap processing program that is called when a program executes a trap instruction. 33 3 is a trap vector table that indicates the destination to which a trap instruction is to be executed when executed. The 1 11 11 11 11 マン 1 command register and the 1 12 データ data register. To output data to the outside, write the data to the 112 data register, and then write the output command to the 111 command register. Next, with reference to FIG. 1, the operation when a process executing a user program executes a system call will be described. It is assumed that the process is executing the user program code of 211 and executes a system call for writing to I0 in this process. The program of 211 first calls a subroutine of the writte program of 23.1 which requests a write to I / O from the system shared library of 23. When a process executing a user program requests processing from a process executing a server program, send a message to that process. Therefore, the writte program 2321 calls the subroutine 232 message transmission program that performs the process of transmitting the message. The message sending program shifts to the system mode by executing the trap instruction, and shifts the processing to the in-kernel message sending program 271, in the microkernel. The in-kernel message communication program 27 1 allocates a message structure 34 1. This structure has a place to store the priority, and writes the priority in the process management table 291 of the running process to it. Then, the message structure is inserted into the queue of port 281, but at this time, the queue is inserted so that the order of the queue is arranged in the priority order of the message structure. Now, the process management table of 29 1 The processing of WRITE of the managed process is the end, the program returns in order from 271, 2332, 231, the user program code of 211 ends, and the process ends. . At this point, the scheduling program 274 is executed to determine the next process to be executed. The process of executing the server program should have a higher priority set in advance. Then, the process of executing the server program is executed next. The process management table of this process is 292, and this table is removed from the execution queue 31 and is positioned as a running process. This process executes the file server parent program 24 1 in the file server 24. This program calls the message receiving program 2 4 4 1 as a subroutine. The message receiving program 2441 calls the in-kernel message receiving program 272 in the microkernel 27 by a trap instruction. The program of 272 takes in the message from the beginning of the port of 281. At this time, the priorities in the process management table of the process executing the priorities in the message structure 34 1 are copied to the area. As a result, the server program is executed with the same priority as the process of the user program that requested the processing. Similarly, the file server program requests the device driver 26 program for processing by message communication. The operation of this part will be described later.

FIG. 2 is an example of the register 101 of the processor in FIG. In the embodiment described here, 101 is the entire register, 1101 is the program counter that points to the address of the location in the program that is being executed, and 11012, 1011, 21 1 0 1 2 1 2, 1 0 1 2 1 3, 1 0 1 2 1 4 1 0 1 2 1 5 are general-purpose registers. FIG. 3 shows an example of the algorithm of the user program 211 in FIG. Since this program is written by the user, any program can be used. Here, a program that requests the operating system to write to a file will be described as an example. The data to be written is prepared in 4 11, and the function to request the writing is called in 4 12. The first argument of the write function in 4 1 and 2 is an identifier indicating the file to be written, and the second argument is the address of the buffer containing the data to be written.

FIG. 4 shows an example of an algorithm of a wri te program 2 31 which is one of the system call shared libraries 23 of FIG. Calling the write function at 4 1 2 in Figure 3 will execute this function. In 421, the command member of the file system structure contains an instruction of WRITE to indicate writing. In 422 and 432, respectively, the file identifier and buffer address passed in the argument are put in the file identifier member and buffer member in the file system structure.

In 424, in order to send a file system structure as a message, a file structure is included in the data member of the message structure. In 4 25, a function is called to request the microkernel to send a message. The first argument of the function is the port identifier of the message destination, the second argument is the address of the message structure, and the third argument indicates whether the message inherits the priority of the process. In this example, the third argument is 1, so the message's own priority is inherited by the message. By calling the message transmission program of 425, the function of 232 in FIGS. 1 and 5 is executed.

Fig. 5 shows the message transmission protocol of 2 32 and 2 4 3 1 to 2 4 3 2 in Fig. 1. 4 shows an example of a program algorithm. Since the main processing of message transmission is performed by the microkernel shown in Fig. 27, this function shifts the processing to the remote microphone kernel by a trap instruction. In 431, 3 is loaded into the register of GR0. This is an identifier that indicates what processing is requested when requesting processing from the microkernel. A value of 3 indicates that the request for message transmission (k-msg-send), which is the third in the system call table 62 in FIGS. 1 and 18, is being made. In 4 32, the trap instruction is executed and the processing is transferred to the kernel. Operand 2 of the trap instruction instructs to jump to the second address of the trap vector table in FIGS. 1 and 19 after executing the trap instruction. The second in the trap vector table in FIG. 19 is the address of the syscal l function, which jumps to the trap handler (syscal l) in FIG. 1 and FIG.

FIG. 6 shows an example of the trap handler algorithm of 273 which is a part of the microkernel 27 of FIG. This function is called when the user program and the server program issue a trap instruction. In 4 41, the system call table shown in Fig. 18 is searched according to the value of register GR0. Before a trap instruction is executed by a user program or the like to request processing from the microkernel, a number indicating what processing is requested is entered in GR0. This value is used for the search. In 442, the arguments on the user stack are copied to the kernel stack. When the user program calls a function to request processing from the microkernel, its argument is pushed onto the user stack 21 of the user program 21 in FIG. For the microphone mouth kernel to use this argument, the 30 You need to copy the arguments to the kernel stack. In 443, the function obtained by searching the system call table is called. When the trap instruction is executed in the example shown in FIG. 10, the send_msg process (k_send_msg) 2 71 in the micro-core in FIG. 1 and FIG. 7 is executed. In 4 4 4, since the function call of 4 4 3 may have caused a change in the priority of the executable process, re-scheduling was performed and the process with the highest priority at that time was executed. Switch.

FIG. 7 shows an example of an algorithm of the send_msg processing in the microphone kernel 271, which is a part of the microkernel 27 in FIG. The 451 allocates a message structure used to manage messages in the kernel. In 452, the address of the data contained in the message structure passed as an argument is relocated to the newly allocated message structure. In 453, the value of the third argument indicating whether to inherit the priority of the own process to the message is checked. If this value is 0 and it is not inherited, the message structure kmsg is inserted at the end of the queue of the port specified by the first argument (281, etc. in Fig. 1), and this function ends. If the value of the third argument i nh is 1 and the priority is to be inherited, go to 4 54. In 454, p is the address of the process management table of the running process. In FIG. 1, it is the address of the process management table 291. In 455, the value of the member pri indicating the priority in the process management table p of the running process is assigned to the member -pri indicating the priority in the message structure. Steps 456 to 549 are processing for inserting the message structure kmsg into an appropriate place so that the queues of the ports are in priority order. In 456, the message structure in the port queue is searched from the beginning. In 4 5 7, the priority of the retrieved message structure m is It determines whether the message structure to be inserted is smaller than that of kmsg or whether there is no more message. If not, retrieve the next message structure at 458. If so, insert kmsg before m at 459. In steps 460 to 462, when a process for receiving a message is registered in a port, the priority of the process is changed by the arrival of the message. At 460, it checks to see if kmsg has been inserted at the beginning of the queue. If it is not the head, the process ends because there is no need to change the priority of the receiving process. In the first case, go to 4 6 1. In 461, it is checked whether the receiving process is registered in the port. If not registered, the process ends. If registered, the process proceeds to 462. In 462, the priority of the process registered as the receiving process is changed to kmsg priority.

FIG. 8 shows an example of an algorithm of a file server parent program 241, which is a part of the file server 24 of FIG. This program mainly accepts a request message from a user program. The actual process creates a new process and causes it to be performed. In 471, the priority of the own process is set as high as 180. Since the file server parent program terminates its processing immediately, it does not register itself as a receiving process on the port, but sets itself to a higher priority, so that the own process is immediately scheduled when the message arrives. I'm trying to be Euling. In 472, a function that requests the microkernel to receive a message is called. This function is 244 1 in FIGS. 1 and 10. The first argument of this function is the port identifier for receiving the message, the second argument is the received message, and the third argument is whether the process inherits the priority added to the message by receiving the message. Represents The fourth argument returns the priority of the received message. In this example, since the third argument is 1, receiving the message changes the priority of the own process. In 473, a child process is generated, and the file server child program 2442 in FIGS. 1 and 9 is executed using the received message as an argument. The priority of the parent process is inherited by the created child process. The parent process that created the child process returns to the beginning of processing and receives the next message.

FIG. 9 shows an example of an algorithm of a file server child program 24, which is a part of the file server 24 of FIG. This program processes requests from the user program to the file server. In 481, the file identifier is extracted from the content of the message received as an argument. In 482, the device to access, the block number, and the offset in the block are calculated from the file identifier. In 483, various information obtained in 482 is put in a structure to send a message to the driver of the target device. 4 8 4 sends a message to the device driver. In this send_msg call, 2431 in FIG. 1 is executed, but the contents are the same as 2332 in FIG. 1, and the algorithm was also explained in FIG.

Fig. 10 shows an example of the algorithm of a function that requests the microphone mouth kernel to receive the messages of 2 3 3 and 2 4 4 1 to 2 4 4 2 in Fig. 1 <4 91 and assigns 4 to GR0. Except for this, it is the same as the function for requesting message transmission in Fig. 5. By inserting 4 into GR0, k—rcv_nisg is retrieved from the system call table in FIG. 18 at 4 41 in FIG.

FIG. 11 shows an example of an algorithm of rev msg processing in the microkernel 27 2 which is a part of the microkernel 27 in FIG. Seki The first argument is the port to receive the message, the second argument is the address to which the received message is returned, the third argument is a flag indicating whether the process inherits the priority of the message, and the fourth argument is The priority attached to the message is returned. At 501, it checks if the port is empty. If it is empty, it blocks at 508 until the message arrives. When a process blocks, it connects its process management table to the block queue 32 in FIG. 1 and switches to another process. If it is not empty at 501, the message structure at the beginning of the port is retrieved at 502. This is kmsg. At 503, the data held by kmsg is inserted into the data of the message structure of the second argument. At 504, a flag is checked to determine whether the message priority is inherited as the priority of the own process. If not, the process ends. When inheriting, the process management table of the running process is checked at 505, and the priority of the message is assigned to a member of the priority of the process management table at 506. In 507, processing is performed to return the priority to the fourth argument.

FIG. 12 shows an example of an algorithm of the device driver server reception program 251, which is a part of the device driver 25 in FIG. 1.The process executing this program is shown in 511. Is registered in the dev_port port as a receiving process. The registration is performed by writing the identifier of the own process in the area of the port structure 642 in FIG. With this registration, the priority of the receiving process is set to the same as that of the message when the message is sent, without waiting for the message to be received as described in 4 62 in Fig. 7. It is possible to In 5 12 we read a function that asks the microkernel to receive a message. The algorithm for this function has already been described in FIG. 5 1 3 The block number, offset, and priority are extracted from the message and put into the I / II request structure. In 514, I 〇 seeks the end of the request queue. At 5 15, it is determined whether the I request is write or read. In the case of writing, the function that inserts a write request into the I @ request queue is read at 516. In the case of reading, a function to insert a read request is called in 517.

FIG. 13 shows an example of an algorithm of a program for inserting a write request which is a part of the device driver 25 of FIG. However, this program is omitted in Fig. 1. This program searches the I / O request queue from the back and inserts the request to be inserted at an appropriate place according to its priority. However, if a request to access the same block as the request to be inserted is in the queue during the search process, the priority of the request is set to the same as the priority of the request to be inserted, and Rearrange the. This is because if the order of access to the same block is changed, the result will be inconsistent. This function takes two arguments, the first is the request to insert, and the second is where to start the search. The second argument is initially given the address of the last request in the queue. In 521, it is checked whether the search point is at the head of the queue. If so, insert the request at the beginning of the queue at 529 and end. If not, the priority of the request for the search point is compared with the priority of the request to be inserted in 522. If the search request has a higher priority, the request is inserted at 529 after the search request. If not, it checks in step 523 whether the request for the search point and the request to insert are accesses to the same block. If the access is not for the same block, the search point is returned to the previous request at 524 and the process returns to the beginning. If the blocks were the same, 5 2 5 —First, the request for the search point is also removed from the queue. In 526, the priority of the removed request is the same as the priority of the request to be inserted. In 527, when the removed request entered the queue, the previous request was PPed. In 528, my function is called recursively to re-insert the removed request into the queue. After the dropped request is inserted, the request that was originally inserted in step 529 is inserted after the request that was once removed and reinserted.

FIG. 14 shows an example of an algorithm of a program for inserting a read request which is a part of the device driver 25 of FIG. However, this program is omitted in Fig. 1. The algorithm of this program is almost the same as the algorithm of the program for inserting a write request in Fig. 13. However, the order of read requests can be changed even for accesses to the same block.Therefore, in step 533, the block numbers are compared and the fact that the search point request is a write request is checked. The point that I am investigating is different.

FIG. 15 shows an example of an algorithm of an output program 252 which is a part of the depth driver 25 of FIG. This program retrieves requests in order from the beginning of the request queue, I Z 〇, and issues requests to I 0. At 5 1 it checks if the I 0 request queue is empty. If it is empty, block at 5 4 2 until a request comes. Otherwise, the first request is retrieved at 543, and the data and command registers of IZ と are written at 544 and 545 according to the request. In 5 4 6, it blocks from the requested I / 〇 to the end interrupt.

FIG. 16 shows an example of a library file system structure used in the algorithm of FIG. 6 0 is the whole structure, 6 0 1 Is the member that contains the command, 602 is the member that contains the file identifier, and 603 is the member that contains the address of the buffer that contains the data to be written.

FIG. 17 is an example of a message structure for a library used in the algorithm of FIG. The structure 61 has an area 611 for storing data to be transmitted as a message.

FIG. 18 shows the configuration of the system call table 62 of FIG. This system call table is used in the algorithm of FIG. 6 2 is the whole table, and 6 2 1 to 624 are the addresses of the functions. These functions are searched according to the value of register GR0 at 4441 in Fig. 6 and jumped to there at 4443. 6 2 1 1 to 6 2 4 1 is the number of arguments that require 6 2 1 to 6 2 4 respectively. Using this number, copy the argument in 4 4 2 in Figure 6.

FIG. 19 is an example of the configuration of the message structure 341-1 to 3446 used by the microchannel 27 of FIG. 6 3 is the whole structure, 6 3 1 is the member that contains the address of the data to be sent, 6 3 2 is the member that contains the priority of the message, 6 3 3 and 6 3 4 are the Forward and backward links to connect the structure to the port queue. FIG. 20 shows a structure of ports 281-282 to which messages in the microkernel 27 of FIG. 1 are connected. Reference numeral 64 denotes an entire port structure, 641 denotes a pointer for connecting a message, and 642 denotes an area for storing a process identifier for registering a process to be received.

FIG. 21 shows the configuration of the trap vector table 65 of FIG. This trap vector table determines to which address to jump to when the trap instruction is executed at 43 in FIG. Second area 652 contains the trap handler syscal l address shown in Fig. 6, and when the instruction of trap 2 is executed, it jumps to that address.

FIG. 22 shows the configuration of the process management table 291 in the microphone opening kernel 27 of FIG. The structure of the process management tables 292-295 is the same as this. 661 is a member that stores the priority of the process, 662 is a member that saves the value of the program counter among the registers of the process, 663 and 63634 are members that save the general-purpose registers, and 6635 and 6635 6 6 3 6 are backward and forward links for connecting the process management table to the execution queue and the block queue.

FIG. 23 shows an example of the configuration of the I / O request structure 2551 in the device driver 25 of FIG. 6 7 1 is the priority, 6 7 2 is the block number to perform 1 〇, 6 7 3 is the offset within the block, 6 74 and 6 7 5 are the links for connecting to the 1 0 request queue. is there. Industrial applicability

As described above, the operating system in which a part of the function of the operating system is realized as a server process using the microkernel according to the present invention is suitable for use in a computer system that requires real-time processing. I have. Furthermore, it is suitable for controlling controllers that require high real-time performance.

Claims

1. It has a communication means for managing a plurality of processes, each of which has a priority, and giving priority to the process that is executable and having the highest priority, and communicating between the plurality of processes. The I〇 control program is implemented as a process outside the kernel, and when other processes perform I / O input / output processing, a message is sent to the I〇 control program process using the communication means. In the operating system, an area for storing a process identifier of the I / O control program, which is a message receiver, is provided in the communication means, and a process, which is a message sender, transmits the message. Means for changing the priority of the process of the IZ〇 control program, which is the recipient, according to the priority of the process of the sender. Operating system to.

2. It manages a plurality of processes, each of which has a priority. Among these processes, it has a communication means for giving priority to the executable and having the highest priority and communicating between the plurality of processes. The IZO control program is implemented as a process outside the kernel, and when other processes perform input / output processing to one node, a message is transmitted to the process of the I〇 control program using the communication means. In the operating system, when the process of the I-control program, which is the recipient of the message, receives the message, the priority is determined by the priority of the process, which is the sender of the message. An operating system comprising means for changing a priority of a process of the I0 control program which is a message receiver.

3. Manage a plurality of processes, each of which has a priority, and execute the process which has the highest priority and which is executable, with priority. The I0 control program is implemented as a process outside the kernel, and when other processes perform input / output processing to 1〇, the communication means is used to communicate with the IZ〇. In an operating system for transmitting a message to a process of a control program, an area for storing a priority is provided in a message management table for managing a message of the communication means, and when a process of a sender transmits a message, The priority of an area for storing the priority is set according to the priority of the process of the sender, and the priority is stored when the message management table is connected to a reception queue for managing the processing order of received messages. Operating means provided with means for connecting in an order according to the value of the region to be connected.

4. Communication means for managing a plurality of processes, each of which has a priority, executing the highest-priority executable process with priority, and communicating messages between the plurality of processes. In the operating system having the following, an area for storing an identifier of a process of a message receiver is provided in the communication means, and a process of a sender of the message is performed when a process of the sender of the communication transmits a message. An operating system for changing the priority of a process of a receiver of the message according to the priority of the operating system.

5. Communication means for managing a plurality of processes, each of which has a priority, executing the process which is executable and having the highest priority, and transmitting a message between the plurality of processes. An operating system comprising: an operating system having means for changing the priority of a receiver process according to the priority of a sender process when the receiver process receives a message.

6. Communication means for managing a plurality of processes, each of which has a priority, executing the highest-priority executable process among the processes with priority, and communicating a message between the plurality of processes. In an operating system having a function, an area for storing a priority is provided in a message management table for managing messages of the communication means, and when a message sender process sends a message, the sender of the message transmits the message. The priority of the area for storing the priority is set according to the priority of the process, and when the message management table is connected to the reception queue, the connection is performed according to the value of the area for storing the priority. Operating system _t provided with means

7. The operating system according to Claims 1, 2, 4 and 5 in which the process of reflecting the priority of the sender's process to the priority of the receiving process is used. An operating system, characterized in that the operating system is provided with means for preventing a sender's process from illegally increasing the priority of the receiver's process by a program in the kernel.

8. The operating system according to any one of claims 1 to 6, wherein the process receiving the message is provided with a means for reading out a priority newly given to the process.

9. The operating system according to claim 1 or 3, further comprising means for designating that the order of the messages is not changed when transmitting the message.

10. In Claims 1, 2, 4, and 5, when sending a message, make sure that the priority of the sender 's process is not reflected in the priority of the receiver' s process. An operating system characterized by providing means for specifying.

1 1. In claims 2 and 5, the sender of the message An operating system comprising means for designating that the priority of a process is not reflected in the priority of a recipient process.

1 2. In Claims 2 and 5, the priority of the receiving process before receiving the message shall be the priority of the sending process when the message has the priority of the process that performs normal processing. An operating system characterized by setting it to the same or lower range as the priority of processes that require higher real-time properties.

13. An operating system according to claim 8, wherein when it is necessary to queue requests even in a process of a receiver, queue management is performed according to the read priority. .

14. In claim 13, the receiver process is executing an I / N control program, and the I / I control program queues requests to be output to IZ. When the read request is assigned to the request and the queues are arranged in descending order of priority, when a new request is inserted into the queue, the same IZ portion as the new request is added. If a request that must be executed before the new request, such as for access, is already in the queue and the request has a lower priority than the new request, the request to be executed earlier An operating system comprising means for resetting the priority to the same as the priority of the new request.