Serial intelligent scheduling method in multitask producer environment

Abstract

The application relates to a serial intelligent scheduling method in a multitask producer environment, and belongs to the technical field of embedded special equipment. The method learns the design idea of a state machine processing mode, and utilizes the state machine to process each single task. In order to save the context of the multitask, a general state machine is designed in structure and logic, but can be customized according to the specific interactive process of each type of task and the data required in the middle. The method can realize intelligent task scheduling of multitask parallel in a serial (single thread) mode in the multitask producer environment.

Description

Technical Field

[0001] The present invention belongs to the technical field of embedded and special equipment, and in particular relates to a serial intelligent scheduling method in a multi-tasking producer environment. Background Art

[0002] In the embedded and specialized equipment sector, a device is often designed to include multiple processing nodes. Each processing node, which may be a microcontroller or other chip, possesses independent computing capabilities, its own hardware and software environment, and operating system. These nodes are deployed at different locations within the device to perform distinct functions. The actual functionality required of the device is often broken down into several relatively independent yet collaborative functions, each deployed separately on these processing nodes. To facilitate this collaborative work, these processing nodes must be interconnected via physical or logical links, enabling communication and command transmission between them. Furthermore, some processing nodes may receive external communications or control. In scenarios where multiple external or internal objects need to concurrently interact with each processing node, it is crucial to leverage the limited hardware and software resources available on these nodes to effectively support concurrent multitasking. Summary of the Invention

[0003] (1) Technical issues to be resolved

[0004] The technical problems to be solved by the present invention are: 1. To realize a serialized scheduling method capable of supporting parallel multi-tasking; 2. The serialized scheduling method can save multi-task context and provide multi-task scheduling support for multiple interactive steps.

[0005] (2) Technical solution

[0006] In order to solve the above technical problems, the application provides a serial intelligent scheduling method in a multitask producer environment, which learns the design idea of a state machine processing mode and uses the state machine to process each individual task; the state machine saves the context and state data of the current processing task and provides the object of the processing logic in each state, and after receiving an external event, the state machine can perform corresponding processing according to the current state and the data contained in the event itself and be transferred to the next state; the state machine can process multi-step interactions, and there are external event-driven tasks between the steps, and can be customized according to the specific interaction process of each type of task and the data required in the middle, and the context of different tasks is saved in the state machine in the form of internal static data customized according to the task itself, so that the next interaction of the same task can be realized by using the data generated before; each type of task to be completed by a node has a state machine defined separately, and each state machine passively accepts events from the outside, triggers the interaction process steps, completes the state transition, enters the next state, and waits for the event of the next step from the current task or the event of starting a new task.

[0007] In the method, each processing node also designs a master module as an entry point for processing all state machine events, and the master module holds a processing thread when it is idle, waits and receives data or signals from the outside, and makes a judgment according to the source and type information, and further encapsulates the data if necessary, generates events that can be processed by the state machine, and distributes them to the state machine that really needs to process the event; if a new task comes, the master module also generates a new state machine corresponding to the task according to the type of the task, and initializes it appropriately; then, the master module calls the event processing logic of the corresponding state machine, transfers the control right of the processing thread to the state machine, and the state machine executes a step of task interaction according to the received event, and performs corresponding state transition after the interaction is completed; after completing the task interaction and state transition, the state machine returns the control right of the processing thread to the master module, and the master module continues to loop the next event receiving-distribution-execution-returning step after taking back the thread control right; when the task ends, the master module is responsible for the resource cleaning and destruction of the state machine.

[0008] Preferably, all state machines follow the "run-to-completion" principle, that is, the state machine performs corresponding operations and is transferred to the next state according to the state after receiving an event, and cannot be interrupted or receive other events in the processing process; from the outside, the state machine is in a defined state, not in an "intermediate state".

[0009] Preferably, if there is a blocking operation waiting for external IO in the state machine, the state is divided, and the external IO is treated as an event.

[0010] Preferably, the single task interaction and state transition processing procedure takes less than a preset threshold, the state machine cannot actively initiate interaction with the outside, and the interaction with the outside must be after receiving an event and as part of the event processing flow.

[0011] Preferably, a step of a task always starts from receiving a signal or data from other nodes or the outside of a system, that is, an event.

[0012] Preferably, the master module is further provided with an event buffer queue for caching events, the event buffer queue adopts a first-in-first-out form or uses a priority queue to assign a high priority to a preset important event.

[0013] Preferably, in the method, the master module performs caching, distribution of events and transfer-return of thread control right, and the state machine performs processing of actual tasks, so that parallel running of multiple state machines is realized, thereby providing support for parallel multitasking in a serial form.

[0014] Preferably, a plurality of available threads are allocated to the master module according to hardware resource conditions, the master module maintains the threads as a thread pool, takes out a thread from the thread pool to assign to the state machine for event processing whenever a new event is received, and puts the thread back into the thread pool after the state machine completes processing and returns the thread.

[0015] The application further provides a system for implementing the method.

[0016] The application further provides an application of the method in the field of embedded and special equipment technology.

[0017] (III) Advantages

[0018] The application provides a serial intelligent scheduling method in a multitasking producer environment, learns the design idea of a state machine processing mode, and uses a state machine to process each single task. In order to save the context of multitasking, a general structure and logic are designed, but a customized state machine can be designed according to the specific interaction flow of each type of task and the data required in the middle. The method can realize intelligent task scheduling of multitasking parallel in a serial (single thread) manner in a multitasking producer environment. BRIEF DESCRIPTION OF DRAWINGS

[0019] Figure 1 The figure is a flowchart of the method of the application. DETAILED DESCRIPTION

[0020] In order to make the purpose, content and advantages of the application clearer, the specific implementation of the application is described in further detail below in combination with the drawings and examples.

[0021] Unlike traditional desktop or server computers, in the field of embedded, special equipment, the hardware resources of processing nodes, especially the number of CPU cores and memory capacity, are extremely limited, and some nodes, such as nodes implemented by single-chip microcomputers, are naturally difficult to support multi-threading, so when the node needs to interact with other multiple nodes or external objects, that is, in a multi-task scenario, it is difficult to use the traditional mode of "one thread responsible for one task", and a serialized scheduling method is needed to support parallel multi-tasking. At the same time, considering that some tasks may also have multiple interaction steps, after the previous step is completed, the next step of interaction may need to wait for the response of other objects before starting, so the context of the task needs to be saved for use, which further increases the complexity of the system. Therefore, the present application is aimed at this scenario. An intelligent task scheduling method for realizing multi-task parallelism in a serialized (single-threaded) manner in a multi-task producer environment is proposed.

[0022] The serial intelligent scheduling method in a multi-task producer environment provided by the present application learns the design idea of state machine processing mode and uses a state machine to process each individual task. The state machine essentially saves the context and state data of the current processing task, and provides processing logic in each state. After receiving an external event, the state machine can perform corresponding processing according to the current state and the data contained in the event, and transition to the next state. Therefore, these characteristics of the state machine are naturally suitable for processing multi-step interactions, and there are external event-driven tasks between steps. In order to save the context of multi-task, a general structure and logic are designed, but the state machine can also be customized according to the specific interaction process of each type of task and the data needed to be used in the middle. The context of different tasks is saved in the state machine in the form of internal static data customized according to the task itself, so the next interaction of the same task can use the data generated before. Each type of task that the node needs to complete has a state machine defined separately, and each state machine passively accepts events from the outside, triggers the interaction process steps, completes state transition, enters the next state, and waits for the event from the next step of the current task or the event of starting a new task.

[0023] All state machines adhere to the "run-to-completion" principle. This means that upon receiving an event, the state machine must execute the corresponding actions based on its state and transition to the next state. It cannot be interrupted during processing and cannot receive other events. Therefore, from an external perspective, the state machine must be in a defined state, not an intermediate state. Furthermore, the state machine that handles each type of event should be well designed, and blocking operations such as waiting for external I / O should not be performed within the state machine. If such operations are required, the states should be segmented and external I / O handled as events. Furthermore, the processing time for a single task interaction and state transition should not be excessive, lest other events be delayed. Furthermore, the state machine cannot actively initiate external interactions; any external interactions must occur after receiving an event and as part of the event processing flow. Because a task step always begins with the receipt of a signal or data—an event—from another node or external to the system, this design simplifies the design and avoids many issues that can arise in complex systems.

[0024] In this method, each processing node also requires a master control module, which serves as the entry point for all state machine event processing. When idle, this master control module hosts the processing thread, waiting for and receiving external data or signals. It then makes decisions based on information such as their source and type. If necessary, it further encapsulates the data, generates events that the state machine can handle, and distributes them to the state machine that actually needs to handle the event. If a new task arrives, the master control module also generates a new state machine to handle the task based on its task type and initializes it appropriately. The master control module then invokes the event processing logic of the corresponding state machine, transfers control of the processing thread to the state machine, and the state machine executes a task interaction based on the received event and performs the corresponding state transition after the interaction is complete. After completing this task interaction and state transition, the state machine returns control of the processing thread to the master control module. After regaining control of the thread, the master control module continues the cycle of receiving, distributing, executing, and returning events. When a task completes (either through completion or abnormal termination), the master control module is also responsible for cleaning up and destroying the state machine's resources. The master control module also requires an event buffer queue to address the problem of nodes struggling to keep up with the rapid arrival of external events. This buffer queue typically uses a simple first-in, first-out (FIFO) approach. Alternatively, a priority queue can be used to assign high priority to important events to ensure they are processed first.

[0025] The main control module caches and distributes events and handles the transfer and return of thread control rights. The state machine processes the actual tasks, which can achieve parallel operation of multiple state machines on a macro level, thereby providing support for parallel multi-tasking in a serial form. The overall processing flow of this method is as follows Figure 1 shown.

[0026] The above discussion describes a fully serial scheduling method for a strictly single-threaded scenario. This method can be easily extended for scenarios with less stringent thread constraints: Based on the actual hardware resources, the master control module allocates a number of available threads. The master control module maintains these threads as a thread pool. Whenever a new event is received, a thread is taken from the thread pool and assigned to the state machine for event processing. After the state machine completes processing and returns the thread, the thread is returned to the thread pool.

[0027] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the technical principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A serial intelligent scheduling method in a multi-tasking producer environment, characterized in that: This method learns the design concept of the state machine processing mode and uses the state machine to process each individual task; the state machine saves the context and state data of the current processing task, and provides the object of the processing logic in each state. After receiving an external event, the state machine can perform corresponding processing based on the current state and the data contained in the event itself, and switch to the next state; the state machine can handle multi-step interactions, and there are tasks driven by external events between the steps, and can be customized according to the specific interaction process of each type of task and the data required in the middle. The context of different tasks is saved in the state machine in the form of internal static data customized according to the task itself, so the next interaction of the same task can be implemented using the data generated previously; Each type of task that a node needs to complete has a separately defined state machine. Each state machine passively accepts events from the outside, triggers interactive process steps, completes state transitions, enters the next state, and waits for events from the next step of the current task or events that start a new task. In this method, each processing node also designs a main control module as the entry point for all state machine event processing. This main control module holds the processing thread when idle, waiting for and receiving data or signals from the outside, and making judgments based on their source and type information. If necessary, it further encapsulates the data, generates events that can be processed by the state machine, and distributes them to the state machine that actually needs to handle this event. If a new task arrives, the main control module also generates a new state machine corresponding to the task type to handle this task and initializes it appropriately. Subsequently, the main control module calls the event processing logic of the corresponding state machine and transfers the control of the processing thread to the state machine. The state machine performs a task interaction according to the received event and performs the corresponding state transition after the interaction is completed. After completing this task interaction and state transition, the state machine returns the control of the processing thread to the main control module. After taking back the control of the thread, the main control module continues to loop and execute the next event reception-distribution-execution-return steps. When the task is completed, the main control module is responsible for the resource cleanup and destruction of the state machine.

2. The method according to claim 1, wherein All state machines follow the "run to completion" principle, that is, after receiving an event, the state machine performs the corresponding operation based on the state and transitions to the next state. It cannot be interrupted during the processing process and does not receive other events. From the outside, the state machine is in a defined state, not an "intermediate state".

3. The method according to claim 2, wherein If there is a blocking operation waiting for external IO inside the state machine, the state will be split and the external IO will be processed as an event.

4. The method according to claim 3, wherein The processing time of a single task interaction and state transition is less than the preset threshold. The state machine cannot actively initiate interaction with the outside world. Interaction with the outside world must exist after receiving an event as part of the event processing process.

5. The method according to claim 1, wherein A step of a task always starts with receiving a signal or data, that is, an event, from other nodes or outside the system.

6. The method according to claim 1, wherein The main control module is further provided with an event buffer queue for caching events. The event buffer queue adopts a first-in-first-out form, or uses a priority queue to assign high priority to preset important events.

7. The method according to claim 6, wherein In this method, the main control module caches and distributes events and handles the transfer and return of thread control rights. The state machine processes the actual tasks, enabling the parallel operation of multiple state machines, thereby providing support for parallel multi-tasking in a serial form.

8. The method according to claim 1, wherein According to the hardware resource situation, several available threads are allocated to the main control module, which is maintained as a thread pool. Whenever a new event is received, a thread is taken from the thread pool and assigned to the state machine for event processing. After the state machine completes the processing and returns the thread, it is put back into the thread pool.

9. A system for implementing the method according to any one of claims 1 to 8.

10. Application of the method according to any one of claims 1 to 8 in the field of embedded and special equipment technology.

Images