CN100336019C - Operating system based on server / execution stream model - Google Patents

Abstract

The present invention relates to an operating system based on a service body/execution stream model. The service body/execution stream model is composed of two mechanisms, namely service bodies and execution streams, wherein each service body has own service body address space, and the service bodies are mutually communicated through messages; the execution stream is a track formed by that a CPU along executes instructions along an instruction execution sequence indicated by an instruction counter, and the execution stream is consecutive; the service bodies are used for realizing the functions of all functional components in the operating system, and the execution streams can only enter the service bodies through small ports. Besides, other system software and user programs in the operating system are loaded into the operating system in the mode of the service bodies; a core service body is arranged in each service body, and the core service bodies are used for guiding the execution streams to pass through the small ports of the series bodies to enter the service bodies and providing basis service. The service body/execution stream model has obvious superiority in the aspects of real-time performance, multi-processor support, expandability, maintainability and support for distributed processing and active networks.

Description

Operating system based on server/execution flow structure

technical field

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

At present, the operating system adopts the process/thread model. As shown in Figure 1, one thread corresponds to one virtual CPU, thus hiding the relevant information of the physical CPU from the user and providing a clear programming model. A better speedup ratio can be obtained when counting. 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:

(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 event reentrance 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.

(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 process migration in a distributed system a difficult problem to solve.

(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 and 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.

The specific methods of constructing the operating system based on the process/thread model can be divided into two construction methods: a single large kernel and a microkernel.

As shown in Figure 2, the operating system with a single large kernel structure expresses the execution flow through function calls in the kernel part, while the user program outside the kernel still uses the process/thread model. The single kernel emphasizes guiding the physical CPU to execute the kernel code and have execution flow flow between modules through simple function calls rather than through inter-process/thread communication.

The significant advantage of a single large-core operating system is high efficiency, so it is widely used, but its shortcomings are increasingly revealed, mainly in:

(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 operating system is very poor.

(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.

(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.

(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.

(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. Therefore, it is difficult for the system to effectively support distributed services.

As shown in Figure 3, the microkernel model was proposed by Carnegie Mellon University in response to the above-mentioned shortcomings of the single-kernel structure, especially the difficulties encountered in supporting distributed computing. There is also a kernel shared by all processes in the system. The difference is that almost all system services are removed from the kernel and implemented by user-level processes outside the kernel.

The microkernel structure has obvious advantages in terms of scalability and maintainability, and can transparently extend services to distributed environments through a location-independent inter-process communication mechanism. Its disadvantage is that the low efficiency of operation is caused by frequent inter-process communication. Although technologies such as Hand-off scheduling, high-speed IPC, and call gates can improve efficiency to a certain extent, these technologies are all due to damage to execution. The hierarchical relationship between streams and processes/threads cannot get rid of the constraints of the process/thread model, and cannot achieve the desired purpose.

The academic community has recognized the inherent flaws of the process/thread model, and major research efforts to overcome or compensate for this flaw have been:

(1) The mach research group of CMU proposed the concept of Continuations to reduce the overhead of thread switching and stacks, and optimized IPC to speed up message delivery. To a certain extent, the inter-process communication is synchronized, which reduces the communication overhead. But continuations can only be used in the kernel, and can only be optimized in some special environments, and cannot meet the performance requirements of distributed computing.

(2) The proposal of Active Message aims to reduce the communication overhead in large parallel machines. The method is to connect the communication process and the calculation process to avoid the delay caused by thread scheduling, data caching and copying. But this method is subject to the following limitations: 1) the processing routine cannot be blocked during operation; 2) it may cause deadlock; 3) the running time of the processing routine cannot be too long, otherwise it may block messages sent from other networks .

(3) Calling across address spaces has developed into a procedural IPC under the microkernel model. The basic principle is: through the service process providing the calling point, the client program can directly enter the service process, which can effectively reduce the system overhead brought by the thread model. 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 change with the entry and exit of the call point, so as not to destroy the semantics of the original thread model. 2) The synchronous call across the address space can only be realized through the asynchronous function of the upper layer protocol. These costs are not only difficult for programmers, but also bad for error handling.

(4) The Container/Loci concept jointly proposed by the University of Adelaide in Australia and the University of Sydney replaces the traditional thread concept, with Container as the only abstraction representing data storage and Loci as the abstraction of execution. 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.

Contents of the invention

The purpose of the present invention is to propose a more reasonable new operating system, to overcome the obstacles encountered in the development of the current operating system, and to solve the problems caused by the internal defects of the structural model it relies on - the process/thread model. performance, structural flexibility, etc.

The operating system based on the service body/execution flow model of the present invention adopts a service body/execution flow structure, which is composed of two types of mechanisms: service body and execution flow; the operating system is composed of a group of service bodies, and each service body Each has its own server address space, and messages are used between servers to promote communication; the execution flow is a trajectory formed by the physical CPU executing instructions in the instruction execution sequence indicated by the instruction counter, and the execution flow is continuous;

The service body is structured according to the same specification, including function code, data collection, service body address space, several ports and several small ports contained in the port, and the code and data are stored in the service body address space for implementing the operating system Corresponding functional components, the execution flow enters the service body through the small port; other system software and user programs in the system are also loaded into the operating system in the form of the service body;

The ports and portlets of the service body adopt a unified specification design, so as to facilitate the communication between the various service bodies in the support system;

A core service body is set in the system service body, which is used to provide execution flow guidance, service body and execution flow management, message push communication, interruption and exception management, and concurrency control basic services.

The service body in the operating system is functionally divided into three levels: the basic mechanism layer, the service layer, and the operating environment layer. The basic mechanism layer is the basic mechanism for system operation; the service layer is used to provide The main service function of the system; the operating environment layer is used to provide the programming model and operating environment of the user program. The division of the above functional levels is used to guide the designer and implementer of the operating system to divide and design the system function component service body.

In the operating environment layer, a service body simulating the operating environment of other operating systems can also be constructed to guide and add system software or user programs supported by the other operating systems to run in the operating system.

The port of the service body corresponds to a message processing routine, and the set of all message interfaces that the routine can handle constitutes a port interface; the message interface is used to define the specific semantics of the message and the type of interface parameter information and message number.

The port interface of the service body has a unified and standardized definition; the identification of the port interface of the service body consists of three parts: the major version number, the minor version number and the globally unique identifier, wherein the major version number and the minor version number are used to support the version upgrades and compatibility.

The address space of the service body is multi-dimensional, including a basic space and an extended space; the basic space includes two parts: a private segment and a shared segment; the service body can have multiple extended spaces for loading different programs respectively , to implement the semantics of multiple address spaces.

The address space of the service body can realize a single address space management mode, a group single address space management mode or/and a private multiple address space management mode;

The single-address space management mode enables different service bodies to occupy different address spaces in the use of the basic space and the extended space, as if they are allocated in the same address space, thereby simply and directly realizing the single-address space management mode.

The group single-address space management mode divides the service bodies with shared data behavior into a group, and performs space management in a single-address mode within the group. Since the number of servers within a group is limited, it can be implemented on 32-bit architectures.

The private multi-address space management makes the expansion space private to the server, and manages the expansion space in a paging manner. Therefore, the current page can be swapped into the backing store as needed to optimize the use of system memory and increase efficiency. Since a server can have multiple private spaces, the capacity of the managed data can exceed the limitation of the processor word length on the virtual memory space.

The message pushes the communication, and the communication between the communication subjects is realized by directly pushing the message from the address space of the source information subject to the address space of the destination communication subject.

The communication mode of message push communication includes synchronous continuous communication mode, synchronous separation communication mode or/and asynchronous communication mode;

The synchronous continuous communication mode refers to: the synchronous communication message of the source communication subject A is directly pushed into the address space of the destination communication subject B via the communication interface of the destination communication subject B from its own address space, and the message is immediately received by the destination communication subject B. After the processing is completed, immediately send a return message to return to the source communication subject A through the communication interface of the above-mentioned source communication subject A that sends the synchronization message, and continue to execute the task of the source communication subject A;

The synchronous separation communication method refers to: the synchronous communication message of the source communication subject A is directly pushed into the address space of the destination communication subject B from its own address space via the communication interface of the destination communication subject B, and at the same time, the message also indicates the third A communication interface of the communication subject C is used as a response interface. After the destination communication subject B has processed the pushed message, the execution flow will enter the specified third communication subject C through the above response interface; the third communication subject can also is the source communication subject A;

The asynchronous communication method refers to: after the source communication subject A pushes the message into the address space of the destination communication subject B through the communication interface of the destination communication subject B, the execution flow immediately returns to the source communication subject A, and the destination communication subject B will properly Then process the message at the right time.

The advantage of the present invention is that the present invention provides a more reasonable operating system based on the service body/execution flow structure, and its advantages are as follows:

①Obviously improve the operating efficiency, for the service body:

●Using synchronous execution flow as the abstraction of system computing behavior, when applying for services, the execution flow directly brings messages into the destination server space, avoiding the overhead of message copying and queue entry and exit;

●In terms of execution, the execution flow directly activates the small port of the destination service body to enter the service body, avoiding the overhead caused by sleep, wake-up and thread scheduling when using threads (scheduling overhead is very considerable when the number of threads is relatively large ); In terms of context preservation, the activation destination portlet does not need to restore any of its registers, nor does it need to save any registers when the execution flow sends a response message, the whole process only needs to save and restore the system's Preserve register set;

●When the sender of the message uses the synchronization separation mechanism, the entire process and even a register do not need to be saved and restored, and its efficiency is greatly improved compared with inter-process communication. Our prototype system MiniCore performance test also proved this point.

②Reduce the consumption of system resources

In the process/thread model, although a thread is a lightweight scheduling unit, it still occupies considerable system resources, which mainly come from the kernel stack and some resources related to scheduling.

In the server model, since the process/thread abstraction is cancelled, each portlet of the server has its own stack, and the interrupt handling process is simulated as sending a message to the core server. All parts of the system are equal, there is no concept of kernel space, and there is no problem of maintaining kernel stacks, thereby completely eliminating the difficulties faced by the process/thread model.

③Advantages in semantic completeness maintenance and system robustness

In the microkernel model, threads exchange data through message queues. In order to ensure the correctness of the model, a message queue only allows one thread to have the right to receive, and the rest of the threads can only have the right to send. The kernel needs to check and process this during operation to ensure the completeness of semantics.

In the server model, this semantics is naturally established. Because a port corresponds to a message processing routine, only the processing routine can process the message delivered to the port. Therefore, unnecessary inspection overhead is avoided in the service body model, and errors caused by users due to design mistakes are also avoided, and the robustness of the system is enhanced.

④ The real-time performance has been significantly improved

The threads of the existing model can only communicate through shared memory, which has inherent defects in message notification. For processing asynchronous events, the thread model often brings a large processing time delay.

For the service body model, due to the synchronization of the execution flow, the small port is directly activated, so the startup time is very small; when a service body requests services provided by other service bodies, the execution flow directly flows into the destination service body, by setting The small port option can keep the priority of the execution flow unchanged. At this time, requests for high-priority transactions are processed first, avoiding problems such as priority inversion caused by the priority setting of the service body; also because the execution flow directly Entering the service body through a small port is synchronous and reentrant, so when a higher priority event is activated, a corresponding idle small port is activated immediately, and it will not be because the port is processing a low priority event Events cause high-priority events to be delayed. Due to the real-time advantages of the service body, it is very suitable for applications that have strict requirements on real-time performance.

⑤Effectively support distributed processing

In a distributed system based on the process/thread model, process migration is the technique adopted to optimize the use of resources or improve the redundancy of the system. The difficulty of process migration is that the calculation and storage of data in the process/thread model are closely combined and cannot exist independently. Therefore, the process must be completely moved from the source node to the destination node, and the contents of the entire process space must be reconstructed at the destination node. The overhead of the whole process is very large.

The service body/execution flow model separates computing power and data storage capacity, making it easier to implement distributed processing. Since the service body and the execution flow are independent of each other, a service body can exist on multiple nodes at the same time. When the calculation is migrated, the service body is already at the destination node, and all services can be pushed to the new node as long as the corresponding port rights are updated through the object manager. The service body uses the execution flow of the new node to work. At the beginning, remote paging of data may occur. As the service body continues to run, the Cache manager will gradually buffer its working set pages locally, and its operating efficiency will increase. It will soon reach the normal level, thus providing effective support for distributed computing.

⑥Support for persistent storage

In the process/thread model, the lifetime of the process address space and the execution capability of the process are linked together, so the essence of the process address space is temporary, which provides persistent storage, distributed computing and high performance for the system. Reliability poses great difficulties.

In the service body model, the service body is the basic abstraction of data storage, and its existence does not depend on the execution flow. In essence, the service body is persistent. Therefore, implementing persistence is simpler and more efficient.

In addition, the service body model combines single-address space technology with private multi-address space technology to provide efficient implementation support for data sharing and data storage, and can realize data query and update more naturally and effectively. The potential advantages that result from this are enormous. On the basis of the service body model, it is easy to construct a new and efficient database management system service body that is truly integrated with the operating system.

⑦Support for active network

For the process/thread model, it abstracts several virtual CPUs. This abstraction determines that the process as the receiving end of the network can only "pull" data from the network node. For the data "pushed" by the sender, it can only be placed in a buffer first, and then the receiver will read from the buffer. "pull" the data into its own process address space for processing. Therefore, the process/thread model can only realize "push" on the basis of "pull", and cannot fully realize the concept of "push". This implementation method of "pull" as "push" hinders the exertion of the advantages of the active network.

In the service body model, because the port actually represents a processing routine, it has a natural advantage in the processing "push" mechanism, which can completely overcome this defect of the process model. Since the service model is essentially consistent with the idea of the active network in terms of communication mechanism and message processing, the message passing process between the service bodies is actually a "push" process, and the execution flow sends the message directly through the small port. brought into the target service body. Realizing the active network based on the service body can be seen as extending the message delivery method of the service body to the transmission and processing of network packets, so better efficiency and a more natural and harmonious system architecture can be obtained.

⑧Support for the tailorability and openness of the operating system

The service body/execution flow model fundamentally breaks the constraints of the process/thread model, and the good isolation and modular structure characteristics between the various parts of the service body can fully support the tailoring and expansion of the operating system. In particular, there is no core concept in the service body model, and all service bodies are equal. Even the management services provided by the core service body can be replaced and expanded by other service bodies, so it has good flexibility and reconfigurability, and thus has good openness. In addition, the synchronous communication mechanism of the novel service body/execution flow model can fully support the parallel control between clusters, as well as the uniqueness of distributed computing service bodies in distributed environments and transparent communication between networks.

To sum up, the execution flow is the most primitive abstraction of the CPU's computing power. It is like a conveyor belt driven by the CPU and advances along the instruction sequence given by the PC register to form a trajectory of instruction execution. It describes a continuous, real The running process of the physical CPU, from power-on reset to shutdown of the CPU, will not be blocked, suspended and stopped like a virtual CPU, nor will it be bound to a specific address space. When the execution flow flows through a certain When the code sequence of the service body is executed, the program of the service body is executed. When a service body needs to call another service body, the execution flow is directed to the called service body through a message. At this time, the execution flow will cross the address boundary between the two The flow between two service bodies is simple and natural, without switching the physical CPU between two virtual CPUs like thread switching.

The core service body is a key component of the system. It controls and manages the execution flow and the service body through the communication mechanism and concurrent scheduling between the service bodies. It mainly provides communication between the service bodies, management of the service body and the execution flow, interruption and exception, etc. The basic service realizes concurrency control between multiple service bodies. One CPU provides one execution stream, and multiple CPUs provide multiple execution streams. The core server has the ability to identify and schedule single-stream concurrency and multi-stream parallelism, thus effectively supporting parallel and distributed computing.

Since the server model separates the operation model from the storage model and abandons the concept of virtual CPU, synchronous message passing can be used as the communication method between servers, which can effectively improve the efficiency of the system and support the active network. At the same time, from the construction principle This ensures the scalability and maintainability of the system.

Therefore, the service body/execution flow model of the present invention is better than the existing process/execution flow model in terms of real-time performance, multi-processor support, consumption of system resources, maintenance of semantic integrity, support for distributed processing and active networks, etc. The threading model has clear advantages.

Description of drawings

FIG. 1 is a schematic diagram of a process/thread model in the prior art.

FIG. 2 is a schematic diagram of the structure of a single large-kernel operating system in the prior art.

FIG. 3 is a schematic diagram of the structure of a microkernel operating system in the prior art.

Fig. 4 is a schematic diagram of the service body/execution flow structure of the operating system of the present invention.

FIG. 5 is a schematic diagram of the message-driven communication of the operating system of the present invention.

Fig. 6 is a schematic diagram of a synchronous continuous communication mode of message-driven communication in the present invention.

Fig. 7 is a schematic diagram of a synchronous separation communication method of message push communication in the present invention.

FIG. 8 is a schematic diagram of an asynchronous communication method of message-driven communication in the present invention.

Fig. 9 is a schematic diagram of the server port and portlet structure of the operating system of the present invention.

Fig. 10 is a schematic diagram of the multi-dimensional address space of the server in the present invention.

FIG. 11 is a schematic diagram of a single address space management mode of the present invention.

Fig. 12 is a schematic diagram of the group single address space management mode of the present invention.

Fig. 13 is a schematic diagram of the private multi-address space management mode of the present invention.

Fig. 14 is a schematic diagram of the persistence of the file system of the present invention.

FIG. 15 is a schematic diagram of a commit algorithm for file system persistence in the present invention.

Fig. 16 is a schematic diagram of the overall structure of the operating system of the present invention.

Fig. 17 is a schematic diagram of the core service body module and structure of the present invention.

Fig. 18 is a schematic diagram of the structure of the object management service body of the present invention.

FIG. 19 is a schematic diagram of the structure of the virtual memory management subsystem of the present invention.

FIG. 20 is a schematic diagram of management of layered drivers by the I/O management service body of the present invention.

Fig. 21 is a schematic diagram of the working process of the stacked file system of the present invention.

Fig. 22 is a schematic diagram of the structure of the Linux operating environment service body of the present invention.

Detailed ways

The specific implementation examples of the present invention will be described in detail below.

The operating system based on the service body/execution flow model of the present invention adopts the service body/execution flow structure, which is composed of two types of mechanisms: the service body and the execution flow; The address space of the service body, the message is used to promote communication between the service bodies; the execution flow is the track formed by the physical CPU executing instructions along the instruction execution order indicated by the instruction counter, and the execution flow is continuous; the service body is constructed according to the same specification, Including function code, data collection, service body address space, several ports and several small ports contained in the port, the code and data are stored in the service body address space, used to realize the corresponding functional components of the operating system, and the execution flow enters the service through the small port body; other system software and user programs in the system are also loaded on the operating system in the form of a service body; the ports and portlets of the service body adopt a unified specification design to facilitate the communication between various service bodies in the system; system services A core service body is set in the body to provide basic services for execution flow guidance, service body and execution flow management, message push communication, interruption and exception management, and concurrency control.

The present invention is an operating system comprehensively composed of the service body/execution flow structure shown in FIG. 4 as the basic structure, message-driven communication as the key technology, and a series of related specific construction methods as auxiliary methods.

Specifically, the service body in the operating system based on the service body/execution flow model of the present invention has static and persistent properties, and it has its own address space. Only when the execution flow is introduced into the service body through a port, the service body The program is executed, and the service body has a communication function. It communicates with other service bodies through message promotion; each port of the service body corresponds to a message processing routine, and the port is the only communication between the service body and the outside world. Legal exit/entry. Therefore, the service bodies are mutually isolated and low-coupling; a port can include several portlets, and the portlets provide the corresponding message routine runtime stack and record the context-related information required at runtime. The number of small ports determines the concurrency of the server; the ports of the server are reentrant, thus allowing high priority messages to be processed immediately.

The execution flow in the operating system based on the service body/execution flow model of the present invention is continuous, and will not be blocked, suspended or terminated from the power-on reset to the shutdown of the machine, and will not be bound to a specific address space. The execution flow enters the service body through a small port of the service body, and executes the corresponding program of the service body. When a service body needs to call the program of another service body, the execution flow is pushed into the called service body through a message, and at this time, the execution flow flows into the called service body across the address space boundary.

The core service body in the operating system based on the service body/execution flow model of the present invention is logically equivalent to the kernel of the microkernel operating system, and the status of the core service body and other service bodies is equal, so there is no concept of kernel state .

The message push communication in the operating system based on the service body/execution flow model of the present invention refers to the method of directly pushing the message from the address space of the source information subject to the address space communication of the destination communication subject, as shown in FIG. 5 , each The communication subject has its own address space and communication interface, and the communication interface contains the entry of the message processing routine and related information; the communication mode of message-driven communication includes three communication modes: synchronous continuous communication, synchronous separation communication and asynchronous communication;

When constructing the operating system based on the service body/execution flow structure and using the message-driven communication technology, the following specific construction methods need to be provided as auxiliary methods.

A. Service body construction method: Each service body in the system must be constructed in a unified and standardized way. The key to this construction method lies in the standardized design of the communication interface of the service body, as shown in Figure 9, and the specific description is as follows:

The server provides several ports as its communication interface. The port defines the legal entry of the service body, corresponding to the service routine provided by the service body and the corresponding description information;

Each of the above ports contains one or more portlets that record the service routine's runtime stack and other contextual information relevant to its operation. The number of small ports determines the concurrency of the port;

The execution flow can only enter the service body from a small port of the port, and switch the state and resources according to the information in the port and the small port.

B. Multi-dimensional address space construction method: the address space of the service body organized by this method is divided into two parts: basic space and extended space, and the basic space is divided into two parts: private segment and shared segment, as shown in Figure 10; different services The shared segments of the service body do not overlap with each other and are mutually exclusive; the private segment is allocated independently by the owner of the virtual space where it is located; the address space of a service body can have one or more extension spaces, each extension Spaces have unique names. The address space constructed by the above method is multi-dimensional. The present invention uses the above multi-dimensional address space construction method to construct the address spaces of all service bodies in the system.

C. Definition specification of service body port interface: a service body port corresponds to a message processing routine, and the collection of interfaces of all messages that this routine can handle is called port interface. The designer of the operating system must formulate the specification definition of the port interface of the service body to constrain the implementer and user of the service body; each message interface defines the specific semantics of the message and the type of information such as interface parameters and the name of the message (message number ); The port interface of the service body is identified by three parts: the major version number, the minor version number and the universal unique identifier UUID (Universal Unique Identifier). The major and minor version numbers are used to support version upgrades and compatibility, and UUID is globally unique in a distributed system.

D. Communication mechanism between service bodies: messages promote communication. Each service body must use message-driven communication as the basic inter-service communication method. Each service body provides several ports as message-driven communication interfaces, and the execution flow flows with the push of messages.

The message is a collection of typed data with a definite format, consisting of three parts: a message header, a data description area and an online data area, and the size is one physical page. (1) Message header: fixed length, indicating the type of message, the number of data, destination/response port and other information; (2) Data description area: provide a data description entry for each data, and the data description entry uses the type field Indicate the type of data such as normal data, online data, offline data and port authority; (3) online data area: online data is the data stored in the online data area, for online data, offset and storage are used in the data description entry Quantity to indicate the address and size of online data.

The communication methods of message-driven communication include three communication methods: synchronous continuous communication, synchronous separation communication and asynchronous communication;

1) Synchronous continuous communication method, the communication steps are: service body A as the source communication subject directly pushes the synchronous communication message from its own address space to the address space of service body B via the communication interface of service body B as the destination communication subject , the communication message is immediately processed by the corresponding processing program in the server B, and immediately after the processing is completed, a return message is sent to the server A, and is received by the communication interface where the server A sends the aforementioned synchronization message, as shown in Figure 6;

2) Synchronous separation communication method, the communication steps are: in the message sent by the service body A as the source communication subject, in addition to specifying the communication interface of the service body B as the destination communication subject, it is also necessary to specify a communication interface called The communication interface of a server (such as server C) that responds to the port. When service body A pushes the message into the address space of service body B through the specified communication interface of service body B, it will be processed by the corresponding processing program of service body B immediately. After the processing is completed, service body B will pass the specified response port Push the execution flow into a certain service body (such as service body C) to which the response port belongs, as shown in Figure 7;

3) The asynchronous communication method, the communication steps are: after the service body A as the source communication subject pushes the synchronous communication message from its own address space into the address space of the service body B via the communication interface of the service body B as the destination communication subject, Immediately return to server A, and server B will process the aforementioned message at an appropriate time in the future, as shown in Figure 8.

E. Operating system construction framework. When utilizing the method of the present invention to construct the operating system, the operating system must be designed according to the construction framework, and the framework includes the following rules and conventions:

With the service body as the basic unit of the operating system, all operating system functional components, system software and user programs must be added to the system in the form of service bodies;

All services in the operating system must be designed according to a unified service body construction method, a unified address space construction method, and a unified service body port interface specification;

The functional components of the operating system are divided into three levels from the bottom up: the basic mechanism layer, the service layer and the operating environment layer. The basic mechanism layer provides the basic mechanism on which the system operates; the service layer provides the main service functions of the system; the operating environment layer provides the programming model and operating environment of user programs. The division of the above functional levels is used to guide the designers and implementers of the operating system to divide and design the system function components and service bodies;

The system software and user programs directly supported by this operating system are loaded on the operating system in the form of services; the system software and user programs that depend on other operating environments are loaded on the corresponding operating environment.

When the operating system expands its functions, the expanded functions need to be organized into service bodies according to the above-mentioned unified specification and added to the operating system. The basic mechanism layer of the system provides functions such as service body registration/revocation, dynamic loading and online upgrade.

F. Three optional address space management modes:

Single address space management mode. Make the shared segments of the basic space of different service bodies occupy different address spaces, as if allocating in a unified address space, so the single address space management mode can be implemented simply and directly in the operating system based on the service body/execution flow structure , as shown in Figure 11;

Group single address space management mode. Divide the service bodies with data sharing behavior into a group, use single address mode for space management within the group, and use multi-address mode for space management between groups, as shown in Figure 12. The group single-address space management mode can be implemented on a 32-bit CPU computing platform, and can also have the main advantages of the single-address mode, such as supporting the sharing of complex data structures. This approach is especially useful in embedded applications;

Private multi-address space management mode: As shown in Figure 13, this mode manages the private expansion space of the server by paging, and can be exchanged with the backing memory as needed to optimize the use of memory; the address space of a server can have multiple private spaces , so that the capacity of the data it manages can exceed the limit of the processor word length on the virtual memory space. When using this mode, large private data and runtime libraries can be loaded into the extended space, and shared data that is of special significance to efficiency can be loaded into the basic space.

G. Persistence method of the file system: By establishing a shadow area for the file system on the disk, as shown in Figure 14, and providing a strictly consistent submission algorithm, as shown in Figure 15, the persistence of the file system can be realized. Thus laying the foundation for realizing the persistence of the operating system.

Application of the message-driven communication mechanism in the operating system based on the server/execution flow model: The message-driven inter-service communication mechanism uses the server as the communication subject and the port/portlet as the communication interface, providing synchronous, continuous, Synchronous separation and asynchronous communication methods. The execution flow pushes the message from the source service body A to the service body B via the port of the destination service body B, and the message handler entering the port of B processes the message. The service body/execution flow model only provides a message-driven primitive to realize synchronous continuous, synchronous separation and asynchronous communication methods, among which:

Synchronous continuous mode: the source service body only specifies the port of the destination service body in the message, and the message push primitive implicitly generates a response port for the source service body, and the execution flow enters the corresponding port through an idle port of the specified destination port The destination service body, the message processing program of the destination port processes the message, and returns to the source service body from the above-mentioned response port after the message processing is completed.

Synchronous separation method: In the message sent by the source server A, in addition to specifying the port of the destination server B, the port of a certain server needs to be specified as the response port. When server A pushes the message into the address space of server B through the destination port, it will be processed by the corresponding message processing program of server B immediately. After the processing is completed, server B will push the execution flow through the response port specified by the above message Enter the service body to which the response port belongs;

Asynchronous mode: the message is bound to an idle small port of the destination server port, and the small port is hung in the port scheduling queue at the same time, and the execution flow then returns to the source server to continue execution, instead of entering the destination through the small port immediately The service body completes the processing of the message. The core service body processes the bound asynchronous message through the port scheduling mechanism according to its priority.

The application of multi-dimensional address space in the operating system of the server/execution flow structure: the address space of the server adopts the multi-dimensional address space, and a server has only one basic space, but can have one or more extended spaces as needed. Extended space is at the low end of the address space, and base space is at the high end of the address space. The shared segment of the basic space is located at the high end of the basic space and is allocated uniformly as system resources with mutual exclusion. That is to say, if a certain server applies for an address range A of the basic space sharing segment, it is impossible for other servers to apply for an address range overlapping with A from the basic space sharing segment. Different service bodies occupy different address ranges in the use of the basic space sharing segment, which do not overlap each other, just like being allocated in the same address space. The allocation of the private segment of the basic space is completely independent of other service bodies. Each service body can use this address space as needed, and different service bodies are not mutually exclusive.

The feature of mutually exclusive allocation of the shared segment of the basic space makes it easy for the content in the shared segment address space to be mapped to the shared segment address space of another server: because the destination address range must be free. According to this feature, complex data structures (including graphs, trees, linked lists, etc.) and codes (codes can also be understood as a complex data structure) that need to be shared with other service bodies at runtime can be loaded into the basic space sharing segment, and in These data and codes are effectively shared between different service bodies. In message-based inter-server communication, the mapping mechanism can be used to directly map messages or data to the destination server space to reduce message copying and communication overhead.

The application of message interface technology in the operating system based on the service body/execution flow structure: each port of the service body can process several messages, and the message processed by the port can be standardized and defined by using the message interface technology, and the version management of the message interface is used Manage the version upgrade of the server or port.

Use this patent to design and implement an operating system:

a) The overall architecture of the operating system as shown in Figure 16 is divided into three levels: the basic mechanism layer, the service layer and the operating environment layer. in,

The basic mechanism layer provides the basic mechanism on which the system runs, including core service body, object management service body, memory management subsystem, IO management subsystem, capability service body and security service body. The memory management subsystem implements the storage model of the system, providing physical memory management and virtual memory management; the IO management subsystem implements the system driver and device management model, and realizes IO device management and file system management; The global and unified management of various objects and ports; the core service body realizes the underlying system mechanism, and provides the abstraction of the service body/execution flow model, including port scheduling, service body management, message delivery, etc.; System security management.

The service layer provides some basic system service functions, including Cache management service body, file system service body, driver program service body, network service body, network protocol driver service body and GUI service body, etc.

The operating environment layer provides users with a programming model and an operating environment for user programs. Part of it is used to achieve compatibility with binary applications supported by other operating systems, and the other part is used to provide a user programming environment for this operating system.

b) Design of system functional component service body:

The core service body shown in Figure 17 provides the underlying basic control mechanism, such as interrupt/exception management, synchronization mechanism, communication mechanism between service bodies, port management and portlet scheduling, etc. In addition, the core service body manages the service body, so it plays the role of the service body manager. The security control of inter-service communication provided by the core service is the basic mechanism to realize system security, and it is through the inter-service communication mechanism that the unified and mandatory access control of object services is realized.

The object management service body shown in Figure 18 uniformly maintains various objects or ports in the system, such as file objects, memory objects, etc., and provides a unified mechanism to realize service registration, query and other operations. It provides unified object management services for other service bodies, such as creating objects and returning object handles, playing the role of a name server. In the service body model, ports, services and objects are equivalent concepts, and the object management service body is used to uniformly control access to objects. Each service body provides several services, and each service is equivalent to an object, and the service body provides external services through the port corresponding to the service. The object management service body manages all objects uniformly and organizes them into a tree structure. The object manager finds the accessed object by searching the above tree structure.

The memory management subsystem consists of two parts: the physical storage management server and the virtual memory management subsystem.

The physical storage management service body mainly provides services such as allocation, recycling, and query of physical pages. The service body reserves a space of corresponding size in the shared segment of the basic space to map all the allocatable physical memory for use by the service body. At the same time, the free physical memory is organized into different free linked lists according to its storage size to support efficient query services.

The virtual memory management subsystem includes virtual memory management service body, Pager service body and Memory service body, and defines four objects related to virtual memory management: the space object represents the virtual memory space of the service body; the pager object is responsible for data management; The memory object provides different views of the pager object according to the user's access rights; the cache object buffers the data in the pager object. The relationship between these four objects is shown in Figure 19.

The Pager service body is responsible for the management of page data, including: calling a page, writing back and removing a page from the cache object, writing back modified page data, and setting and modifying page permissions.

The Memory service body is responsible for the management of the memory object, including: permission checking, determining the pager object associated with the memory object, setting the memory view according to the permission, and providing the following four services for basic space sharing: ①Map a memory object to In the shared section; ②Provide shared services of memory objects according to permissions; ③Allocate and ④Release the reserved space of the service body.

The virtual memory management service body VMSB mainly manages cache objects and space objects. Based on the services provided by the physical memory management service body, the service body provides virtual memory services such as mapping, buffering, and sharing for the interaction between the memory object and the pager object.

I/O management service body: realize the functions of management and coordination among various devices and drivers. Provides a unified basic mechanism for file systems and drivers to support various file systems, thereby simplifying the design of file systems, and provides a fairly flexible driver model for stackable file systems and layered drivers. strong support. The IO management server uses device objects and driver objects to represent all devices and drivers in the system. The hierarchical driver structure diagram and the stackable file system structure diagram supported by the IO management service body are shown in Figures 20 and 21 respectively.

Cache management service body: In order to improve the efficiency of IO, the Cache management service body is provided separately in the system. It cooperates with the IO management service body, memory management service body and object management service body to provide IO requests for various file systems and drivers. Provide a unified caching mechanism.

File system service body: implement various specific file system drivers, such as FAT, EXT2, NTFS, etc. And a filesystem that supports persistent storage can be implemented if desired.

The Linux operating environment service body as shown in Figure 22 provides a Linux operating environment for user programs, provides users with the same programming model as Linux, and at the same time realizes binary compatibility of Linux applications, and can reuse existing Linux applications. There is investment. The Linux operating environment uses ports to realize Linux process/thread abstraction and capture system calls of Linux applications, and utilizes the expansion space of the service body to realize the Linux process address space.

Service body operating environment: provide a set of norms, standards and programming environment for users to implement their own service body (user service body), which is also a standard method for designing user programs in the service body/execution flow model, written in this way The user program can give full play to the advantages of the service body/execution flow model to achieve the best efficiency.

Claims (8)

1. An operating system based on a servant/execution flow architecture, characterized by: the operating system adopts a server/execution flow structure, and the structure consists of two mechanisms of a server and an execution flow; the operating system consists of a group of service bodies, each service body has a service body address space, and the service bodies adopt message to promote communication; the execution flow is a track formed by the execution of the instructions by the physical CPU along the instruction execution sequence indicated by the instruction counter, and the execution flow dynamically and continuously flows among the service bodies;

the server is constructed according to the same specification and comprises a function code, a data set, a server address space, a plurality of ports and a plurality of small ports contained in the ports, wherein the code and the data are stored in the server address space and are used for realizing corresponding function components of an operating system and executing flow entering the server through the small ports; other system software and user programs in the system are also loaded on the operating system in the form of a service body;

the ports and the small ports of the service bodies are designed in a unified specification so as to support the communication among the service bodies in the system;

the method comprises the steps that a core service body is arranged in the service body and used for providing basic services of execution flow guidance, service body and execution flow management, message push communication, interruption and exception management and concurrency control, and interaction among the service bodies is realized in a message push communication mode through the core service body;

according to the functions and the functions of the service body, the operating system is divided into three levels from bottom to top, namely a basic mechanism layer, a service layer and a running environment layer, wherein the basic mechanism layer is a basic mechanism for system running; the service layer is used for providing main service functions of the system; and the running environment layer is used for providing a programming model and a running environment of the user program.

2. The operating system of claim 1, wherein: in the operating environment layer, a service body simulating the operating environment of other operating systems can be further constructed, so that system software or user programs supported by the other operating systems are guided and added to the operating system to run.

3. The operating system of claim 1, wherein a port of the service corresponds to a message handling routine, the set of all message interfaces that the routine can handle constituting a port interface; the message interface is used for defining the type and the message number of the specific semantic and interface parameter information of the message.

4. The operating system of claim 3, wherein: the port interface of the service body has the definition of uniform specification; the identification of the port interface of the service body consists of a major version number, a minor version number and a globally unique identifier, wherein the major version number and the minor version number are used for supporting version upgrading and compatibility.

5. The operating system of claim 1, wherein the server address space is multidimensional and comprises a base space and an extension space;

the basic space comprises two parts, namely a private section and a shared section;

the service body can have a plurality of extension spaces for respectively loading different programs so as to realize the semantics of the multi-address space.

6. The operating system of claim 5, wherein said server address space is capable of single address space management mode, group single address space management mode, or/and private multiple address space management mode;

the single address space management mode enables different service bodies to respectively occupy different address spaces in the use of the basic space and the expansion space, and realizes the use distribution in the same address space;

the grouped single address space management mode divides service bodies with shared data behaviors into a group, and performs space management in the group according to the single address mode;

the private multi-address space management enables the expansion space to be private to the service body, and manages the expansion space in a paging mode.

7. The operating system of claim 1, wherein: the message push communication realizes communication between communication bodies by pushing a message from an address space of a source information body directly into an address space of a destination communication body.

8. The operating system of claim 1 or 7, wherein: the communication mode of the message push communication comprises a synchronous continuous communication mode, a synchronous separation communication mode or/and an asynchronous communication mode;

the synchronous continuous communication mode is as follows: the synchronous communication message of the source communication agent A is directly pushed into the address space of the destination communication agent B from the address space of the source communication agent A through the communication interface of the destination communication agent B, the message is immediately processed by a corresponding processing routine in the destination communication agent B, a return message is immediately sent to the source communication agent A through the communication interface of the source communication agent A for sending the synchronous message after the processing is finished, and the task of the source communication agent A is continuously executed;

the synchronous separation communication mode is as follows: the synchronous communication message of the source communication agent A is directly pushed into the address space of the target communication agent B from the address space of the source communication agent A through the communication interface of the target communication agent B, meanwhile, one communication interface of the third communication agent C is indicated in the message as a response interface, and after the target communication agent B processes the pushed message, the execution flow enters the indicated third communication agent C through the response interface; the third communication agent may also be a source communication agent a;

the asynchronous communication mode is as follows: after the source communication agent a pushes the message into the address space of the destination communication agent B via the communication interface of the destination communication agent B, the execution flow immediately returns to the source communication agent a, and the destination communication agent B will process the message again at an appropriate timing later.

Images