RU2408062C2 - Method and system for controlling processes in operating system on microkernel - Google Patents

Abstract

FIELD: information technology.

SUBSTANCE: according to the method of controlling processes in an operating system on a microkernel, a descriptor of the next process is received from the scheduler of the current process queue. It is determined whether the process queue is empty. The scheduler determines whether the inner loop of the next process has finished, and if so, the descriptor of the next process moved into the waiting list. If the execution queue is empty, all messages in the system message queue are processed by shifting, and the volume of all counters of connections in the message routing database (MRD) is reduced after completion of the shift cycle. Descriptors of all processes are moved by the scheduler from the waiting queue to the execution queue to prepare the system for the next shifting cycle, otherwise descriptors of the next process are used; the volume of input/output counters of the current process is reduced by the scheduler and the values of volume of these input/output counters is checked. If the value of the counters is less than zero, the volume of the process counters is increased, otherwise the process is shifted from the execution queue to the waiting queue.

EFFECT: higher accuracy of transmitting information.

2 cl, 6 dwg

Description

The invention relates to methods and systems for program control, and in particular to methods and systems for controlling processes in a microkernel operating system, and can be used in robotic systems and navigation systems of robots.

Due to the rapid growth of digital communication networks and the further expansion of the functionality of devices connected to them, the problem arises of allocating device resources and providing access to these resources.

Another modern and rapidly growing direction in the development of information technology is distributed computer and multi-agent computing systems. There are many advantages to using multi-agent systems. One of them is the ability to self-organize and adapt, as well as flexibility.

Many modern multi-agent systems are built on the basis of software libraries that work at the application level or are supported in compilers as a programming paradigm (see, for example, US patents 7228187 and 7275048).

In all these areas, the main problem is the creation of autonomous systems adaptive to a changing environment with effective control over the execution of processes produced by these systems.

Closest to the claimed invention in terms of the system is the operating system M.O.N.S.T.E.R. (see MONSTER: A new behavior-based microkernel for mobile robots. Dirk Spenneberg, Martin Albrecht, Till Backhaus, Robotics Lab, Faculty of Mathematics and Computer Science, University of Bremen. Bibliotheksstr. 1, D-28359 Bremen, Germany (http : /www.informatik.uni-bremen.de/robotik), which uses the concept of shared processes together with the export of resources. This system is selected as a prototype of the claimed invention. The main disadvantage of the prototype is the lack of flexibility when exporting resources and implementing interfaces in the language level, whereby the system cannot be a truly distributed system. the processes in it must be rigidly connected due to predefined interfaces.These drawbacks impair the flexibility, adaptability and self-organization ability of the prototype system.

The task to which the invention is directed is to develop a method and system for controlling processes that would improve the flexibility, adaptability and self-organization ability of a micronuclear operating system.

The problem is solved by creating a process control method in a microkernel operating system, characterized in that

- receive a descriptor (hereinafter referred to as a "descriptor") of the next process for planning from the current process execution queue;

- check if the execution queue is empty;

- check with the help of the scheduler whether the internal cycle of the process is completed, if it is finished, then the process handle is moved to the waiting queue;

- if the execution queue is empty, process by mixing all the messages in the system message queue and reduce (decrement) the volume of all link counters in the message routing database (MRD - Message Routing Database) after the completion of the mixing cycle;

- using the scheduler, they move the descriptors of all processes from the “waiting” queue to the execution queue to prepare the system for the next mixing cycle, otherwise they use the descriptors of the next process in the queue;

- using the scheduler, reduce the volume of I / O (input / output) counters of the current process (process counters) and check the values of the volumes of these I / O counters, while if the values of the counters are less than zero, they increase (increment) the volume of the process counter, in otherwise, they move the process from the execution queue to the wait queue.

For the functioning of the method, it is important that the volume of process counters is increased each time the process receives or sends a message, and at the same time perform the following operations:

- when sending a message is initiated, using the sending procedure they try to get a descriptor of the sending process to prevent the anonymity of the message, if they do not receive this descriptor, they destroy the message, otherwise they send the message, and the procedure receives a list of subscribers from the routing database descriptor messages;

- check the list of subscribers, however, if the list of subscribers is empty, this means that there are no subscribers for this process, and the output counters are reduced by the corresponding amount, as well as the volume of link counts for the descriptor in the message routing database, after why the message is destroyed and the next message in the queue is processed; if the list of subscribers is not empty, the message is duplicated for each subscriber from the list and the number of successful takes is summarized;

- increase the volume of I / O counters for the sending process by the appropriate amount, which is determined from the number of successful attempts, respectively, also increase the volume of reference counters in the MRD.

For the method to function, it is important that the message is duplicated for each subscriber, and a message is generated that needs to be duplicated, and a list of subscribers as parameters, and in response, the number of successful duplication attempts is reported, and the following operations are performed:

- receive a list of subscribers and the message to be sent as parameters and copy the message;

- copy the message into the message queue of the process identified by the subscriber's descriptor, and if the subscriber's descriptor is identified and copying was successful, then increase the volume of the reference count in the list of subscribers for this descriptor and increase the amount of input counters of this process descriptor.

The problem was also solved by creating a process control system in a microkernel operating system containing a mixing layer and a message subsystem, which is formed as a separate subsystem and includes a message routing database (MRD), which is used by the subsystem for message routing, and MRD is organized as an object the database contains two types of tables: the message source table (MRT) and the subscriber table, while the MRD has a system message queue, which receives messages scheniya of processes to forward communications subsystem.

Thus, the technical result is achieved by creating additional attributes in descriptors of the processes being performed, introducing a method for detecting and compiling a list of processes in the operating system, as well as by performing distributed data processing. Distributed data processing is provided by the introduction of the so-called “mixing layer”, which ensures synchronization of all the processes performed. The complete synchronization cycle of all processes is hereinafter referred to as the “mixing cycle”.

For a better understanding of the claimed invention the following is a detailed description with the involvement of graphic materials.

Figure 1. Scheme of additional attributes to the descriptor of the process performed according to the invention.

Figure 2. A step-by-step diagram of a method for controlling processes in a microkernel operating system carried out according to the invention.

Figure 3. A diagram of the step-by-step procedure for increasing the volume of process counters, performed according to the invention.

Figure 4. A structure diagram of a routing database (MRD) of a process according to the invention.

Figure 5. A message flow diagram in a microkernel operating system according to the invention.

6 is a diagram of the step-by-step execution of the message duplication procedure performed according to the invention.

The essence of the invention is as follows. It seems important that each process in the system be separated from other processes to ensure the following characteristics: flexibility, adaptability, fault tolerance and data security, and therefore they should be connected only with associative relations. This means the inadmissibility of direct interactions between processes (direct inter-process communication). After starting, each process is assigned a unique identifier (descriptor) and its description is recorded in the resource description database.

Each process has an entry point into the logical block of the process, and, in the general case, the logical block carries out an infinite closed loop. The scheduler controls the execution of the process, i.e. carries out control, and guarantees one cycle of execution of the logical block for each process in the general mixing cycle. Therefore, the characteristic period (mixing cycle time) in such an operating system is described by the following expression

,

,

where N is the number of processes currently running, t _n is the execution time of the process at number n.

Each process in the system, in addition to the standard process descriptor, has a descriptor of its behavior and collaboration (a descriptor of the group or “social” process behavior). The descriptor of the group behavior of the process can be organized as additional attributes in the standard descriptor, or as a separate unit. Using the descriptor of the group behavior of the process, the scheduler can decide to terminate (destroy) the process if the process behavior becomes “asocial”, i.e. unfavorable in relation to the system. The solution is based on formal parameters that reflect the group connections of the process, and to ensure the operation of this mechanism, input counters are introduced. Group communications are formed in the process of exchanging data between processes and in the absence of communications (messaging) for a particular process, such a process is considered inappropriate to the system and should be terminated. Thus, in each process, it is necessary to implement algorithms to establish and maintain group ("social") relationships. Otherwise, such a process will ultimately be terminated by the scheduler.

As mentioned above, each process should be well separated from the others. Ideally, he should not know anything about other running processes in the system in the initial state of the process when it is loaded for the first time. So the main idea is to make it an anonymous process. Each process has incoming and outgoing information; in the initial state, the process tries to find the resources necessary for work by sending input and output requests to the system. To be independent of the system architecture (such as the file system and file system structure), he needs to know only the description of the required resource. In order to make the mechanism workable, a method for finding resources is also proposed.

To perform the claimed method, use link counters in the process descriptor (Figure 1). The fields that must be added to the process descriptor to provide information for the mixing layers are as follows: the volume of the counter of 1 sent (output) messages increases each time a message has been successfully sent by this process. The volume of the counter 2 received (input) messages increases each time a message has been successfully received by this process; counter 3 sent bytes increases by the number of bytes sent in the message; counter 4 received bytes increases by the number of bytes received in the message; trace 5 of the total run time is a linked list of cycle times for recently executed process cycles.

Consider the step-by-step implementation of the claimed method (Figure 2). First get the handle to the next process from the wait queue (step 1). Check if the execution queue is empty (step 2). Move all processes from the waiting queue to the execution queue (step 3). Move the process to the execution queue (step 4). Check if the execution cycle for the given process is completed (step 5). Reduce the volume of I / O process counters (step 6). Terminate the process (include the process in the queue for termination) (step 7). Check if the I / O process counters are reset (step 8). Move the process from the execution queue to the wait queue (deferred process) (step 9). They process all messages from the message queue in the message subsystem and reduce the volume of all link counters in the MRD (step 10).

As can be seen from the description, during the execution of the method, all processes will be stopped, since the volumes of their I / O counters will be reduced to zero. To avoid termination, the process must constantly increase the volume of its counters. To ensure collaboration, the present invention proposed an indirect procedure for increasing the volume of I / O counters for the process, which is performed as follows (see Figure 3). Receive the descriptor of the sending process (step 11). Verify the sender descriptor is correct (step 12). Destroy the message and exit the procedure (step 13). Get the list of subscribers from the message source table (MRT - Message Routing Table) (step 14). Reduce the counters of sent messages from the sending process (step 15). The message duplication procedure is called (step 16). Increase the volume of output counters of the sending process by an appropriate amount (step 17). Increase the volume of output MRT counters for the descriptor by an appropriate amount (step 18). Reduce the volume of reference counts in the MRT for the descriptor (step 19).

The message subsystem is formed as a separate subsystem of the microkernel operating system and should perform the functions described below. The basis of the message subsystem is the message routing database (MRD) (see Figure 4), which is used by the subsystem to route messages. MRD is organized as an object database and contains two types of tables: table 6 of message sources and table 7 of message recipients. MRD has a system message queue, which receives messages from processes for further forwarding by the message subsystem.

The message flow in the operating system on the microkernel is shown in FIG. 5. Messages from the queue 8 of system messages are processed in each cycle of the mixing layer. When all processes 9 complete the next run cycle (cycle of the mixing layer), the message subsystem processes all messages in queue 8 until the next cycle of mixing.

Parameters for the sending procedure are sent only in the message block. The procedure does not provide a return value.

The duplication procedure consists in receiving a message that needs to be duplicated, and a list of subscribers as parameters, and data on the number of successful duplication attempts are reported. A step-by-step duplication procedure is shown in FIG. 6. Get the next descriptor from the list of subscribers (step 20). Check the user descriptor (step 21). Copy (duplicate) the message into the incoming message queue of the process identified by the descriptor (step 22). Check if the copy was successful (the process is present, but the queue is not formed) (step 24). Next, either reduce the reference counter for the descriptor in the MRT (step 23), and then decrease the reference counter for the messages received from the process descriptor (step 27), or increase the reference counter for the descriptor in the MRT table (step 25), and then increase the volume of the counter received by the descriptor of the message process (step 26).

The main application of the claimed invention can be robotic systems in embedded and navigation systems of robots.

Although the above embodiment of the invention has been set forth to illustrate the present invention, it is clear to those skilled in the art that various modifications, additions and substitutions are possible without departing from the scope and meaning of the present invention disclosed in the attached claims.

Claims (4)

1. A method of controlling processes in an operating system on a microkernel, characterized in that
get the handle to the next process from the scheduler of the current process execution queue;
check if the process execution queue is empty;
using the scheduler, check whether the internal cycle of the next process is completed, and if it is finished, then move the handle of the next process to the wait queue;
if the execution queue is empty, process by mixing all the messages in the system message queue and reduce the volume of all communication counters in the message routing database (MRD) after the completion of the mixing cycle;
using the scheduler, they move the descriptors of all processes from the “waiting” queue to the execution queue to prepare the system for the next mixing cycle, otherwise they use descriptors of the next process in turn;
using the scheduler, they reduce the volume of input / output counters of the current process and check the values of the volumes of these input / output counters, while if the values of the counters are less than zero, they increase the volume of the process counter, otherwise, they move the process from the execution queue to the waiting queue. 2. The method according to claim 1, characterized in that the volume of the process counter is increased each time the process receives or sends a message, while performing the following operations:
when sending a message is initiated, using the sending procedure they try to get a descriptor of the sending process to prevent the anonymity of the message, while if they receive this descriptor, they destroy the message, otherwise they send the message, and the procedure receives a list of subscribers from MRD;
check the list of subscribers, and if the list of subscribers is empty, this means that there are no subscribers for this process, and the output counts are reduced by the corresponding amount, as well as the volume of reference counters for the descriptor in the MRD, after which the message is destroyed and the next message is processed in Queues if the list of subscribers is not empty, the message is duplicated for each subscriber from the list and summarizes the number of successful takes;
increase the volume of input / output counters for the process by an appropriate value, which is determined from the number of successful attempts, respectively, also increase the volume of reference counters in the MRD. 3. The method according to claim 2, characterized in that the message is duplicated for each subscriber, and receive a message that needs to be duplicated, and a list of subscribers as parameters, and send data in response to the number of successful duplication attempts, while performing the following operations:
receive a list of subscribers and a message to be sent as parameters, and copy the message;
copy the message to the message queue of the process identified by the subscriber descriptor, and if the subscriber descriptor is confirmed and the copy was successful, then increase the volume of the reference counter in the subscriber table for this descriptor and increase the amount of input counters of this process descriptor. 4. The control system for the execution of processes in the operating system on the micronucleus, containing a mixing layer and a message subsystem, which is formed as a separate subsystem and includes a message routing database MRD, which is used by the subsystem to route messages, and MRD is organized as an object database and contains two types of tables: the table of message sources MRT and the table of subscribers, while MRD has a system message queue, which receives messages from processes for further and transfer subsystem messages.

Images