Multi-container priority distribution method under embedded operating system

Abstract

The invention relates to a multi-container priority distribution method under an embedded operating system, and belongs to the technical field of embedding. According to the method, a container priority distribution manager which is at the same level as an original task priority scheduling manager of the embedded real-time system is introduced, the priority is divided into N levels (0-N-1), each level maps M priorities in original 0-255, and M is equal to 256 / N. A running state, a ready state and a blocking state are introduced, and a ready chain table with the container nodes as basic management units is used for storing all the ready container nodes; and the blocking linked list taking the container nodes as basic management units is used for storing all blocked container nodes. According to the invention, the priorities of the tasks in the containers are mapped to the containers through the container priority distribution manager, and are uniformly managed by the system priority scheduler. According to the method, the real-time performance of the container task is ensured by an optimization-level scheduling method.

Description

Technical Field

[0001] This invention belongs to the field of embedded technology, specifically relating to a method for prioritizing multiple containers under an embedded operating system. Background Technology

[0002] With the rapid development of industrial automation, the Internet of Things, cloud computing, and other fields, the demand for real-time performance and flexibility is increasing, and container technology for real-time systems has gradually gained attention. Real-time operating systems combined with container technology provide highly flexible and scalable solutions that better meet the needs of these industries for rapid response, high reliability, and convenient application deployment and management. Therefore, real-time container technology can provide the necessary performance support for intelligent edge applications. It enables systems to evolve from hardware-based solutions to software-defined infrastructure, allowing for rapid updates and patching, effectively addressing cybersecurity threats, and facilitating the integration of new technologies into the system after deployment without requiring extensive hardware replacement.

[0003] Container technology is a lightweight virtualization technology that provides a lightweight isolated environment for software development, deployment, and operation. Real-time operating system containers can provide an isolated runtime environment for each container, achieving isolation in areas such as memory space, file system, private devices, environment variables, and IPC communication. This enhances the security of applications within containers and also enables quota management of operating system resources, effectively blocking unauthorized operations and preventing excessive use of kernel resources, thus ensuring system security and reliability. This is particularly important for fields with high security requirements, such as aerospace, automotive, and energy.

[0004] Real-time containers have robust resource isolation and limitation capabilities, which can prevent application errors from affecting the operating system and other applications. Through quota management of system resources within the container, system integration can be better achieved.

[0005] However, currently valid Chinese patents such as "CN109992415B A container scheduling method and scheduling system", "CN116661972B A container scheduling method, device and storage medium", and "CN110502311B Container scheduling method, device, electronic device and readable storage medium" are all applicable to general cloud platforms and are not applicable to real-time containers under the embedded operating system in this invention. Summary of the Invention

[0006] (a) Technical problems to be solved The technical problem to be solved by this invention is how to provide a method for prioritizing multiple containers under an embedded operating system, so as to solve the problem of real-time container priority allocation under an embedded operating system.

[0007] (II) Technical Solution To solve the above technical problems, the present invention proposes a method for multi-container priority allocation under an embedded operating system, which includes the following steps: S101. The system starts relevant services; S102. Traverse the ready containers and add them to the ready list; if a container has not been traversed, by default, the prio_num of the current container node is the priority number n of the container itself, the task ID is empty, and prio_num = n < N < 2M; if prio_num > N in the container, it indicates that the highest-priority task in the container has been mapped. S103. Among the containers in the ready list, compare the container priorities prio_num to find the container node with the smallest prio_num. S104. If the prio_num of the container node with the smallest prio_num is n < N < 2M, execute S105; if the prio_num of the container node with the smallest prio_num is >= 2M > N, then execute step S106. S105. Obtain the highest-priority task in the ready container and map its priority to prio_num. If the task priority is m, then prio_num = min(M * n + m) >= 2M > N. Return to the scheduling manager, and in this container node, record the ID of the highest-priority task and its priority value prio_num, and continue to execute S103. S106. Return the highest-priority task priority value prio_num = min(M * n + m) >= 2M > N; it indicates that all the current ready containers have been traversed, so select the container with the smallest prio_num and execute S07. S107. Determine whether the current mode is a preemption mode. If it is, execute step S108; otherwise, execute step S109. S108. The current is the preemption mode. Compare according to the recorded prio_num and task ID to determine whether it is the interrupted container. If it is, continue to execute from the breakpoint before interruption, exit the preemption mode, and after execution, execute step S110; if it is not the interrupted container, then execute step S109. S109. Enter the corresponding container, find the corresponding task according to the recorded prio_num and task ID, and execute the task. During the execution process, it may be interrupted by a newly ready container / task. After interruption, enter the preemption mode and execute step S111; otherwise, after execution, execute step S110. S110. After the task is completed, return the new highest priority task ID and its priority number prio_num in this container; if there are no ready tasks in the container after execution, switch the container to the blocking list; if it is not in preemptive mode, execute step S102; if it is in preemptive mode, exit preemptive mode, and return to the original task according to the record to continue execution. After execution is completed, proceed to step S110. S111. Enter preemptive mode and record the currently interrupted container and task. If the preemption is for a higher-priority task within the container, execute the higher-priority task directly. Schedule within the container, and after the preempted task is completed, continue executing the original task. Exit preemptive mode and proceed to step S110. If the preemption is for a container with a new ready task, compare the container priorities. If the new container has a lower priority than the current container, ignore it, return, and continue execution. After execution, exit preemptive mode and proceed to step S110. If the new ready container has the same or higher priority than the current container, proceed to step S102.

[0008] (III) Beneficial Effects This invention proposes a multi-container priority allocation method under an embedded operating system, meeting the needs of combining embedded operating systems with container technology. Currently, there is a lack of a unified and publicly available method for container scheduling in embedded operating systems. Furthermore, tasks within a container are opaque to the operating system, and tasks between containers are isolated. This invention provides a new approach for introducing container technology into embedded operating systems. This invention is applicable to real-time containers in embedded operating systems, using an optimized scheduling method to ensure the real-time performance of container tasks. Attached Figure Description

[0009] Figure 1 This is a comparison diagram of the system task scheduling model before and after incorporating the multi-container priority allocation method in this invention; Figure 2 A diagram illustrating the method for allocating container task priorities; Figure 3 Here is a structural diagram of the container node; Figure 4 This is a flowchart illustrating the execution process of the present invention. Detailed Implementation

[0010] To make the objectives, contents, and advantages of the present invention clearer, the specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples.

[0011] The purpose of this invention is to propose a multi-container priority allocation method under an embedded operating system, which simultaneously satisfies all of the following characteristics: 1. Applicable to real-time containers in embedded operating systems; 2. Guaranteeing the real-time performance of container tasks using an optimized scheduling method.

[0012] This invention innovatively proposes a multi-container priority allocation method under an embedded operating system. The core advantage of an embedded real-time operating system is its deterministic real-time response. It employs a strict priority scheduling mechanism, using priority preemptive scheduling to allow high-priority tasks to "jump the queue" for execution, ensuring that tasks are completed within strict time constraints.

[0013] After adding container functionality to embedded real-time operations, containers are essentially control task groups, with each container managing multiple tasks. Tasks within containers are isolated from each other and cannot be directly scheduled. Therefore, this invention introduces a multi-container priority method into the embedded operating system. This method can limit the readiness and blocking of the entire control task group / container, while isolating CPU usage by tasks within different containers and ensuring the real-time performance of the embedded operating system. Figure 1 This is a comparison of the system task scheduling model before and after adding a multi-container priority allocation method.

[0014] To manage container nodes, this invention introduces a container priority allocation manager at the same level as the original task priority scheduler in the embedded real-time system. This manager maps task priorities within containers to the container itself, and these priorities are then uniformly managed by the system priority scheduler. Taking an embedded operating system with 256 (0~255) priority levels (smaller numbers indicate higher priority) as an example, the container priority allocation method is as follows: Figure 2 The structure of a container node is as follows: Figure 3 Priorities are divided into N levels (0 to N-1), each level mapping to M priorities from 0 to 255, where M = 256 / N. Since one principle of priority allocation is that system tasks have higher priority than user tasks, the container's 0th priority is assigned to the operating system's system tasks, and the 1st priority is reserved. Therefore, the highest priority for tasks within a container is 2M. To ensure that the mapped priority value of tasks within a container is greater than the container's priority, 2M > N. Both container and non-container application tasks use priorities from 0 to N-1. Tasks within a container use priorities from 0 to M-1. Each container is designed with: container priority, container ID, mapped priorities of tasks within the container (prio_num), and corresponding task IDs. Therefore, we also need to introduce control task group states similar to thread states for the control task group / container. Running state: A ready control task group node is said to be in the running state if it is scheduled to run on the processor; all tasks managed by a container node can only be in the ready or running state when the control task group is in the running state. Ready state: Excluding the influence of the container on the task, if there are ready tasks in a container node but the processor is occupied by other container nodes and the container has not been restricted from using certain physical resources, then this container node is in the ready state at this time. When the container is in the ready state, the container node will suspend all tasks managed by that node; Blocked state: When all tasks managed by a container node are not in the running state or the ready state (that is, the container currently has no need to use the processor), it will be suspended by the container manager and thus enter the blocked state; The container in the blocked state will suspend all tasks it manages.

[0015] To control the above state transition process, two linked lists need to be introduced into the container structure: (1) A ready linked list with the container node as the basic management unit, used to store all ready container nodes; (2) A blocked linked list with the container node as the basic management unit, used to store all blocked container nodes.

[0016] The specific implementation steps are as Figure 4 , including the following steps: S101. The system starts relevant services.

[0017] S102. Traverse the ready containers and add them to the ready linked list. If the container has not been traversed, by default, the prio_num of the current container node is the priority number n of the container itself, the task ID is empty, and prio_num = n < N < 2M; If prio_num > N in the container, it indicates that the highest-priority task in the container has been mapped.

[0018] S103. For the containers in the ready linked list, compare the container priority prio_num. The smaller the prio_num, the higher the priority, and it is executed first. Find the container node with the smallest prio_num.

[0019] S104. If the prio_num of the container node with the smallest prio_num is prio_num = n < N < 2M, execute S105; If the prio_num of the container node with the smallest prio_num is prio_num > 2M > N, then execute step S106.

[0020] S105. Obtain the highest-priority task in the ready container and map its priority to prio_num. If the task priority is m, then prio_num = min(M * n + m) > 2M > N. Return to the scheduling manager, and in this container node, record the ID of the highest-priority task and its priority value prio_num, and continue to execute S103; S106. Return the priority value of the highest priority task among them, prio_num=min(M*n+m)>2M>N; This indicates that all currently ready containers have been traversed, so select the container with the smallest prio_num (i.e., the highest priority task) and execute S07. S107. Determine whether the current mode is preemptive. If yes, proceed to step S108; otherwise, proceed to step S109. S108. The current mode is preemptive. Compare the recorded prio_num and task ID to see if it is the interrupted container (it may be interrupted by a container of the same priority, but the task priority is lower than the interrupted task). If it is, continue execution from the breakpoint before the interruption and exit preemptive mode. After execution is completed, proceed to step S110; if it is not the interrupted container, proceed to step S109. S109. Enter the corresponding container, find the corresponding task according to the recorded prio_num and task ID, and execute the task. During the execution process, it may be interrupted by a newly ready container / task. After interruption, enter the preemptive mode and execute step S111; otherwise, after the execution is completed, execute step S110.

[0021] S110. After the task is completed, return the new highest priority task ID and its priority number prio_num in this container; if there are no ready tasks in the container after execution, switch the container to the blocking list. If it is not in preemptive mode, proceed to step S102; if it is in preemptive mode, exit preemptive mode, return to the original task according to the record, continue execution, and after completion, proceed to step S110.

[0022] S111. Enter preemptive mode and record the currently interrupted container and task. If the preemption is for a higher-priority task within the current container, execute the higher-priority task directly. Schedule within the container, and after the preempted task is executed, continue executing the original task, exit preemptive mode, and proceed to step S110. If the preemption is for a container with a new ready task, compare the container priorities. If the priority is lower than the current container priority, ignore it, return, and continue execution (according to this mapping algorithm, the highest priority task in a lower-priority container is still lower than the lowest priority task in a higher-priority container. For example, in a container with priority n, the task priority range is (M*n ~ M*n+M-1), and in a container with priority n+1, the task priority range is (M*(n+1) ~ M*(n+1)+M-1), where M*n+M-1 < M*(n+1)). After execution, exit preemptive mode and proceed to step S110. If the new ready container has the same or higher priority than the current container, proceed to step S102.

[0023] This invention proposes a multi-container priority allocation method under an embedded operating system. Based on the real-time characteristics of the embedded operating system, in order to ensure the real-time performance of high-priority tasks, a container priority allocation manager is introduced into the system to map the task priorities within the container to the container, and the system priority scheduler manages them uniformly.

[0024] This invention proposes a multi-container priority allocation method under an embedded operating system, primarily addressing the need for integrating embedded operating systems with container technology. Currently, there is a lack of a unified and publicly available method for container scheduling in embedded operating systems. Furthermore, tasks within a container are opaque to the operating system, and tasks between containers are isolated. This invention provides a solution for introducing container technology into embedded operating systems. This invention is applicable to real-time containers in embedded operating systems, using an optimized scheduling method to ensure the real-time performance of container tasks. The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for assigning priorities to multiple containers under an embedded operating system, the method comprising: The method comprises the following steps: ​ S101, the system starts the related service; S102, the ready container is traversed, and is added into a ready linked list; if the container is not traversed, the prio_num of the current container node is the priority number n of the container itself, the task ID is empty, and the prio_num=n S103, the container in the ready linked list is compared in priority prio_num, and the container node with the minimum prio_num is found; S104, if the prio_num of the container node with the minimum prio_num is n S105, the highest priority task in the ready container is acquired, and the priority of the highest priority task is mapped as prio_num, the task priority is m, the prio_num is min(M*n+m) >=2M>N, the scheduling manager is returned, the highest priority task ID and the priority value prio_num of the highest priority task are recorded in the container node, and the step S103 is continuously executed; S106, the priority value prio_num of the highest priority task is returned, the prio_num is min(M*n+m) >=2M>N, the ready container is fully traversed, the container with the minimum prio_num is selected, and the step S07 is executed; S107, whether the current is a preemption mode is judged, if yes, the step S108 is executed; otherwise, the step S109 is executed; S108, the current is the preemption mode, whether the container is interrupted is compared according to the recorded prio_num and task ID, if yes, the execution before the interruption is continuously executed, the preemption mode is exited, and the step S110 is executed after the execution is completed; if not, the step S109 is executed; S109, the corresponding container is entered, the corresponding task is found according to the recorded prio_num and task ID, the task is executed, and the execution process can be interrupted by a new ready container / task, after the interruption, the preemption mode is entered, and the step S111 is executed; otherwise, the step S110 is executed after the execution is completed; S110, after the task is executed, the new highest priority task ID and the priority number prio_num of the container are returned; if there is no ready task in the container after the execution, the container is switched to a blocking linked list; if the preemption mode is not executed, the step S102 is executed; if the preemption mode is executed, the preemption mode is exited, the original executed task is returned according to the record, the execution is continuously executed, and the step S110 is entered after the execution is completed; S111, enter preemption mode, record the current interrupted container and task; if it is preempted by a higher priority task in the container, directly execute the higher priority task, schedule in the container, continue to execute the original task after executing the preempted task, exit the preemption mode, and enter step S110; if it is a container with a new ready task, compare the container priority, if it is lower than the current container priority, it can be ignored, return, continue to execute, and after execution, exit the preemption mode and execute step S110; if the new ready container is the same level or higher than the current container priority, enter step S102.

2. The method of claim 1, wherein the priority of the container is determined based on at least one of a type of the container, a type of the process, a type of the file, a type of the user, and a type of the application. In order to manage the container node, a container priority allocation manager is introduced which is at the same level as the original task priority scheduling manager of the embedded real-time system.

3. The method of claim 2, wherein the priority of the container is determined by the embedded operating system. The priority is divided into N levels (0~N-1), and each level maps M priorities in the original 0~255, M=256 / N.

4. The method of claim 3, wherein the priority of the container is determined by the embedded operating system. The system task priority is higher than the user task, the 0th priority is allocated to the system task of the operating system, and the 1st priority is reserved; the highest priority of the task in the container is 2M.

5. The method of claim 4, wherein the priority of the container is determined by the embedded operating system. In order to ensure that the mapped value of the task priority in the container is greater than the container priority, it is necessary to meet 2M>N.

6. The method of claim 3, wherein the priority of the container is determined by the embedded operating system. The application tasks of the container and non-container use 0~N-1 priority, and the tasks in the container use 0~M-1 priority.

7. The method of claim 3, wherein the priority of the container is determined by the embedded operating system. Each container is designed with: container priority, container ID, mapped priority prio_num of the task in the container, and corresponding task ID.

8. The method of claim 3, wherein the priority of the container is determined by the embedded operating system. The highest priority task in the container with low priority is still lower than the lowest priority task in the higher level container.

9. The method of claim 3, wherein the priority of the container is determined by the embedded operating system. The state of the container includes: Running state: if the ready control task group node is scheduled into the processor for running, it is called running state; all tasks managed by the container node can only be in the task ready state or running state when the control task group is in the running state; Ready state: excluding the influence of the container on the task, there is a ready task in the container node, but the processor is occupied by other container nodes, and the container has not been limited to use a certain physical resource, then the container node is in the ready state at this time; when the container is in the ready state, the container node will suspend all tasks managed by the node; Blocked state: when all tasks managed by a container node are not in the running state or ready state, the container node will be suspended by the container manager, and enter the blocked state; the container in the blocked state will suspend all tasks managed by it.

10. The method of claim 3, wherein the method is performed in an embedded operating system. A ready linked list is established with the container node as the basic management unit, which is used to store all ready container nodes; a blocked linked list is established with the container node as the basic management unit, which is used to store all blocked container nodes.

Images