JP2015038757A - Computer system, kernel scheduling system, resource allocation method, and process execution sharing method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To allocate resources in a computer system of a multi-operating system, and thereby to avoid bottlenecks and other decrease in efficiency that result from contention of limited resources.SOLUTION: A computer system 100 includes: resources; and a plurality of processors executing a plurality of operating systems 101 to 106 that provide access to the resources. The resources include: printers; disk controllers; network controllers; and other frequently-accessed resources. Each operating system includes a kernel scheduler. The plurality of kernel schedulers mutually adjust allocation of the resources to process execution on the computer system.

Description

  The present invention relates to a computer system. More particularly, the present invention relates to allocating resources to processes on a computer system running multiple operating systems.

  The resources used by a computer vary with the computing environment and are distributed among them, but the resources are needed before the job can be run. When running multiple processes simultaneously, it is normal, but bottlenecks occur in resources. These bottlenecks can occur in the I / O bus controller, the memory controller in the swap sequence, or the program is interrupted because it requires memory load when a memory dump is initiated Also occurs when (preempted).

  The occurrence of bottlenecks, and thus process starvation, is increasing even in computer systems running multiple operating systems. As the number of processes running on these operating systems increases, there is a higher probability that multiple processes will request the same resource at the same time, or that processes waiting for each other to starve will starve.

  The computer system according to the first aspect of the present invention includes a plurality of resources and a memory storing a plurality of operating systems. Each operating system includes a kernel scheduler that coordinates resource allocation for processes executing on the computer system. In one embodiment, the computer system also includes a plurality of central processing units that respectively execute different ones of the plurality of operating systems. The plurality of resources include any two or more of a keyboard controller, a video controller, an audio controller, a network controller, a disk controller, a universal serial bus controller, and a printer.

  Preferably, the plurality of kernel schedulers share the resource related information using a communication protocol. In one embodiment, the communication protocol accesses shared memory. Alternatively, the communication protocol includes inter-process communication, protocol stack, or Transmission Control Protocol / Internet Protocol (TCP / IP). Alternatively, the communication protocol includes semaphore accessing, pipes, signals, message queues, pointers to data, and file descriptors. In one embodiment, the process consists of at least three processes that communicate with each other.

  In one embodiment, each of the plurality of kernel schedulers includes a relationship manager that coordinates resource allocation. Each of the plurality of relationship managers includes a resource manager that determines resource information regarding one or more of the plurality of resources. The resource information is an estimated time until the resource becomes available.

  The computer system according to the second aspect of the present invention includes a memory storing one kernel scheduler and a plurality of operating system kernels that access a plurality of resources. The kernel scheduler assigns a process requesting one of the plurality of resources to a corresponding one of the plurality of operating system kernels. The computer system also includes a plurality of processors each executing a corresponding one of a plurality of operating system kernels.

  In one embodiment, the kernel scheduler schedules processes on multiple operating system kernels based on multiple processor loads.

  In one embodiment, the computer system also includes a process table that matches resource requests to one or more of a plurality of operating system kernels. In other embodiments, the computer system also includes a communication channel between a pair of operating system kernels. Multiple operating system kernels exchange information regarding processor load, resource availability, and estimated time to resource availability.

  The kernel scheduling system according to the third aspect of the present invention includes a plurality of processors and an assignment module. Each of the plurality of processors executes an operating system kernel that accesses one or more resources. The allocation module is programmed to match the process requesting the resource and dispatch the process to one of a plurality of operating system kernels that can access the resource. Preferably, each of the plurality of processors is controlled by a corresponding processor scheduler.

  According to a fourth aspect of the present invention, there is provided a resource allocation method for allocating resources to an operating system kernel, selecting one operating system kernel from a plurality of operating system kernels based on the ability to access the resources, and selection Assigning a process to a designated operating system kernel. All of the multiple operating system kernels are executed in a single memory.

  According to a fifth aspect of the present invention, there is provided a process execution sharing method for sharing process execution between a first operating system and a second operating system on a memory of a single computer system. Executing under the control of one operating system, and transferring control of the process to the second operating system in memory and executing the process in memory under the control of the second operating system. And have. In this way, the process is executed in memory under the control of the second operating system. Both the execution of the process under the control of the first operating system and the second operating system access a single resource. In one embodiment, a process execution sharing method includes the step of exchanging process information between a first operating system and a second operating system using one of shared memory, interprocess communication, and semaphores. Also have.

It is a conceptual diagram of a kernel operation scheduler (KOS) based on one embodiment of this invention. It is a conceptual diagram of the kernel operation | movement scheduler (KOS) based on other embodiment of this invention. It is a state transition diagram of kernel process scheduling based on one embodiment of the present invention. FIG. 2 is a diagram showing a system having an additional function of KOS design according to an embodiment of the present invention. It is a figure which shows the star core kernel structure in the system based on one embodiment of this invention. FIG. 3 is a high-level block diagram of multiple kernels communicating over a channel according to one embodiment of the present invention. FIG. 3 is a diagram illustrating a shared memory communicating between kernel schedulers, according to one embodiment of the present invention. FIG. 3 is a diagram illustrating a kernel scheduler having a filter that reserves resource processes according to an embodiment of the present invention. It is a figure which shows KOS of the star structure which allocates a some resource to a process. 6 is a flowchart based on an embodiment of the present invention showing how an embodiment of the present invention distributes operating system functionality. FIG. 2 is a diagram illustrating a kernel scheduler according to an embodiment of the present invention that informs an encoded protocol. FIG. 6 is a block diagram illustrating how processes communicate via a communication port according to an embodiment of the present invention. FIG. 6 is a diagram illustrating a table for mapping resources to an operating system according to an embodiment of the present invention. It is a figure which shows the independent kernel scheduler which exchanges resource information using a shared memory. FIG. 15A is a diagram illustrating a table indicating the state of another operating system included in each of a plurality of operating systems, and FIG. 15B is a table indicating a state of another operating system included in each of the plurality of operating systems. FIG. 15C is a diagram illustrating a table indicating the states of other operating systems included in each of the plurality of operating systems. FIG. 7 is a diagram showing resource information used and exchanged by an independent kernel scheduler according to an embodiment of the present invention. FIG. 6 is a high level diagram showing how independent kernel schedulers according to one embodiment of the present invention exchange resource information. FIG. 6 is a high-level diagram showing how resources are allocated to processes via an operating system kernel according to an embodiment of the invention. FIG. 4 is a high level block diagram of a command kernel, its relationship manager, and three resources. It is a figure which shows the process table based on one embodiment of this invention which stores a process identifier, the resource to which the process identifier was allocated, and the priority of a process. 6 is a flowchart illustrating a method for allocating resources to an operating system according to an embodiment of the present invention. 6 is a flowchart of a method for allocating processes using criteria to an operating system kernel according to an embodiment of the present invention. It is a figure which shows the sequence which allocates a process to the operating system based on one embodiment of this invention.

  Multiple operating systems that run in tandem in accordance with the present invention share resources that are allocated to processes that require resources, thereby reducing bottlenecks and other indications of resource contention. In one embodiment, resources are allocated centrally using a central kernel operating scheduler that coordinates an operating system that allocates resources to processes that require the resources. In other embodiments, the resources are provided by an operating system that coordinates the allocation of resources on a peer-to-peer basis. In this embodiment, the operating system communicates using well-established protocols.

  In the present invention, several operating systems running on a computer system are specialized to perform specific tasks. In an operating system specialized to fulfill a request for a specific resource allocation, as soon as a request for a backlogged resource is received, the overflowed request is sent to the centralized operating system (centralized It is simply queued by the resource operating system, not the Operating System).

Process management
The main task of the kernel is to allow the application to run and support the application, for example by the ability to abstract hardware. A process defines what memory portion an application can access (in this introduction, process, application and program are used as synonyms). Kernel process management must consider hardware with built-in memory protection.

  To run an application, the kernel typically prepares an address space for the application, loads a file containing the application's code into memory (often by demand paging), and prepares the program stack Then, execution of the application is started so as to branch to a predetermined position in the program.

  A multitasking kernel can give the user the illusion that more processes are running on the computer simultaneously than the maximum number of processes that the computer can physically run simultaneously. Typically, the number of processes that a computer system can run simultaneously is equal to the number of CPUs implemented (note that this is not the case if the processor supports simultaneous multithreading).

  In a preemptive multitasking system, the kernel provides time slices to all programs and switches from one process to another fast enough to make the user appear as if these processes are running simultaneously. The kernel uses a scheduling algorithm to determine which process to run next and how much time to give. The selected scheduling algorithm can give one process higher priority than other processes. The kernel also usually provides a way to communicate to these processes. This method is called inter-process communication (IPC), and the main techniques are shared memory, message passing, and remote procedure calls.

  Other computer systems (especially smaller and less powerful computers) have co-operative multitasking, where each process can switch to another process. It can work without interruption until it makes a special request to tell the kernel what is good. Such a request is called “yielding” and usually occurs in response to a request for inter-process communication or to wait for an event to occur. Both previous versions of Windows (registered trademark) and MacOS (registered trademark) used cooperative multitasking, but these were switched to a preemptive method as the performance of the target computer increased.

  The operating system may also support multi-process (Symmetric Multiprocessor (SMP) or Non-Uniform Memory Access). In this case, different programs and threads can run on different processors. The kernel of such an operating system must be designed to be re-entrant which means that the kernel can operate two different parts of its code simultaneously without problems. This usually means providing a synchronization mechanism (eg, spinlock) that ensures that no two processors attempt to change the same data at the same time.

Memory management
Operating systems typically incorporate a kernel, a group of centralized control programs that operate as the core of a computer. These control programs include a scheduler program that serves to reserve CPU time in series for the next process. The present invention uses one operating system per CPU and a plurality of operating systems operating on a plurality of CPUs. Each operating system has a dedicated kernel with a unique scheduler program called the Kernel Operational Scheduler (KOS). Every KOS has the ability to configure itself during initialization, and a system generated (sysgen) binary code copy of the operating system kernel for each CPU installed in the computer system (System generation means generation of another program by combining a specific, uniquely defined operating system, or independent software components). Once each kernel is properly prepared and connected to each CPU, KOS schedulers establish communication between each kernel and determine which kernel controls which resource.

Kernel-Wide Design Approaches
The tasks and features described above can of course be provided in a variety of ways that differ in design and implementation.

  The fundamental difference between the principle of microkernel and the principle of monolithic kernel is the principle of separation of mechanism and policy. Here, a mechanism is a support on which many different policies can be implemented, while a policy is a specific mode of operation. The minimal microkernel contains only a few very basic policies, and its mechanism allows policy (such as memory management, high-level process scheduling, file system management, etc.) The basic policy that determines which of these policies should be employed can run on top of the kernel (above the rest of the operating system and other applications). On the other hand, monolithic kernels tend to include more policies, and therefore the rest of the operating system is limited to rely on these policies. Inadequate separation of this mechanism and policy is a major cause of a lack of significant innovation in existing operating systems and a common problem in computer architecture. Monolithic kernel design is done by a kernel mode / user mode architectural approach (technically called a hierarchical protection domain construction method), which is traditionally It is common in commercial operating systems. Thus, every module that needs protection is actually in the kernel. This link between monolithic kernel design and privileged mode results in an important issue of mechanism and policy separation; in fact, the privileged mode architectural approach has a protection mechanism. Fusion with security policy, while other major architectural approaches and capability-based addressing clearly distinguish between the two and naturally, microkernel design Leads to (see Separation of protection and security).

  Monolithic kernels execute all of their code in the same address space (kernel space), while microkernels maintain the codebase by running most of their services in user space. It is intended to improve performance and modularity. Most kernels do not fit strictly in one of these classifications, and lie in the middle of these two designs. These are called hybrid kernels. More novel designs such as nanokernel and exokernel are available, but are rarely used as product operating systems. For example, the Xen hypervisor is an exokernel.

Monolithic kernel
Monolithic Kernel Diagram In a monolithic kernel, all OS services operate with the main kernel thread and therefore reside in the same memory area. This method provides rich and powerful hardware access. Some developers, such as UNIX developer Ken Thompson, argue that compared to other solutions, the operating system of a monolithic kernel is easier to design and implement. ing. The main disadvantage of monolithic kernels is the fact that dependencies between operating system components, such as bugs in device drivers, can crash the entire operating system, and large kernels are very difficult to maintain.

Microkernel
In the microkernel approach, the kernel itself has only basic functions that allow the server to execute independent programs that inherit the functions of the previous kernel, such as device drivers, GUI servers, and the like.

  The microkernel method is a simple abstraction of hardware (system calls) by a series of primitives or system calls that perform the minimum required OS services such as memory management, multitasking and interprocess communication. including the definition of abstraction). Normally, other services including services provided by the kernel, such as network services, are executed by a user space program called a server. Microkernels are easier to maintain than monolithic kernels, but they have more system calls and context switches, and such system calls and context switches are typically simple function calls ( Compared with plain function call), a larger overhead is generated, which may reduce the processing speed.

  In a microkernel, the rest of the operating system can be implemented as a normal application program written in a high-level language, and the same kernel can be used on different operating systems without modification. In addition, it is possible to dynamically switch between a plurality of operating systems and activate a plurality of operating systems simultaneously.

Monolithic vs. Microkernel As the computer kernel evolved, several problems became apparent. One of the most obvious problems is the increased memory footprint. This is mitigated to some extent by improving the virtual memory system, but not all computer architectures support virtual memory. Reducing kernel memory usage requires extensive editing and careful removal of unnecessary code, which is an interdependence between parts of the kernel with millions of lines of code It is very difficult because it is difficult to understand. Due to the problems with monolithic kernels, monolithic kernels were considered obsolete in the early 1990s. As a result, the Linux ™ design, which adopted a monolithic kernel rather than a microkernel, became the subject of a well-known discussion between Linus Torvalds and Andrew Tanenbaum. In the Tannenbaum / Torvalz debate, each opinion had its advantages. Some people, including early UNIX developer Ken Thompson, argued that microkernel design is aesthetically appealing, but monolithic kernels are easier to implement. However, bugs in the operating system of a monolithic kernel usually cause the entire operating system to crash, while this does not happen in a microkernel where the server operates separately from the main thread. Monolithic kernel advocates conclude that wrong code never enters the kernel, and that the microkernel offers little benefit from correct code. Microkernels are often used in embedded robotic or medical computers where crash tolerance is important, and most OS components have their own protected memory dedicated to them. Exists in space. This is not possible with a monolithic kernel, and not even with the latest module loading monolithic kernel.

Performance
A monolithic kernel is designed to have all of its code in the same address space (kernel space) to enhance system performance. Some developers, such as UNIX developer Ken Thompson, argue that the operating system of a monolithic kernel is very efficient if the program is written well. In the microkernel design, the interprocess communication (IPC) method, usually based on message passing, is slow and the monolithic model tends to be more efficient by using shared kernel memory instead of this IPC. .

  The performance of microkernels constructed in the 1980s and early 1990s was poor. Studies that measured some performance of specific microkernels based on experiments did not analyze the reason for such inefficiency. These performance descriptions increase the frequency of switching from kernel mode to user mode (note that such a multi-stage design of protection is not unique to microkernels) and increase the frequency of interprocess communication (note that IPC has been made a folklore with a common, unproven idea by increasing the frequency of context switches, and can run an order of magnitude faster than previously believed. In fact, the reasons for their low performance are (1) the actual inefficiencies of all the microkernel methods, and (2) the specific concepts implemented in these microkernels, as estimated in 1995. (3) because of the specific implementation of these concepts. Therefore, if there is a solution to construct an efficient microkernel, unlike previous attempts, there remains research to apply the correct construction technique.

  On the other hand, the multi-level protection domain architecture that leads to the design of the monolithic kernel has an interaction between different levels of protection (ie, the process handles the data structure in both user mode and supervisor mode). When it has to be done, it has a serious performance degradation because it needs to copy messages by importance. Most researchers have given up the idea that by carefully tuning this overhead can be dramatically reduced by the mid-1990s, but in recent years newer microkernels have been optimized to increase performance. ing.

Hybrid kernel
The hybrid kernel approach attempts to combine the speed and ease of design of a monolithic kernel with the modularity and runtime security of a microkernel.

  The hybrid kernel is essentially a compromise between the monolithic kernel approach and the microkernel operating system. This is because some services (eg network stack or file system) run in kernel space to reduce the overhead in the performance of traditional microkernels, but kernel code (eg device drivers) acts as a user space server Means to work.

Nanokernel
The nanokernel effectively delegates all services, including even the most basic services such as interrupt controllers, ie timers, to the device driver and frees up the memory required by the kernel over traditional microkernels. Is even less.

Exokernel
Exokernel is a kind of kernel that does not abstract hardware into a theoretical model. Instead of a logical model, the exokernel allocates physical hardware resources such as CPU time, memory pages and disk blocks to different programs. Programs running on the exokernel can be linked to a library operating system that simulates the well-known OS abstraction using the exokernel, or provide application specific abstractions to increase performance be able to.

Scheduling
Scheduling is a key concept in computer multitasking and multiprocess operating system design, and real-time operating system design. Scheduling is a method of assigning priority of a priority queue to a process. This allocation is performed by software known as a scheduler.

  In addition, the scheduler must ensure that processes are in time for deadlines in real-time environments, mobile devices for automated control in industry (eg, robotics). This is important for keeping the operating system stable. Scheduled tasks are sent to the mobile device and managed by an administrative back end.

Operating System Scheduler Types The operating system includes up to three different types of schedulers: a long-term scheduler (also known as an admission scheduler), an intermediate or medium-term scheduler, and a short-term scheduler (also known as a dispatcher). be able to.

  The long-term scheduler, or input scheduler, decides which jobs or processes to put in the runnable queue, that is, the long-term scheduler immediately adds it to the set of currently running processes when it tries to run the program Decide whether to add it later or later. Therefore, this long-term scheduler determines which processes run on the operating system (dictate) and also determines the degree of parallelism that is supported simultaneously, i.e., increases or decreases the number of processes running simultaneously Alternatively, it is determined how to separate a process with high I / O load (I / O intensive process) and a process with high CPU load (CPU intensive process). Typically, on a desktop computer there is no such long-term scheduler and the process is automatically granted to the operating system. However, the ability of the operating system to keep up with process deadlines is diminished by slowdown and contention caused by allowing more than the number of processes that the operating system can handle without problems. So this kind of scheduling is very important in a real-time operating system.

  The medium-term scheduler exists in all operating systems that have virtual memory and temporarily saves the process from main memory to secondary memory (for example, a disk drive) and vice versa. Return from the secondary memory to the main memory. Such processing is generally called swapping out and swapping in (although it is also inaccurate, it is also called paging out and paging in). The medium-term scheduler swaps out processes that are inactive for some time, low-priority processes, processes that frequently cause page faults, or processes that have a large amount of memory to make main memory available to other processes. Free up and later swap these processes back into main memory when more memory becomes available or when the process is unblocked and no longer waits for resources. decide.

  In many of today's operating systems (in addition to swap files, operating systems that support mapping virtual address space to auxiliary storage), the mid-term scheduler was swapped out when executing binary code By treating it as a process, it actually plays the role of a long-term scheduler. In this way, when a portion of the binary code is needed, the portion of the binary code can be swapped in on demand or lazy loaded.

  A short-term scheduler (also known as a dispatcher) then executes any of the processes in memory that are ready to run after a clock interrupt, I / O interrupt, operating system call, or other type of signal. To determine whether to allocate a CPU. Thus, the short-term scheduler makes scheduling decisions more frequently than the long-term or medium-term scheduler. Scheduling decisions need to be made at the minimum, that is, in a very short time, for each time slice. This short-term scheduler may be preemptive, meaning that the process can be forcibly removed from the CPU when the scheduler decides to allocate another process to the CPU, or the scheduler is CPU It may be non-preemptive that cannot be forced to remove the process from.

Scheduling rules (scheduling disciplines)
The scheduling rule is an algorithm used for allocating resources between parties that need resources simultaneously and asynchronously. Scheduling rules are used not only in operating systems (which share CPU time between threads and processes), but also in routers (which handle packet traffic).

  The main purpose of the scheduling algorithm is to minimize resource starvation and to ensure fairness among the parties using the resource.

Implementation of schedulers in operating systems Different computer operating systems implement different scheduling schemes. MS-DOS and Microsoft's very early Windows system were not multitasking and themselves did not require a scheduler. The Windows 3.1 based operating system uses a simple non-preemptive scheduler, and programmers yield CPU time to give CPU time to other processes (yield, free CPU) It was necessary to instruct the process to This non-preemptive scheduler originally supported multitasking, but did not have more advanced scheduling options.

  Windows NT 4.0-based operating systems use a multilevel feedback queue. Priorities in Windows NT 4.0-based operating systems are 1-31, priorities 1-15 are normal priorities, and priorities 16-31 are soft real-time priorities that require privilege assignment. It is. The user can select five priorities from these priorities from the task manager application or by the thread management API and assign them to the execution application.

  In the initial implementation of the UNIX system, a multi-stage feedback queue scheduler is used, and selection is performed in a round robin manner within each feedback queue (round robin selection). In this UNIX system, when a process is created, the process is placed in the highest priority queue (with a shorter response time for new processes, eg, processes related to a single mouse movement or keystroke), and the UNIX system. When the CPU time is consumed, it is preempted for a plurality of times, and finally put into the lowest priority queue. However, in this UNIX system, if new processes are spawned continuously, the old process can become starved of CPU time, so if the UNIX system cannot handle the new process faster than the spawn speed, Hunger cannot be avoided. In the UNIX system, the process priority could be explicitly set to one of 40 levels, but in the latest UNIX system, a higher number of priorities can be used (Solaris has 160 levels). Have priority). Unlike the Windows NT 4.0 solution to starvation of low priority processes (when a process starves, this process is brought to the top of the round robin queue), the early UNIX system uses a clever time lapse method. That is, the priority of the starving process is gradually increased until it is executed, and when the process is executed, the priority is reset to the value before the start of starvation.

  The Linux kernel used an O (1) scheduler (O (1) scheduler) until version 2.6.22, but from this version 2.6.23, it was changed to a completely fair scheduler. It has been switched.

Scheduling Algorithm In computer science, a scheduling algorithm is a method that gives threads or processes access to system resources, usually CPU time. Scheduling algorithms are typically performed to efficiently distribute the load across the system. The need for scheduling algorithms arises from most demands on modern operating systems that perform multitasking, ie, run multiple processes simultaneously. Scheduling algorithms are typically used only in a time slice multiplexing kernel. The reason for this is that in order to distribute the load efficiently on the system, the time slice multiplexed kernel must be able to force the current thread to suspend in order to start executing the next thread. Don't be.

  The scheduling algorithm used can be as simple as a round-robin scheme that gives each process in the cycling list a predetermined equal time (eg, 1 ms, typically 1 ms to 100 ms). Therefore, process A is executed for 1 ms, then process B is executed for 1 ms, then process C is executed for 1 ms, and then returns to process A.

  More advanced scheduling algorithms take into account the priority of the process, i.e. the importance of the process. This allows some processes to use longer CPU time than other processes. It can be said that the kernel always uses some resources needed to ensure proper functioning of the operating system and therefore has infinite priority. In a symmetric multiprocessor (SMP) system, it is believed that processor affinity improves overall system performance even if the processor affinity is the cause of slowing down the operating speed of the process itself. Processor affinity generally improves performance by reducing cache thrashing.

I / O Scheduling This section is about I / O scheduling, which is different from process scheduling. I / O scheduling is a term that describes the method used in a computer operating system to determine the order in which blocked I / O operations are sent to the disk subsystem. I / O scheduling is also called disk scheduling.

Objectives The I / O scheduler can have many objectives, depending on the goals of the I / O scheduler, and will show the common goals below.

• Minimize time wasted by hard disk seeks.
Prioritize specific process I / O requests.
Allocate disk bandwidth to each running process
Ensure that a request is issued before a specific deadline.

Implementation I / O scheduling usually has to work with a hard disk, and the access time is long due to a request to move the disk head far away from the current position (this operation is called seeking). It has the characteristic of becoming. In order to minimize the impact of this seek operation on system performance, most I / O schedulers use various elevator algorithms (elevator) that rearrange requests entered in random order into the order they are detected on disk. algorithm) is implemented.

General disk scheduling rules / Random Scheduling (RSS)
・ First In First Out (FIFO), also known as First Come First Served (FCFS)
・ Last In, First Out (LIFO)
・ Shortest seek first (aka Shortest Seek / Service Time First: SSTF)
Elevator algorithm, also known as SCAN (including variants C-SCAN, LOOK and C-LOOK)
-N-step SCAN (N-Step-SCAN) that scans N records at a time
FSCAN, step SCAN where N is equal to the first queue size of the SCAN cycle (Step-SCAN)
・ Completely Fair Queuing (CFQ (Linux))
-Anticipatory scheduling

  FIG. 1 is a schematic diagram illustrating a KOS scheduler operating system 100 according to an embodiment of the present invention. The KOS scheduler operating system 100 includes a plurality of operating systems 101-106 that run in a single memory, all operating systems 101-106 interface with an application indicated by an outer shell 115.

  FIG. 2 is a schematic diagram illustrating a KOS scheduler operating system 120 according to another embodiment of the present invention. The KOS scheduler operating system 120 includes a plurality of operating systems 121-126 that run in a single memory, and the operating systems 121-126 interface with the resources indicated by the outer shell 130, which are the outer shells 135. It is interfaced with the application shown in.

Multi-OS KOS System In multi-tasking, the kernel gives the user the illusion that more processes are running simultaneously on the computer than the maximum number of processes that the computer can be physically running at the same time. be able to. The present invention makes this illusion a reality by increasing the number of processors from one to more than one, and the event as an event requesting resources, communication, scheduling, delegated, routing and subcontracting ( Using a specially designed scheduler software that outsources, we actually propose a KOS design that increases the number of operating systems actually installed in a computer system that function simultaneously with each other. Normally, the number of processes that can be operated simultaneously by the operating system is equal to the number of CPUs mounted (except when the processor supports simultaneous multithreading). The preferred embodiment of the present invention requires that a plurality of CPUs be installed, and in order to achieve the maximum performance, the number of operating systems that function simultaneously in cooperation with each other is limited. Propose that it must be equal to the number. The UNIX-KOS design also proposes that multithreading continues to be executed within each operating system kernel, but the KOS scheduler is based on the resources required by the application and the resources supported by each operating system. Thus, it remains to communicate, outsource and route application programs to / from each installed operating system.

KOS Concept A distributed kernel operation scheduler (distributed KOS) is a distributed operating system that operates in synchronization with other kernel operation schedulers. Each KOS operates in parallel with other similar KOSs, with two or more operating systems within a given computer system environment, and certain computers with two or more CPUs, These environments are considered single computer systems. In some nomenclature, distributed computing means that computing resources are distributed across many different computer platforms, and all computer resources work together under one subject. In concert. KOS is similar, except that distributed KOS are in a single computer system environment, are very close to each other and operate as a single computer system. Each KOS is in a single kernel. Each kernel has a single scheduler, which is designed by the KOS after it has been designed to have communication functions that communicate with other similar KOSs of the kind that schedule events. Replaced.

  Data processing can be divided into a series of events, whereby each event requires some computer resources to complete the data processing. The scheduler is the most responsible program in the kernel with the task of assigning CPU time, resources and priority to events. Thus, when scheduling CPU time resources under a time-sharing scenario, a particular event includes any resources needed to complete that particular event, plus the remaining resources, For example, memory, temporary I / O bus priority, and the like are given. The KOS according to the present invention is a kernel operation scheduler in which there are multiple KOSs per single system, and each KOS operates on simultaneous events that operate simultaneously and require computer resources to complete. Manage the execution of In addition, each KOS may require similar resources that are controlled by the semaphore in the kernel environment space, or a shared portion of memory when such resources are limited or insufficient. The distributed OS KOS and its core scheduler are distributed computing connected to general-purpose CPU hardware, and each distributed OS has a unique ID at the time of initialization. Assigned to.

Unix System IPC (Unix System IPC)
IPC Facilities and Protocol Stacks
The IPC function and protocol stack resides in the UNIX structure and is already integrated as a utility. These utilities are used to communicate between operating systems under the UNIX structure.

  Table 1 is a table in which IPC types are mapped to specific resources supported by KOS. Referring to the information in Table 1, the seven IPC types in the first row are used for communication between processes in the local kernel and the scheduler operating system, and the last two rows are on the same computer. Yes, it is used for communication between operating systems distributed across multiple CPUs on the same computer system.

  STREAMS Linux support is available as a separate optional package called "LIS".

  The seven IPC types in the first row of Table 1 are usually limited to IPCs between processes on the same host operating system. Only the last two rows of sockets and STREAMS are generally supported for IPC between processes on different hosts.

Kernel scheduler The kernel scheduler has the function of filtering and selecting the resources required to determine where to perform the current process. For example, each CPU is usually a general-purpose CPU, whereas each KOS is more specialized. Part of the memory is shared between each KOS so that pointers and file descriptors are passed between each KOS instead of the actual file data. By using the IPC function, any process can be moved across multiple CPUs and across multiple KOSs, and thus the required transactions can be in the form of a transactional protocol between processes. Can be moved.

  In one embodiment of the present invention, an application, such as a speech synthesizer, can exclude I / O resources when it has to disable interrupts, queues and swap out to allow preemption. It can operate continuously on a specific CPU using KOS that uses, thus continuously. In other embodiments, the application is DVD format video streaming, which is a scenario that must be swapped out from time to time to achieve optimality between processes within a centralized OS. It can operate using a specific CPU, memory and KOS without facing a centralized scheduler.

Shared memory Shared memory is a very integral part of the current UNIX structure and is now used for specific conventions, but shared memory is also a KOS, current rule. Below, it can be implemented in a specific way to function for the purpose of a distributed OS. In one embodiment of the present invention, each operating system kernel incorporates a scheduler, which is an indispensable key component player for each kernel. The KOS of each distributed operating system is a KOS scheduler. If there are four such operating systems with four such schedulers, each scheduler is designed to communicate with other schedulers of other operating systems. This communication is designed so that resources of other schedulers can be shared. Each scheduler is attached to a specific set of resources, which includes typical computer resources such as disk access, Internet access, movie DVD player, music DVD, keyboard communication, etc. It is. These resources are connected to a predetermined set of operating system kernel schedulers, each of which performs specific processing that requires special resources at a specific given point, and others. Can be outsourced or off-loaded to other KOS running on the other CPU. Each scheduler is assigned a portion of memory. The scheduler and its kernel, along with other KOS, are mapped to main memory and their CPU.

TCP / IP protocol group (TCP / IP Protocol Suite)
TCP / IP local can be used as a resource for transferring data and application files between the CPU and the KOS. Each KOS is local to its own CPU and may or may not have I / O with independent memory mapped. In one embodiment, a TCP port loop-back facility that is resident in many UNIX systems is used, and this TCP port loop-back function is implemented under other KOS system configurations. It is configured to send and receive data files to and from the operating system.

UDP Protocol Mechanism (UDP Protocol Mechanics)
User datagram (UDP), user defined protocol (User defined protocol) is a part of TCP / IP protocol group, and imports data files between independent CPU and operating system under KOS rules. Can be configured to export. Also, UDP can be configured to pass messages between operating systems that reside on independent CPUs.

I / O CPU-based operating system The I / O bus controller functions as a special purpose device, but is also specific to specific tasks related to disk operation or processing of channel data for main memory input or output Direct tasks. Such a controller has more functional capabilities and is a general purpose resident software, eg KOS, that can provide a reconfigurable application to a specific controller rather than a hard wired application. It can be easily replaced by the CPU. In an embodiment of the present invention, an I / O CPU or processor resides an I / O operating system having a scheduler that is specifically designed to handle only general system I / O functions. As a result, the bus data has the ability of the CPU to form an I / O queue as a necessary condition, so that a bottleneck in the controller can be avoided.

  Table 2 shows specific KOS types and specific resources that each type of KOS is specialized to support. For example, Table 2 specializes to perform video I / O when the media OS (5th row in the first column) operates, for example, a CD / DVD (5th row in the 4th column). It has been shown. Similarly, Table 2 shows that disk I / O is performed when the disk OS (seventh row in the first column) communicates via, for example, a channel bus (seventh row in the second column). It is shown that

  In one embodiment of the present invention, a configuration based on the concept of being portable is used, and the operating system assigns the function to a thread that operates independently. Can be divided. In this way, each thread has the ability to perform operations independently of each other under a different independent scheduler.

  The various process states shown in the state transition diagram show possible transitions between states indicated by arrows, some processes are stored in main memory, and some processes are stored in secondary (virtual) memory. The

  FIG. 3 is a diagram showing a state transition 200 of kernel process scheduling. The state transition 200 includes a “Created” state 201, a “Waiting” state 207, a “Running” state 205, and a “Block” state. ("Blocked" state) 209, "Swapped out and blocked" state 213, "Swapped out and waiting" state 211, and "Finished" "Terminated" state 203. Details of these states will be described later.

  Embodiments of the present invention allow multiple operating systems to function in concert with each other and are specialized by the resources they manage, thus waiting for execution to be “received” outsourced or out-routed By using it as a queue for inputting events, the need for “swap out and waiting for execution” and “swap out and blocking” is eliminated. Embodiments of the present invention leave the ability to distribute multi-threading, swap-out and pending / blocks to be deployed as a function to perform a design different from the current design.

Primary process states
The following typical process conditions can occur in all types of computer systems. In most of these states, the process is “stored” in main memory.

Created (also called “new”)
When a process is first created, the process is in a “created” or “new” state. In this state, the process is waiting for admission into the “ready” state. This admission is approved or delayed by the long-term scheduler, ie the input scheduler. Typically, in most desktop computer systems, this input is automatically approved, but in real-time operating systems, this input may be delayed. In a real-time operating system (RTOS), if too many processes are put into the “runnable” state, they become oversaturated and system resource contention begins, resulting in deadlines in the process. You can't avoid that.

Ready (also called “waiting” or “runnable”)
An “executable” process or a “waiting to execute” process is already loaded into main memory and is waiting to be executed on the CPU (a dispatcher, ie a short-term scheduler, causes a CPU context switch). There may be many “runnable” processes at some point in the execution of the system. For example, in a single processor system, only one process can be executed at a time, and all other “concurrently executing” processes are waiting to be executed.

Running (also called "active" or "executing")
An “running” process, an “executing” process, or an “active” process is a process that is currently executing on the CPU. From this state, the process is context switched out by the operating system and returned to the “ready” state when the time slice assigned to it is exceeded. Note that this process may be completed or terminated, or blocked by some required resources (eg, input / output resources) and transition to a “block” state.

Blocked (also called “sleeping”)
When a process is “blocked” by a resource (eg, file, semaphore or device), the process is removed from the CPU and becomes blocked. A process remains “blocked” until its resources are available, and in the worst case a deadlock. From the blocked state, the operating system can notify the process that the blocked resource is available (the operating system itself notifies that the resource was made available by an interrupt. ) Once the operating system knows that the process is no longer blocked, the process is again in the “ready” state and can be dispatched from this ready state to the “run” state. Once in the running state, the process can use the newly available resource for it.

Terminated
A process can be terminated from the “executed” state by completing its execution or by explicitly killing it. In either case, the process moves to the “finished” state. If a process is not removed from memory after entering this end state, such a state is also referred to as a “zombie”.

Additional process states
In a system that supports virtual memory, there are two additional process states. In both of these process states, the process is stored in secondary memory (usually a hard disk).

Swapped out and waiting (also called “suspended and waiting”)
In systems that support virtual memory, the process can be swapped out, that is, the process is removed from main memory and placed in virtual memory by the medium term scheduler. Then, the process can be swapped back to the execution waiting state from the virtual memory.

Swapped out and blocked (also called "suspended and blocked")
Blocked processes may also be swapped out. At this event, the process has been blocked and swapped out, and the swap-out and waiting processes can be swapped back to the same state (ie, in this case, the process is in the blocked state). Migrating and waiting for resources to become available).

Scheduling
In a multitasking kernel (such as Linux), there can always be multiple processes, and each process can operate as if it were just one process on the system. The process does not need to be aware of any other process unless explicitly designed. This allows programs to be easily developed, maintained and ported. Each CPU in the system can only execute one thread in the process at a time, but it appears that many threads from many processes are running simultaneously. This is because threads are scheduled to run for a very short time and give other threads an opportunity to work. The kernel scheduler enforces thread scheduling policies, including when, how long, and possibly where (on the SMP system) threads can run. Usually, the scheduler runs in its own thread, which is activated by a timer interrupt. Alternatively, this thread is called by a system call or other kernel thread that wants to yield the CPU. The thread is allowed to run for some amount of time, and a context switch to the scheduler thread occurs, followed by another context switch to the thread selected by the scheduler. This cycle is repeated and in this way a specific policy for CPU usage is performed.

CPU-bound and I / O-bound threads (CPU- and I / O-bound Thread)
Thread execution tends to be either CPU bound or I / O bound (Input / Output bound). That is, some threads use a long time CPU to perform computations, and some other threads wait a long time to complete a relatively slow I / O operation. For example, a DNA sequencing thread is CPU bound. Threads that input word processing programs are I / O bound because they spend a lot of time waiting for humans to type. Whether a thread is CPU bound or I / O bound is not always clear. Even if you really consider which thread the scheduler is, the best that the scheduler can do is guess. Many schedulers consider whether a thread should be considered CPU bound or I / O bound, so the technique of classifying threads as either is an important factor for the scheduler. . The scheduler tends to give priority to access the CPU to I / O bound threads. Human input programs tend to be I / O bound, and even the fastest typist takes a lot of time between each keystroke, and the program with which the typist interacts simply waits during this time It is. When humans are expecting a quick response, it is important to give priority to programs that interact with humans because they are aware of slow and slow responses.

Round-Robin Scheduling Algorithm
Scheduling is the process of assigning a series of resources to a task. Scheduling is an important concept in many areas, such as computing and production processes.

  Scheduling is a key concept in multitasking and multiprocess operating system design, and real-time operating system design. Scheduling is a method of assigning priorities of prioritized queues to processes. This allocation is performed by software known as a scheduler.

  In a general purpose operating system, the purpose of the scheduler is to balance the processor load and prevent any one process from monopolizing the processor and starving resources. In real-time environments, such as automatic control equipment in the industry (eg for robotics), the scheduler must also ensure that the process can meet deadlines. This is important for keeping the system stable.

  The round robin method is the simplest scheduling algorithm for processes in the operating system. This algorithm assigns time slices to each process in the same length and in order so that all processes have the same priority. In a prioritized scheduling system, processes with the same priority are often addressed in a round robin manner. This algorithm starts at the beginning of a list of process descriptor blocks (Process Descriptor Blocks: PDBs) and gives each application an opportunity in turn when a time slice becomes available.

  Round robin scheduling has the advantage of being easy to implement in software. Since the operating system must have a reference to the beginning of the list and a reference to the current application, it is easy to determine what to do next, following the placement or chain of PDBs for the next element. Can be determined. Once the end of the placement is reached, the selection is returned to the beginning of the placement. A blocked application unnecessarily wastes CPU time, and worse, it makes the task think it has found the resource when it actually has to wait a bit more, so this blocked application The PDB must be examined to ensure that it is not inadvertently selected. The term “round robin” is derived from the principle of round robin, which is known in other fields where each individual shares something in order.

  Briefly, each process is assigned a time interval called its quantum, during which time the process can operate. If the process is still running after the quantum ends, the CPU is preempted and given to other processes. If the process is blocked or terminated before the quantum elapses, the CPU is switched when the process is blocked.

  The scheduling algorithm can be divided into two categories as to how clock interrupts are handled.

Nonpreemptive Scheduling
Once a process is given a CPU and the process continues to have a CPU, the scheduling rule is non-preemptive. Some features of non-preemptive scheduling are described below.

  1. In the non-preemptive method, a short job is waited for by a longer job, but the overall processing of all processes is fair.

  2. In the non-preemptive method, since the input highest priority job cannot move the waiting job, the response time is easy to predict.

3. In non-preemptive scheduling, the scheduler executes jobs in the following two aspects.
a. When a process switches from an execution state to a waiting state b. When the process ends

Preemptive Scheduling
Once a process is given a CPU, the scheduling rule is preemptive if the CPU may be picked up. A strategy that allows a logically operable process to be temporarily stopped is called preemptive scheduling, as opposed to a run to completion method.

  Round-robin scheduling is preemptive (at the end of the time slice) and therefore the time-sharing environments where the system needs to guarantee reasonable response times for interactive users. ) Is effective.

  The most noticeable problem in the round robin method is the length of the quantum. If the quantum is set too short, too many context switches will occur, reducing CPU efficiency. On the other hand, if the quantum is set too long, the response time is delayed and the first come first service (FCFS) approach is approached. A specific example is shown below.

  Assume that task switching is 2 ms. If the quantum is 8 ms, a very good response time can be guaranteed. In this specific example, all 20 users are logged into a single CPU server, and all users generate requests simultaneously. Each task takes 10ms (8ms quantum + 2ms overhead) and the 20th user gets a response in 200ms (10ms x 20), ie 1 / 5s.

On the other hand, the efficiency is as follows.
Total effective time = 8 ms / 10 ms = 80%, that is, 20% of CPU time is wasted on overhead.

  At a 200 ms quantum, the efficiency is 200 ms / 202 ms = approximately 99%.

However, when 20 users make requests simultaneously, the response time is 202 × 20 = 4040 ms, ie, 4 s or more, which is not preferable. Define parameters to get an overall picture of what is actually happening.
Response time—the time for the process to complete. The OS prefers certain processes or wants to minimize statistical properties such as average latency.
Implementation Time—This includes algorithmic and maintenance complexity.
Overhead—The time to decide which process to schedule and collect the data needed for this selection.
Fairness-the difference in the degree to which user processes are handled differently.

  Therefore, increasing the quantum ensures that the efficiency is improved, and shortening the quantum ensures that the response time is shortened. Throughput and turnaround depend on the number of jobs in the system and I / O usage per task. The round robin method is clearly fair.

  In any case, the average latency under round robin scheduling is often very long and the process may use less time than its time slice (eg, semaphore or I / O operations). Blocking). An idle task must never acquire a CPU except when there are no other tasks running (the idle task must not participate in round robin).

  The latest major operating systems operate on round-robin variants, and the most important improvement they bring is process priority classes.

  A simple algorithm for setting these classes is to set the priority to 1 / f, where f is the fraction of the last quantum used by the process. A process using only 2 ms out of 100 ms has a priority level of 50, and a process using 50 ms before blocking has a priority of 2. Thus, a process that uses the entire 100 ms quantum has the lowest priority (unlike Linux, which sets the priority to 1-99, the other priority is C-style [0... 99]. 1 in the system).

  There are clearly three configurations in the operating system design of the KOS scheduler. FIG. 1 shows a closed cluster KOS configuration in which resources are distributed along the outer perimeter, as with all other conventional operating systems.

  FIG. 4 illustrates a system 300 having several additional features that are possible under the KOS conceptual design. These additional functions include a dedicated centrally located routing OS function (only for the purpose of receiving events from the input mechanism and routing the events to the appropriate distribution OS that gains access to the resources). central routing OS facility) 301 is included. Under this design, each operating system 310-316 has a limit built into its memory footprint that can be reached immediately to obtain full resolution of each event assigned to it. Have the specified number of resources. In the outer periphery, there are additional resources that can be considered system resources, and each internal OS 310-316 must share these resources, but extend events (extend resources for completion) Can be reserved for jobs that need to).

  As illustrated in FIG. 4, the system 300 includes a plurality of operating systems 310 to 316 surrounding the OS function 301. In FIG. 4, the operating systems 310-316 are surrounded by the outer shell of the resource 330, and then the resource 330 is surrounded by the outer shell of the application 340.

  One method of configuring the kernel operation scheduler is Star Configuration. Under a star configuration, one kernel is configured to act as a central dispatcher, and the role of receiving processes from the ready state is responsible for the necessary resources such as additional memory allocation, stack Screening a process for requests, robust I / O traffic, etc. and dispatching the process to an appropriate operating system environment configured to support such requests. Under a star configuration, no process is blocked, i.e. sleeping, and traffic flows using only three states: an execution state, a wait state, and a switched state.

Star Core Kernel Configuration in system S1
The kernel functioning as the core is surrounded by n other kernels. FIG. 5 shows a star core kernel configuration 350 in system S1 according to one embodiment of the present invention. This star core kernel configuration 350 comprises a Central Routing Operating System 360 with KOS, which is surrounded by kernel operating systems 351-356, These kernel operating systems 351 to 356 are surrounded by the outer shell of the application 363. The outer shell surrounding each operating system 351 to 356 corresponds to a resource that can be used by each operating system 351 to 356. The central routing operating system 360 takes the following typical process states:

  1. When a process is first created in system S1, it becomes a new process state that is screened for the resources it needs (see chapter on system resources). Once the required resources have been determined, the core is an operating system (ideally an I / O operating system (see I / O operating system)) that is likely to meet these resource requirements. Is in an idle state). Once the appropriate OS is determined, the process transitions to the switched state (usually from the ready state) and in the next cycle of the clock, the process is dispatched to the appropriate operating system in system S1. .

  2. The core has an “execution state” that is used to communicate with all other execution states based on the processes that have already been dispatched and should be currently running. The execution state of the core does not actually run the process, but the progress of all the running processes in the system S1 is tracked, and each state is notified to the console. Virtual execution state.

  3. The executable state of the spawned process is the state below the star core kernel that acts as a priority triage state or screening state, and the peripheral kernels below the star core kernel In any of the (peripheral kernel), the peripheral kernel functions as a waiting state or a runnable state, just as it is under the conventional process state.

  FIG. 6 is a high-level block diagram of a plurality of kernels 601, 630, 640 communicating via a communication channel C680, each kernel having an application program A that switches out and an application program B that switches in . For example, the kernel 601 is executed by the central processing unit 602 and includes a scheduler 607. The KOS 610 has an execution state 611, an execution wait state 612, and a switching state 613 for switching the application program A 615. FIG. 6 shows application A 615 to be switched out and application B 605 to be switched in. The kernels 630 and 640 operate in the same manner as the kernel 601, and will not be described further. The communication channel C680 connects the KOS schedulers in the kernels 601, 630, and 640 across a plurality of CPUs.

Shared memory
FIG. 7 shows a system 700 that includes shared memories Σ1720, Σ2721, Σ3722, Σ4723, and an environment of operating systems 710-713. As shown in FIG. 7, shared memory Σ1720-Σ4723 is just part of the UNIX operating system, and abstraction is currently provided for use with specific rules, but shared memory Σ1720 to Σ4723 can be implemented in a specific way to serve the purpose of a distributed operating system according to an embodiment of the present invention. If each operating system kernel is a dedicated scheduler and there are four such operating systems 710-713 having these dedicated schedulers, then each scheduler can share the resources of other schedulers, in other ways The scheduler is designed to communicate with other schedulers. If each scheduler attaches to a specific resource known to other schedulers at initialization (startup), it is part of the category of resources it serves at any point in its operation Can be outsourced to other schedulers.

  Each scheduler is assigned a portion of its memory that is shared with other schedulers, and outsources other schedulers for operations that require a program that operates on the data set that it accesses and processes to complete. If so, the outsourced scheduler passes only the pointer and file descriptor to the receiving scheduler, not the amount of data itself. Pointers and file descriptors can be queued on the receive scheduler for processing by the CPU.

IPC Facilities and Protocol Stacks
Not only the protocol stack but also the IPC function is provided separately from the UNIX structure, both of which are already integrated as utilities. These utilities are also useful in the present invention. These utilities are configured in a manner intended to communicate a large amount of communication between operating systems in a cluster, with the exception of current distributed computing that is built into specific computer systems, rather than across several platforms. can do.

IPC Scheduler
FIG. 8 shows the network controller as one resource, and a data packet 751 is transmitted to a network operating system (NOS) 755. As shown in FIG. 8, the kernel scheduler includes a filter that acquires resource processes, and the kernel scheduler first selects the resources needed to determine where the process should occur. Each CPU is a general purpose CPU and the kernel of each operating system is more specialized or dedicated to the allocation of resource groups or sets. FIG. 8 illustrates one embodiment of a specialized or dedicated operating system used in accordance with the present invention. The NOS 755 can use one or more of protocols such as FTP, PPP, Modem, Airport, TCP / IP, NFS, and Appletalk, and can use a port depending on proxy options. .

  Note that the memory is divided into four (quadrant), a part of the memory is divided among the operating systems, and pointers and file descriptors are allocated from the operating system by allocation rather than moving a large amount of data. It is clear that it can be passed to the operating system. By using the IPC function, the process can communicate messages in the form of a transaction protocol to carry the necessary transactions.

  In one embodiment, an application, such as a speech synthesizer, can run continuously on a CPU that utilizes a particular I / OOS without interrupting the process. In other embodiments, an application, such as a video stream, utilizes a specific CPU, memory, and an OS that is not controlled by a scheduler that swaps programs in and out during their lifetime, Can work.

  FIG. 9 illustrates a KOS 790 according to one embodiment of the present invention, which processes the I / O key 781, AOS sound system 782, I / O video 783, and I / O disk 784. And an I / O universal serial bus (USB) 785, an I / O auxiliary port 786, a print OS 787, and an I / O net controller 788. As shown in FIG. 9, the I / O USB bus 785 has a controller, which is a manager of resources on that bus. Resources are necessary to move data in both directions along the bus. I / O is no longer a subfunction of the operating system because it is a major function of any computer. In the embodiment of the present invention, the operating system coordinates not only asynchronously but also a plurality of lower-level operating systems operating in parallel.

I / O Operating System The I / O operating system performs a data read from a centralized asynchronous central OS and determines the controller function that determines when and how to transfer the data. Run.

  The construct according to the present invention is distributed into operating system functions based on the concept of being portable, which can have its function divided into threads, where threads are Similar, but can share other threads code, data and other resources.

  The construct in one embodiment shown in FIG. 10 deploys one operating system function 801, 803, 805, 807, 812, 814, and all system calls are threaded communication ( Asynchronous operating systems 810 and 816 are formed that operate with each other using threaded communication. Each operating system with its own independent kernel is specially designed for two specialized functions and queue management. This arrangement divides the cycle time by distributing all tasks around the computer and uses multiple CPUs. Each kernel is tied to one CPU, and the controller is replaced by a CPU or special purpose controller.

Primary KOS process states
The following typical process conditions can occur in all types of computer systems. In most of these states, the process is stored in main memory.

Generate (also called “new”)
When an application is opened and the process is first created, the process is in a “created” or “new” state. In this application state, the process is waiting to enter a “ready” state. This input is approved or delayed by the long-term scheduler, ie, input scheduler, KOS scheduler. While entering, the process enters the execution state after the required resources are examined, or the process is switched to another CPU's operating system with the appropriate resources required for operation. Reset to state.

Executable (waiting for execution)
This executable state is similar to the “executable” state of the main process states described above.

Running
This operation state is the same as the “operation” state of the main process state described above.

Switching (previously called "block" or "sleeping")
Instead of the process being “blocked” by a resource (eg, file, semaphore or device) (because the block process cannot continue execution), the process is removed from the current CPU and operating system and blocked A state is reached and the resources required by the process are transferred to other CPUs and operating systems that are continuously available. Under a single CPU / single OS scenario, the process remains blocked until its resources are available, and in the worst case deadlocked. From the blocked state, the operating system can notify the process that the blocked resource is available (the operating system itself notifies that the resource was made available by an interrupt. ) Once the process arrives at the appropriate operating system where its resources are available, the process reenters the “executable” state and is dispatched from this “executable” state to its “executed” state. From the state, the process can use newly available resources for it.

Terminated
This end state is the same as the “end” state of the main process state described above.

Additional process states
In a system that supports virtual memory, there are two additional process states. In both of these states, the process is stored in secondary memory (usually a hard disk).

Swapped out and waiting
This swap-out and waiting for execution state is the same as the “swap out and waiting for execution” state of the main process state described above.

Swapped out and blocked
This swap-out and block state is similar to the “swap-out and block” state of the main process state described above.

  FIG. 11 shows signaling enabled protocols. For example, the protocol KC can be used to synchronize multiple kernels, namely KDISPLAY 852, KI / Ofile System 1853, KAPPS 1854, KCONTROL 855, and KBUS CONTROL 856. A method is described for synchronizing three or more kernels that function asynchronously by the central and core kernels in the operating environment. The UNIX operating system consists of a core, commonly known as the kernel, that executes all of the central commands and puts multiple processes or nodes into the operating environment that perform certain tasks to perform operations. Distributed over. The method described here is different, first allowing the central core kernel to outsource most of all input and output operations to the I / O kernel, then I / O The O kernel performs the rest of such operations without placing additional burden on the central kernel or core.

  Within the operating system, file I / O, ie data transfer to / from memory, occupies most of the activity of the traditional kernel, and when the traditional kernel can be released from such a heavy task, I / O operations performed by the kernel, such as application management and command interpretation, and other core configurations, such as processing time scheduling on a particular CPU, can be completed with less latency.

  This method describes task separation between the operation of the central hierarchical kernel and several subordinate and / or asynchronous kernels. Symmetric kernel processing environments where symmetric kernels process shared information asynchronously use environmental variables that control and indicate collisions that can occur under such environmental inconsistencies. The method also describes multiple rotating kernels on a symmetric, abstract, and symmetric metaphysical wheel-like apparatus, where all rotating kernels Information is shared through environment variables used to control collisions between commands and data on which it operates.

Communication protocol (COMMUNICATION PROTOCOL)
In the embodiment of the present invention, a communication protocol is defined as a communication protocol between kernels operating under an environment and a communication protocol between processes operating under these kernels. With this communication protocol, there can be more than two processes, and communication between these processes can be made simultaneously by communication managed by processes outside of the specific type of communication to be addressed. The communication protocol can be designed differently depending on the type of configuration architecture.

  Processes line up to communication ports instead of tables of communication between processes. As shown in FIG. 12, all of the processes 911 to 916 are trying to access the communication port 910. The process manager manages communication between processes as requests and resources are released. Compared to a standard IPC table configuration, one of the many advantages provided by a communication process such as this port is that two or more processes can communicate simultaneously. Another advantage is that all communication is managed by a protocol between processes rather than the handshake abstraction. When 6 or more processes line up to establish communication between each other, each process must establish a direct line between itself and one or more other processes. .

  For example, in FIG. 12, process 911 is attempting to release resource A, and process 912 is attempting to request resource A. Communication is established between process 911 and process 912, whereby processes 911 and 912 have a shared relationship with resource A, and resource A communicates between the two processes 911 and 912. Managed by process manager. When both the process 911 and the process 912 request the resource C under a predetermined scenario, the process 911 releases the resource A while requesting the resource C, and the process 915 leads to the release of the resource C. If not, the request for process 912 is blocked until process 911 obtains resource C and releases it. This given scenario is dominated by the fact that there are many processes requesting resources and there are fewer than the appropriate number of resources available.

  The managers described below include, but are not limited to, a relationship manager, a processor manager, a thread manager, a resource manager, and a resource allocation manager. All are used in the embodiment of the KOS according to the present invention. The following describes how these managers and other components of the KOS function.

Relationship Manager (RELATIONSHIP MANAGER)
The relationship manager always manages relationships between multiple kernels running in the environment. Each kernel can serve many predetermined threads to execute their kernel code, but this element is independent of the tasks performed by the relation manager. The tasks performed by the relationship manager according to the embodiment of the present invention include the kernel and the mutual relationship between the kernels.

  Each relationship manager communicates using an established protocol, depending on the type of configuration, across the operating system in the Ring-Onion Kernel System or in each of the four configuration architectures. Share information between organized kernels. FIG. 13 shows a resource manager 921 and a resource allocation manager 922. In FIG. 13, a protocol {Al} called resource sharing represents a protocol of data transmitted from a relation manager that requests knowledge of a certain resource residing in the environment. The {B1} below the same resource manager 921 in FIG. 13 represents another layer of the same protocol, and informs the information regarding the released resources or the estimated time until the resources are released. The third parameter and protocol layer {Cl} represents the information received about the requested resource, the released resource, or where a certain resource resides.

  In another embodiment, the relationship manager RM1 generates a request for the resource Al under the relationship manager RM2. If the relationship manager RM2 knows that the resource Al is in use, the relationship manager RM2 generates a request for that resource manager RsMgr2, and thus through the system of layered protocols By sending the information back to the original, it is possible to estimate the time until the resource A1 is released.

  Once the relationship manager RM1 knows that the resource A1 has been released, it notifies the relationship manager RM3, for example, using a specific protocol layer. As soon as the relationship manager RM3 knows that the kernel or one of its threads has acquired the resource A1, under the ring architecture, all the operating kernels or operating systems in the environment The resource allocation manager is informed only to the command control operating system or kernel under the Star-Center architecture.

Configurations for task distribution
Although the schedulers that reside in all kernels play a central role in determining how tasks are distributed and executed, these schedulers are also important for the present invention, and the flow of operations in any way. It plays a central role in deciding what to do. In the embodiment of the present invention, there are four or more types of configurations that execute tasks assigned to the environment, and these configurations are considered to be the central command structure of the environment and are named as follows.

Architecture (ARCHITECTURES)
1. Hierarchical structure
In accordance with the present invention, in a hierarchical structure where multiple kernels operate simultaneously in an environment, the host kernel is at the center of all control and receives all input jobs or tasks executed by the environment. The command kernel screens the task of the required resource and assigns a specific task to the appropriate kernel that is executed until this task is completed. Below the command kernel is a relationship manager, which manages the relationship between the command kernel and subsequent kernels operating in the environment. The relationship manager manages other kernels with a control protocol structure similar to the one described above. The relationship manager records and balances resource requests and resource conditions with each of the other kernels running in the environment. To perform this chore, the relationship manager needs to understand where all tasks and jobs were initially assigned and why they were assigned to a particular kernel. Under the hierarchical structure, resources installed in the environment are assigned to a specific kernel, for example, a printer is assigned to a specific kernel, and a video screen is assigned to another kernel. Tasks that require a specific I / O driven task do not interrupt the video / audio driven task due to delays in acquiring specific resources.

2. Round-Robin
The round-robin configuration consists of tasks assigned to the kernel in a predetermined order. In this case, if the kernel does not contain the resources needed to perform the task, the relationship manager is responsible for properly forwarding the task to the next kernel. In the present invention, the round robin configuration is suitable for many different common situations, but in other situations, the beneficial effects intended by the present invention may not be obtained.

  Under a round-robin configuration, each kernel operates asynchronously with respect to other kernels in the environment and is linked by the relationship manager, so the kernel communicates with each resource manager under each of each kernel. Do. The round robin configuration does not have a control center point. In this configuration, there is no command kernel. Each kernel is considered to be in an abstract circular configuration and connects to other kernels via their respective relationship manager.

3. First-in first-out (FIFO)
Under the FIFO configuration, each kernel executes each task appearing in the environment on a first-come, first-served basis. If a particular task is fed into the kernel and the kernel is free enough to accept that given task, the task will reside in that kernel until the task is blocked for resources.

4). Star-Center
A star-central architecture is defined as a configuration having multiple kernels that surround a central command kernel in a circular fashion. The central command kernel is a controlling kernel that uses its functions to receive and organize task requests for other kernels under the Star configuration. The Star-Center configuration groups the subordinate kernels into constellations based on resources in the environment. Here, a given task needs to use a given resource, while other tasks are often blocked by that given resource until the given task completes using the given resource. The operating system to be considered. In the present invention, kernel threads are dedicated to copy specific kernels when such bottlenecks are resolved, whereas other kernels can use these threads as appropriate. . One of the many conditions for multiple operating systems is that a dedicated kernel threaded out a copy of their code to handle a particular type of attached resource. Multiple kernels not only run on multiple CPUs, but also multiple copies of themselves across multiple CPUs. Make it work.

5. Ring-Onion Kernel System
In a ring onion kernel system, multiple strip-down kernels function simultaneously within the operating system service structure. Operating system service structure means all ancillary and auxiliary files that make up a particular set of operating systems for a service. These services can be shared. Under this architecture, such as system call functions and other mechanisms external to the kernel code, design diversity can be provided and performance under specific requirements can be affected. In the case of a ring-onion kernel system, all of the kernels perform single operating system kernel tasks, but when these tasks run asynchronously with each other and share auxiliary files and functions, these tasks Run on separate CPUs.

  FIG. 1 described above shows a ring-onion kernel system in which kernel systems share the same services and functions, but execute tasks asynchronously. Each kernel has a set of immediate service functions in its local space, but a wider service is shared among all kernels in the environment.

  Although FIG. 1 shows that all kernels operate asynchronously with each other without a command and control kernel, the architecture according to the present invention allows a command and control kernel to be installed, which -Specifications similar to the central system architecture can be applied in coordination with the ring onion architecture.

Multiprocessor synchronization (MULTI PROCESSOR SYNCHRONIZATION)
One of the basic prerequisites maintained in the traditional synchronization model is that the thread is not allowed to leave the kernel until the thread is ready to leave the resource or the resource is blocked. Maintain usage rights (excluding interruptions). In multiprocessors, each processor can execute kernel code simultaneously, so the conventional synchronization model is no longer an effective model. Under a multiprocessor model with multiple threads, each type of data needs to be protected when each processor can execute its copy of the kernel code. Under the present invention, there are multiple kernels in one environment, and each kernel has multiple threads as a result of operations by multiple processes executing their own copies of kernel code. Protection is effective.

Processor manager (PROCESSOR MANAGER)
Under the present invention, the processor, and thus the CPU, becomes a managed resource as well as other resources. More specifically, the processor manager is a process that manages the number of CPUs and the allocation of CPUs to copies of kernel-specific processes that manage the use of kernels or kernel threads operating in the environment. Each request to execute a special copy of the kernel code and use a kernel thread that utilizes a particular resource is managed by the processor manager. The number of processors must be cataloged by the processor manager and assigned to each thread running in the current environment.

  In one implementation, it provides access to an inter-process communication table for multiple processes to communicate, particularly an inter-process communication table that exists in the latest kernel. The data structure of the interprocess communication table is not accessed by an interrupt handler and does not support any operations that may block the process accessing the data structure. Thus, in a uniprocessor system, the kernel can manipulate the table without locking the table. However, this cannot be done under a multiprocessor system. Thus, under the present invention, such a table is used to indicate resources that are co-operated by multiple processes executing multiple copies of resident kernel code and attached to other kernels. It must be extended so that multiple kernels that need to be used cooperate. In the present invention, once two processes access such a table in order for two processes to communicate simultaneously between the processes, such a table must be locked, and the processor manager performs management of such a table. We propose to change the current abstraction so that it can. When two or more processes attempt to access the IPC table at the same time, the processor manager allows the other processes to access the IPC table until one or more processes terminate their communication links The IPC table must be locked before it can be done. The locking mechanism is the basis of IPC communication, and under the present invention, the locking mechanism is compatible with IPC communication of multiprocessor systems in order to allow more than two processes to communicate simultaneously. Can be extended to

Inter-process Communication Table
Inter-kernel communication table (INTER-KERNEL COMMUNICATION TABLE)
Under a traditional kernel system, the kernel simply checks the lock flag and sets the lock flag to the lock position to lock the inter-kernel communication table, or locks to unlock the inter-kernel communication table. The flag is reset. Under the present invention, inter-process communication (IPC) and inter-kernel communication (IKT) become another resource in the system managed accordingly. The complexity of these tables determines the level of sophistication of the system environment. Under the present invention, in the case of a multiprocessor system, two threads operating on different processors, but managed by one processor manager, can simultaneously examine a single lock flag for the same resource. Both threads try to access a particular resource at the same time when it knows that the lock flag has been released. Thus, in the present invention, only one process performs a lock flag check, in which case such check is performed by the processor manager if the resource is a processor and the resource is other than a processor. In some cases, this is done by the resource manager. Such division of the manager can prevent to some extent that the simultaneous access cannot be predicted.

Thread manager (THREAD MANAGER)
In the present invention, a thread manager is defined as a process that runs under the current local kernel and is assigned to a lightweight process (LWP) and other processes that run under the current local kernel. Keep track of all thread usage. The thread manager reports this information to other management systems that operate to support the synchronization of multiple kernel environments (MKE). If the MKE is organized into one of the five configurations described above, the thread manager report can be modified to meet the requirements of this particular environment. For the thread manager, what is important is, for example, reporting the number of assigned threads in order to more accurately track a given resource under a particular system. Resource reporting is the role of the resource manager, and therefore the resource manager relies on a thread manager that provides this type of information.

Resource manager (RESOURCE MANAGER)
In the present invention, a resource manager is defined as a manager of resources that are considered to exist in the environment. For example, resources are considered an integral component of any operating system environment, so this statement has significant significance under systems where multiple kernels reside or can reside. The resource manager manages resources that reside at the local kernel level, and whenever a task requests a specific resource, these requests are made through the resource manager and are not available on the specific kernel. When a request for is made, the resource manager contacts the relationship manager to establish a relationship between the task that requires the resource and the kernel that has the particular resource.

Resource allocation manager (RESOURCE ALLOCATION MANAGER)
In the present invention, a resource allocation manager starts on one kernel with a particular resource, but between processes that have a starting task that requires a resource that may be attached to another kernel. Records all allocated resources. In such a situation, the resource manager needs to contact the resource allocation manager in order to find a particular resource or to inventory all available resources in the environment. In such a case, the resource allocation manager that manages all resource allocations between kernels supplies necessary information to the resource manager.

  Under certain architectures, the resource allocation manager and resource manager can reside in an OS or kernel system other than the command kernel system or operating system in the environment. In order to describe the embodiment of the present invention, it is assumed that both the resource allocation manager and the resource manager exist as part of a command operating and kernel system.

Further Specific Examples FIGS. 14 to 23 show more detailed specific examples of the embodiment of the present invention. In one embodiment of the invention, the KOS is executed within the individual operating system rather than centrally. Processes exchange information, eg, using shared memory, to inform other processes when resources are available or when resources are available. As one specific example, FIG. 14 shows two processes 1001 and 1010 for exchanging information about the resource R1 using the shared memory 1015. The shared memory 1015 includes information indicating that the resource R1 for which the process 1010 is waiting is now available. At this time, the process 1010 can request the resource R1, for example, by creating a call to the resource R1.

  Although FIG. 14 shows a shared memory including information related to a single resource, in other embodiments, the shared memory includes information related to many resources. Further, the shared memory can include information different from the information shown in FIG. 14 or further information in addition to the information.

  In other embodiments, each KOS includes a table that indicates the other KOS and the resources they support. This table also shows how the resource is invoked (eg, by entry point or system call to the operating system) and the load on the processor that is currently executing the particular operating system. For example, FIGS. 15A to 15C show specific examples of tables in each KOS in an environment where there are three processors and each processor executes KOS and supports different resources. FIG. 15A shows a table stored in the operating system OS1. A line 1101 in FIG. 15A indicates that the operating system OS2 has an entry point P2, supports resources R2 and R3, and the load on the system (processor) is 10%. Line 1103 indicates that operating system OS3 has entry point P3, supports resource R3, and the system load is 40%.

  The table of FIG. 15B stored in the operating system OS2 and the table of FIG. 15C stored in the operating system OS3 are described in the same way, and will not be described here. In operation, operating systems exchange information with each other periodically, for example, at specific times, or when their resource parameters change beyond a predetermined threshold.

  FIG. 16 shows a table 1200 that stores resource information in different formats and maps resources to operating systems. For example, row 1201 of table 1200 in FIG. 16 indicates that resource R1 is currently accessible via operating system OS1, and row 1202 is accessible to resource R2 via operating systems OS2 and OS1. The row 1203 indicates that the resource R3 is accessible via the operating systems OS2 and OS3.

  The tables of FIGS. 15A-15C and FIG. 16 are merely exemplary. A person skilled in the art can conceive many different formats and types of information contained in the resource table based on the embodiment of the present invention.

  FIG. 17 illustrates a system 1250 in which multiple KOSs exchange resource information in accordance with one embodiment of the present invention. The system 1250 includes a KOS 1251 having a relationship manager 1251A and a resource manager 1251B, a KOS 1255 having a relationship manager 1255A and a resource manager 1255B, and a KOS 1260 having a relationship manager 1260A and a resource manager 1260B. As described above, when a KOS needs a resource, the KOS checks its local kernel level using a resource manager. If the resource cannot be found or is not available, the KOS calls its relationship manager to access the resource via the other KOS.

  18 to 23 show an embodiment of a central KOS (central KOS) according to the present invention. FIG. 18 illustrates a computer system 1300 that executes a plurality of operating systems OS1 (1310), OS2 (1311), OS3 (1312), OS4 (1313), each configured to access one or more resources. ing. Both the operating systems OS1 (1310) and OS2 (1311) are configured to access the printer 1320. The operating system OS3 (1312) is configured to access the disk 1321, and the operating system OS4 (1313) is configured to access the video display 1322. In one embodiment, the operating system OS4 (1313) is specifically adapted to interface with the video display 1322. That is, for example, the operating system OS4 (1313) includes a video display driver, and the operating systems OS1 (1310), OS2 (1311), and OS3 (1312) do not include a video display driver, or The interface of the operating system OS4 (1313) supports more features, for example, less memory usage, faster, etc., or a combination of these. Only some operating systems on the system 1300 are configured to access a given resource and other operating systems are not configured in this way, or some operating systems are compared to other operating systems. Many reasons for being suitable for accessing a particular resource will be apparent to those skilled in the art.

  In operation, a process requests to use resources and is introduced into a kernel operational scheduler (KOS) 1305. The KOS 1305 first determines which of the operating systems OS1 (1310) to OS4 (1313) is best suited to supply the requested resource to the process, and then sends the process to the selected operating system. assign. When multiple operating systems can supply the requested resource, KOS 1305 uses the selection criteria described below. As one example, the process invokes a print function to access the printer 1320. Both the operating system OS1 (1310) and OS2 (1311) can access the printer 1320, but the operating system OS1 (1310) is not busy, so the operating system OS1 (1310) is selected.

  FIG. 19 shows the KOS 1305 in more detail. As shown in FIG. 19, in one embodiment, the KOS 1305 includes a command kernel 1400 and a relationship manager 1410.

  FIG. 20 shows a process table 1450 stored in the relationship manager 1410 of FIG. 19 in accordance with one embodiment of the present invention. The process table 1450 stores information on processes, resources allocated to the processes, and their priorities. For example, row 1451 of table 1450 indicates that the process having process ID 1572 is currently assigned resource R1 and has the highest priority.

  Note that the process table 1450 stores other information, for example, information indicating how long the process has been waiting for resources and how long the process has been waiting for resources when other types of information are raised. It is clear that you can.

  FIG. 21 is a flowchart of a method 1500 for scheduling a kernel operating system to process a process according to an embodiment of the invention. In step 1503 following start step 1501, the process determines which of the operating systems (OS) running on the computer system can supply the resources. Next, in step 1505, the process determines whether more than one OS can supply the resource. If only one of the OSs can supply the resource, the process skips to step 1515, and if applicable, the process proceeds to step 1510.

  In step 1510, the process selects one of the plurality of OSs using one or more selection criteria, as described below in connection with FIG. In step 1515, the process allocates resources to the process and ends in step 1520.

  FIG. 22 shows details of step 1510 shown in FIG. 21 for selecting one kernel operating system from among multiple kernel operating systems that can supply all the requested resources. In an initial step 1550, the process selects the operating system with the least load. In step 1555, the process determines whether one OS meets this criterion. If so, the process skips to step 1575. If not, the process proceeds to step 1560 and only the OS with the least load is removed from consideration.

  In step 1560, the process selects only the OS with the least waiting process or block process from the remaining OS, and removes the remaining from consideration. In step 1565, the process determines whether there is only one OS with the least number of processes waiting to be executed or block processes. If only one OS has the least number of waiting processes or block processes, the process skips to step 1575. If not, the process proceeds to step 1570 where one OS is selected from the remaining OSs by rotation, ie, another round robin method. Next, in step 1575, the process allocates the requested resource to the process via the selected OS. The process ends at step 1580. Here, it can be said that the “selection criterion” includes the state of the OS (the number of waiting processes or block processes, and the load of the processor executing the OS).

  Note that step 1510 is merely illustrative. Many variations can be conceived by those skilled in the art. For example, steps 1510 may be rearranged in a different order, some steps may be added, some steps may be deleted, or a completely different set of steps may be performed. Also good. One of the different steps is to select an OS running on a faster microprocessor if both of the two OSs can provide resources.

  FIG. 23 illustrates the components of system 1600 according to one embodiment of the invention and the sequence of transactions when a process requests a resource on a computer system. System 1600 includes an operating system 1610 that executes process 1610A to provide access to resource 1610B, an operating system 1660 that executes process 1660A to provide access to resources 1660B-1660D, and KOS 1650.

  As shown in FIG. 23, process 1610A generates a request 1706 for resource 1660B, eg, via a resource manager. As indicated by dashed line 1706, resource 1660B is not available locally, so a request 1720 for resource 1660B is sent to KOS 1650. The KOS 1650 determines that the OS 1660 can supply the resource, sends a request 1730 for the resource 1660B to the OS 1660, and the OS 1660 supplies the resource 1660B.

  The process of supplying resources depends on the specific resource requested. If the resource is a CPU, the allocation can include setting the process identifier to a run queue in OS 1660. If the resource is a disk, the allocation can include placing the process in a queue that dispatches the process to the disk.

  In the present invention, a process can be handed-off from one OS to another. As a specific example, when a process is accessing a resource through one OS, the process is slowed if another task is assigned to the processor running that OS. In other words, the OS is also a resource. The KOS according to the present invention can reassign processes to other CPUs that can execute more efficiently.

  In the embodiment of the present invention, resources can be efficiently shared, and the load can be balanced between operating systems that supply the resources. This can reduce bottlenecks, process starvation and other symptoms that adversely affect the multiprocessor system. Furthermore, resources and operating systems that are specialized to perform specific tasks can be easily assigned to the process, thereby enabling the process to execute efficiently.

  It should be noted that the KOS, its components, and algorithms based on the present invention described herein can be recorded on a computer-readable medium as instructions that can be executed by the computer to realize the functions of the KOS. These instructions may be recorded on a computer readable medium as one or more software components, may be one or more hardware components, may be a combination thereof, and are used by a computer. Any element that performs the steps of the algorithm.

  In order to facilitate an understanding of the principles and operation of the present invention, specific embodiments of the present invention have been described using details, but the specific embodiments and details referred to herein are not It is not intended to limit the scope of the invention. It will be apparent to those skilled in the art that the embodiments illustrated above can be modified without departing from the spirit and scope of the invention.

Claims (9)

One kernel scheduler and an inter-kernel communication table accessed using a flag indicating lock or permission of access to the inter-kernel communication table;
Multiple operating system kernels accessing multiple resources;
A processor manager that manages multiple processors assigned to the kernel;
A memory that stores a resource manager that handles requests for resources residing at the local kernel level;
The kernel scheduler assigns a process requesting one of the plurality of resources to one of the plurality of operating system kernels;
Kernels of multiple operating systems communicate with each other via the inter-kernel communication table to adjust allocated resources,
If the requested resource is a processor, the processor manager checks the flag to determine access to the inter-kernel communication table, and if the requested resource is not a processor, the resource manager A computer system characterized by examining the flag in order to determine access to an inter-kernel communication table.   The computer system of claim 1, further comprising a plurality of processors each executing a corresponding one of the plurality of operating system kernels.   3. The computer system according to claim 2, wherein the kernel scheduler schedules processes on the plurality of operating system kernels based on loads of the plurality of processors.   2. The computer system according to claim 1, wherein the plurality of resources include any two or more of a keyboard controller, a video controller, an audio controller, a network controller, a disk controller, a universal serial bus controller, and a printer.   The computer system of claim 1, further comprising a process table that matches resource requests to one or more of the plurality of operating system kernels.   The computer system of claim 1, further comprising a communication channel between a pair of the plurality of operating system kernels.   The computer system of claim 1, wherein the plurality of operating system kernels exchange information regarding processor load, resource availability, and estimated time until the resource becomes available. Multiple processors each executing an operating system kernel and accessing one or more resources;
An inter-kernel communication table that is accessed using a flag indicating lock or permission of access to the inter-kernel communication table and permits communication between operating system kernels;
An allocation module programmed to match a process requesting the resource to one of a plurality of operating system kernels connected to access the resource and dispatching the process;
If the requested resource is a processor, the flag is checked in the first process to determine access to the inter-kernel communication table, and if the requested resource is not a processor, the inter-kernel A kernel scheduling system characterized in that it is examined in a second process to determine access to a communication table.   9. The kernel scheduling system according to claim 8, wherein each of the plurality of processors is controlled by a corresponding processor scheduler.