Operating system based on server / execution stream model

Abstract

The invention relates to an operating system based on service body and execution flow model. The model comprises service body and execution flow, wherein, each service body has its own address space and service bodies adopts message to communicate to each other, besides, said execution flow is a trace formed by physical CPU executing orders and is continuous.The said service body is used to accomplish the function of all functional components in operating system and execution flow only comes into service body through a small port, wherein, other system softwares and user program are loaded on execution system in the mode of service body and said service bodies are set with a core service body to direct execution flow into service body through small port.

Description

technical field [0001] The invention relates to basic software used in computer systems, in particular to an operating system based on a service body / execution flow model. Background technique [0002] At present, the operating system adopts the process / thread model, such as figure 1 As shown, one thread corresponds to one virtual CPU, thereby hiding the relevant information of the physical CPU from the user, providing a clear programming model, and a better speedup ratio can be obtained when the system increases the number of physical CPUs. However, because the process / thread model tightly couples data storage and data calculation, and adopts the concept of virtual CPU, it leads to the following main disadvantages: [0003] (1) The communication between threads is asynchronous, which will inevitably lead to delay or loss of information processing, and the uncertainty of delay limits the real-time performance of the system. When an event re-entrant occurs, since the commun...

AI Technical Summary

Problems solved by technology

[0003] (1) The communication between threads is asynchronous, which will inevitably lead to delay or loss of information processing, and the uncertainty of delay limits the real-time performance of the system

When the reentry of an event occurs, because the communication is asynchronous, the thread cannot perceive that the event is activated again, which will cause the loss or delay of the event

It is difficult to effectively solve this problem under the process / thread model of the existing operating system

[0004] (2) The thread / process abstraction ignores a large number of synchronization relationships between threads, and all use asynchronous methods to run logical synchronization through shared memory. The result is a lot of unnecessary sleep, wake-up, and scheduling for the system. Complicated operations increase operating overhead, reduce system efficiency, and make migration of processes in distributed systems an intractable problem

[0005] (3) The process / thread model shields the relevant information of the physical CPU, which is not conducive to writing efficient programs, especially for multi-processor systems, users do not know the number of real processors in the system when programming, thus losing the ability to schedule threads Participation opportunities, thread scheduling can only be determined by the scheduler using predictive methods, and predictive methods make the system more complicated and it is difficult to obtain the expected efficiency

[0009] (1) Due to the high coupling between system modules and the lack of effective means of interaction between processes, the expansion of functions can only be realized by adding corresponding modules in the kernel, which requires system developers to have a deep understanding of the data structure and algorithms of the kernel, And this is difficult for ordinary users to do, so the scalability of this kind of operating system is very poor

[0010] (2) All kernel modules run in the core state, all in the same kernel space, and each part lacks protection. Therefore, errors in kernel modules can cause the entire system to crash, and it is difficult to ensure high reliability of the system. Moreover, it is difficult to implement kernel upgrade

[0011] (3) Since there is no isolation between kernel modules, errors caused by one module are likely to be propagated to other modules in an imperceptible way, and such errors may occur in various forms after a considerable period of time. Reflected in the form, it is very difficult to troubleshoot and locate errors, so the robustness of the system is poor

[0012] (4) Since all modules are connected to each other through connectors, when the parameters and semantics of one party change, many parts of the system will often be affected and corresponding changes must be made, otherwise it will easily cause errors that are difficult to troubleshoot. To construct a system, only Only components with agreed version numbers can work together normally, which brings great difficulties to the archiving, maintenance, release, and transplantation of kernel components. Therefore, the maintainability of the system is poor.

[0013] (5) Since the communication of each part of the kernel is based on function calls, it is difficult to transparently propagate the services provided by a module to other processors in realizing distributed processing, so it is difficult for the system to effectively support distributed services

However, in order to maintain the thread model from being destroyed, the additional price that must be paid is: 1) The affiliation of the thread / process must be changed with the entry and exit of the call point, so as not to destroy the semantics of the original thread model

2) Synchronous calls across address spaces can only be realized through the asynchronous function of the upper layer protocol

The Container / Loci model has abandoned a lot of content in the process / thread model and realized the separation of storage and computing, but they still stay in the research of permanent storage and single address space, and the use of virtual Loci will obviously still affect system efficiency

Images