Task scheduling method, domain controller and computer program product
By acquiring task data during task scheduling through middleware and allocating it to threads according to task allocation rules, the problem of insufficient fine-grained task scheduling by middleware is solved, thereby improving task execution performance and the running efficiency of business logic modules.
Patent Information
- Application Number
- CN202411182607.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-08-26
- Publication Date
- 2026-03-03
AI Technical Summary
Existing middleware struggles to achieve fine-grained control during task scheduling, resulting in poor task execution performance and inefficient operation of business logic modules.
The middleware obtains task data from the business logic module, determines the tasks to be executed based on the task data, creates threads during process startup, assigns tasks to target threads using task allocation rules, and optimizes the task scheduling process by combining thread binding rules and priority mapping.
It improves task scheduling efficiency and the operational efficiency of business logic modules, and enables fine-grained control over the task scheduling process.
Smart Images
Figure CN121597353A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and more specifically, to a task scheduling method executed by middleware of a target system. Furthermore, this application also relates to a domain controller and a computer program product. Background Technology
[0002] Computer systems, such as those used in autonomous driving systems, often use middleware to internally schedule various business logic modules. For example, middleware might assign multiple tasks provided by a business logic module to multiple threads within a process, which then execute those tasks. The way the middleware schedules these tasks affects their execution performance (e.g., execution speed), which in turn impacts the operational efficiency of the business logic module. Summary of the Invention
[0003] According to one aspect of this application, a task scheduling method executed by middleware of a target system is provided, comprising: acquiring task data sent by a business logic module of the target system; determining multiple tasks to be executed based on the task data; and starting a target process for executing the multiple tasks, wherein, during the startup of the target process, the following steps S1-S2 are performed: S1. creating multiple threads corresponding to the target process; S2. when the task data includes task allocation rules, allocating the target task among the multiple tasks to the target thread among the multiple threads according to the task allocation rules.
[0004] According to another aspect of this application, a domain controller is provided, comprising: a memory configured to store computer-executable instructions; and a processor configured to perform the method provided according to the foregoing aspect of this application when the computer-executable instructions are executed by the processor.
[0005] According to another aspect of this application, a computer program product is provided, including computer-executable instructions, wherein when the computer-executable instructions are executed by a processor, they perform any of the methods provided according to the foregoing aspects of this application.
[0006] According to the task scheduling method provided in this application, task data sent by the business logic module of the target system can be obtained through the middleware of the target system. Based on the task data, multiple tasks to be executed are determined. During the startup of the target process used to execute these multiple tasks, multiple threads corresponding to the target process are created. When the task data includes task allocation rules, the target tasks among the multiple tasks are allocated to the target threads among the multiple threads according to the task allocation rules. This task scheduling method provides the business logic module with a mechanism for fine-grained control over the task scheduling process executed by the middleware, thereby helping to improve task scheduling efficiency and the operational efficiency of the business logic module.
[0007] These and other aspects of this application will be clear from the embodiments described below, and will be elucidated with reference to the embodiments described below. Attached Figure Description
[0008] In the following description of exemplary embodiments in conjunction with the accompanying drawings, further details, features, and advantages of the technical solutions of this application are disclosed, as shown in the drawings:
[0009] Figure 1 The illustration shows a vehicle and its surrounding environment in which the technical solutions provided according to some embodiments of this application can be applied;
[0010] Figure 2 This illustration schematically shows a vehicle system architecture to which the technical solutions provided according to some embodiments of this application can be applied;
[0011] Figure 3 An example flowchart illustrating a task scheduling method according to some embodiments of this application is shown schematically;
[0012] Figures 4A-4B The schematic diagram illustrates example schematics of a task scheduling method according to other embodiments of this application;
[0013] Figures 5A-5B The schematic diagram illustrates example schematics of a task scheduling method according to further embodiments of this application;
[0014] Figure 6 An example flowchart illustrating a task scheduling method according to further embodiments of this application is shown schematically; and
[0015] Figure 7 An example flowchart illustrating a task scheduling method according to yet another embodiment of this application is shown. Detailed Implementation
[0016] Several embodiments of this application will now be described in more detail with reference to the accompanying drawings so that those skilled in the art can implement the technical solutions of this application.
[0017] like Figure 1As shown, various methods provided according to embodiments of this application (see below) can be applied in vehicle 110, which is situated in vehicle environment 100. Vehicle 110 may include various vehicles, such as passenger cars like sedans and SUVs (sports utility vehicles), logistics and freight vehicles like trucks and automated guided vehicles (AGVs), mining and construction vehicles like dump trucks and excavators, etc. Vehicle 110 may also include various aircraft and vessels, such as drones for cargo delivery, agricultural spraying, monitoring, etc., and vessels for recreation or transportation, etc. Accordingly, vehicle environment 100 can be various environments such as urban environments, rural environments, off-road environments, mountain environments, and aerial environments.
[0018] The following is through Figure 2 This describes an exemplary system architecture for a vehicle to which the various methods provided in the embodiments of this application can be applied. For example... Figure 2 As shown, the driving system of vehicle 210 in vehicle environment 200 may include an Autonomous Driving System (ADS) and / or an Advanced Driver Assistance System (ADAS). The corresponding system architecture 220 may include: an application layer 221, a middleware layer 222, a hardware abstraction layer 223, and a hardware layer 224. The application layer 221 includes various algorithm- and model-based applications to achieve functions such as path planning, decision-making, and obstacle detection. These applications utilize… Figure 2 The various business logic modules (perception module, positioning module, human-computer interaction module, control module, prediction module, and decision-making and planning module) are schematically shown; the middleware layer 222, as the core of the driving system, utilizes corresponding middleware to be responsible for data transmission, processing, management, and coordination between different modules, and includes multiple corresponding sub-modules for implementing these functions (e.g., Figure 2 The communication module, scheduling module, and data fusion module are shown in the diagram. The hardware abstraction layer 223 provides an abstraction layer that allows software to communicate with underlying hardware (e.g., various sensors). The hardware layer 224 includes various sensors (e.g., cameras, LiDAR, GPS), actuators (e.g., motors, steering mechanisms), computing platforms (e.g., GPUs, CPUs), etc. The application layer 221 can interact with other layers (e.g., hardware layer 224) through the application programming interface (API) provided by the middleware layer 222.
[0019] Figure 3 An example flowchart of a task scheduling method 300 according to some embodiments of this application is illustrated schematically. The task scheduling method 300 can be implemented in, for example... Figure 2The task scheduling method 300 is executed in the middleware layer 222 of the driving system of the vehicle 210 shown. Specifically, it can be executed by the scheduling module in the middleware (those skilled in the art should understand that the task scheduling method 300 can also be executed by a different module). Figure 2 The driving system shown is executed by other systems, such as middleware responsible for scheduling functions in other systems.
[0020] like Figure 3 As shown, in step 310, task data sent by the business logic module of the target system can be acquired. In some embodiments, the target system is an autonomous driving system of a vehicle, and the business logic module includes at least one of the following modules in the autonomous driving system: a perception module, a decision planning module, a localization module, a control module, a prediction module, and a human-machine interaction module. As an example, the task data acquired in step 310 may include data sent by the perception module of the autonomous driving system; as another example, the task data acquired in step 310 may include data sent by the localization module and the decision planning module of the autonomous driving system.
[0021] It should be noted that various business logic modules in ADS and / or ADAS systems can generate task data. For example, the perception module may include sensors such as cameras, LiDAR, and millimeter-wave radar. These sensors can collect environmental data about the vehicle's environment. The perception module uses appropriate algorithms to perceive the environmental data collected by the sensors. In this case, the environmental data collected by the sensors can serve as the corresponding task data. Similarly, the data required by other business logic modules such as the positioning module, control module, and prediction module to perform their respective tasks also constitutes task data. After acquiring the task data, the business logic modules can send it to the middleware of the target system.
[0022] In step 320, multiple tasks to be executed can be determined based on the task data. For example, after receiving task data sent by the business logic module, the middleware's scheduling module can encapsulate the task data through the middleware to determine the corresponding multiple tasks to be executed. It should be noted that this encapsulation process generally includes encapsulating the task data into multiple tasks (also commonly referred to as "units," "running units," etc.) that can be executed by operating system threads. These tasks may contain specific function pointers, parameters, and required resource descriptors. Depending on the architecture and functional requirements of the target system, the corresponding middleware may use different modules to perform the encapsulation process, such as a task management module, a task scheduler, or a task coordinator.
[0023] In step 330, a target process for executing the multiple tasks can be started, wherein during the startup of the target process, the following steps S1-S2 are performed: S1. Create multiple threads corresponding to the target process (the number of threads created by the process can be configured by the business logic module); S2. When the task data includes task allocation rules, allocate the target task among the multiple tasks to the target thread among the multiple threads according to the task allocation rules.
[0024] For example, task allocation rules can include a correspondence between target tasks and target threads. For instance, task allocation rules can instruct the assignment of one or more of the multiple tasks (i.e., target tasks) to one or more of the multiple threads (i.e., target threads). For example, tasks with higher priority and / or longer runtime can be assigned to a specific thread, while other tasks are assigned to other threads. This allows tasks with higher priority and / or longer runtime to exclusively occupy a thread, thereby improving the execution efficiency of such tasks. For example, task allocation rules can be statically configured by the business logic module in a configuration file (which can have various suitable formats, including but not limited to JSON, YAML, XML, etc.), and then dynamically set by the middleware during the startup of the target process according to the configuration file to achieve the corresponding task allocation and scheduling.
[0025] For example, when the task data does not include task allocation rules, a default allocation algorithm can be used to allocate the multiple tasks (see below for details). Figure 5A (As described in the example), in other words, in this case, the target task may not necessarily be assigned to the target thread. This technique may be particularly advantageous in some situations; for example, it is backward compatible because it does not require modification of the default allocation algorithm. Specifically, when a new version of the middleware is deployed to the target system, if the business logic module does not allocate tasks to specific threads according to the task allocation rules, the middleware of the target system can allocate and schedule tasks according to the default allocation algorithm. That is, the business logic module does not need to make any changes or adaptations, and the previous configurations can continue to be used in the new version of the middleware. At the same time, if the business logic module allocates tasks to specific threads according to the task allocation rules, the middleware can recognize and execute this configuration of the business logic module.
[0026] According to the task scheduling method 300 provided in this application, the middleware of the target system can be used to schedule multiple tasks provided by the business logic module. When the task data sent by the business logic module includes task allocation rules, the target task among the multiple tasks to be executed is allocated to the target thread according to the task allocation rules. This allows the business logic module to influence the task scheduling process of the middleware, which helps to improve task scheduling efficiency and thus helps to improve the running efficiency of the business logic module.
[0027] In some embodiments, the task allocation rule includes multiple correspondences between the multiple tasks and the multiple threads, and wherein allocating a target task among the multiple tasks to a target thread among the multiple threads according to the task allocation rule includes: allocating the target task to the target thread according to the target correspondence among the multiple correspondences. Figures 4A-4B Two examples of the aforementioned multiple correspondences are shown. For example... Figure 4A As shown, exemplarily, the plurality of tasks includes four tasks (Task_1, Task_2, Task_3, and Task_4), and the plurality of threads includes four threads (Thread_1, Thread_2, Thread_3, and Thread_4). A first, second, third, and fourth correspondence exist respectively between Task_1 and Thread_1, between Task_2 and Thread_3, between Task_3 and Thread_4, and between Task_4 and Thread_2 (in...). Figure 4A The middleware uses arrows between threads and tasks to identify their correspondences, allowing it to assign tasks to appropriate threads. The target correspondence can be any one or more of the multiple correspondences, and the target thread can be any one or more of the multiple threads. The target correspondence between the target task and the target thread can be configured by the business logic module. Figure 4A In the example shown, Task_1 is assigned to Thread_1, Task_2 is assigned to Thread_3, Task_3 is assigned to Thread_4, and Task_4 is assigned to Thread_2.
[0028] Figure 4B It shows a difference Figure 4A Another example of the multiple correspondences mentioned above. For example... Figure 4BAs shown, exemplarily, the plurality of tasks includes four tasks (Task_1, Task_2, Task_3, and Task_4), and the plurality of threads includes four threads (Thread_1, Thread_2, Thread_3, and Thread_4). There are first, second, third, and fourth correspondences respectively between Task_1 and Thread_1, between Task_2 and Thread_2, between Task_3 and Thread_2, and between Task_4 and Thread_3 (in...). Figure 4B The middleware uses arrows between threads and tasks to indicate their correspondence, allowing it to assign tasks to the appropriate threads. This demonstrates how... Figure 4B In the example shown, Task_1 is assigned to Thread_1, Task_2 and Task_3 are assigned to Thread_2, Task_4 is assigned to Thread_3, and no task is assigned to Thread_4. Figure 4B The correspondence between these tasks and threads shown is as follows: Figure 4A Not entirely the same, in fact, not limited to Figures 4A-4B As shown in the examples (whether in terms of the number of tasks, the number of threads, or the correspondence between tasks and threads), the business logic module can flexibly set, for example, the number of threads to be created, which tasks should be assigned to which threads, etc., according to actual needs.
[0029] In some embodiments, thread identifiers (IDs) can be used to facilitate the configuration of the mapping between tasks and threads. For example, middleware can read the mapping statically configured by the business logic module in a configuration file using thread IDs. For example, the business logic module can assign one or more tasks (target tasks) from a set of tasks to threads (target threads) with specific IDs (target identifiers), thereby achieving fine-grained control over task allocation. Referring to the example above, higher-priority tasks (e.g., ...) can be assigned to threads with specific IDs (target identifiers). Figure 4A Task_1 shown is assigned to a thread (e.g., Figure 4A As shown in Thread_1), while other tasks (e.g., Figure 4A Task_2, Task_3, and Task_4 shown are assigned to other threads (e.g., Figure 4A The example shows Thread_2, Thread_3, and Thread_4. This is particularly advantageous when the processing core bound to Thread_1 has ample machine resources (e.g., computing resources), because such a more efficient thread can be used to execute the corresponding task (Task_1 in this example).
[0030] Alternatively or additionally, tasks with longer runtimes (e.g., Figure 4B Task_1 and Task_4 shown are assigned to certain threads (e.g., Figure 4B As shown in Thread_1 and Thread_3), other tasks (e.g., Figure 4B Task_2 and Task_3 shown are assigned to other threads (e.g., Figure 4B As shown in Thread_2, this allocation allows longer-running tasks Task_1 and Task_4 to have a dedicated thread (Thread_1 and Thread_3 in this example), thus improving the execution efficiency of Task_1, Task_4, and all tasks overall. It should be noted that although in Figure 4A and Figure 4B Using the same terminology to represent corresponding threads and tasks does not mean that... Figure 4A and Figure 4B The threads and tasks shown must be the same.
[0031] In some embodiments, the task scheduling method 300 further includes: during the startup of the target process, performing the following steps: S3. When the task data does not include task allocation rules or there are still unallocated tasks among the plurality of tasks after the processing of step S2 above, the corresponding tasks among the plurality of tasks are allocated to the corresponding threads among the plurality of threads according to the dependencies between the plurality of tasks and the number of threads created.
[0032] For example, when the task data does not include task allocation rules, the corresponding tasks among the multiple tasks can be allocated to the corresponding threads among the multiple threads based on the dependencies between the multiple tasks and the number of threads created. Figure 5A As shown, suppose there are five tasks to be assigned: Task_1, Task_2, Task_3, Task_4, and Task_5, and these tasks are related as follows: Figure 5A The dependencies shown are: Task_3 depends on Task_1 and Task_2, Task_4 depends on Task_3, and Task_5 depends on Task_4. Since three threads (Thread_1, Thread_2, and Thread_3) have been created, these tasks can be assigned to these threads sequentially. For example, Task_1 can be assigned to Thread_1, Task_2 to Thread_2, Task_3 to Thread_3, Task_4 to Thread_1, and Task_5 to Thread_2.
[0033] Alternatively, if unassigned tasks still exist among the multiple tasks after the processing in step S2 above, the method described above can be used in conjunction with the reference method. Figure 5A The described approach assigns these unassigned tasks to the appropriate threads. For example, assuming the task allocation rule only instructs that Task_1 be assigned to Thread_1 so that Task_1 has exclusive access to Thread_1, then after assigning Task_1 to Thread_1 according to the task allocation rule, other tasks (Task_2, Task_3, Task_4, and Task_5) can be assigned to threads Thread_2 and Thread_3 based on the dependencies between these tasks and the number of threads created (actually the number of available threads in this example). Figure 5A As exemplified, Task_2 is assigned to Thread_2, Task_3 to Thread_3, Task_4 to Thread_2, and Task_5 to Thread_3. Combined with... Figures 5A-5B The examples described herein can provide a flexible way for business logic modules to configure task allocation rules, thereby better addressing various complex real-world application scenarios.
[0034] In some embodiments, the task scheduling method 300 further includes: after allocating the plurality of tasks to the plurality of threads through steps S1-S3, executing the plurality of tasks through the plurality of threads according to a preset task topology relationship, wherein the preset task topology relationship represents a preset association relationship between the plurality of tasks. The following is in conjunction with... Figure 6 This embodiment will be further described below. For example... Figure 6 As shown, in task scheduling method 600, in step 610, task data sent by the business logic module of the target system can be obtained. In step 620, multiple tasks to be executed can be determined based on the task data. For steps 610 and 620, please refer to the descriptions of steps 310 and 320 of task scheduling method 300 above, which will not be repeated here. In step 630, a target process for executing the multiple tasks can be started, wherein steps S1-S3 described above are executed during the startup of the target process.
[0035] After assigning the multiple tasks to the multiple threads through steps S1-S3, in step 640, the multiple tasks can be executed through the multiple threads according to a preset task topology, wherein the preset task topology represents a preset association between the multiple tasks. Depending on the actual application scenario, the preset task topology may include various associations between multiple tasks (including but not limited to serial, parallel, and other dependencies). For example, such task topology can be represented by a Directed Acyclic Graph (DAG).
[0036] According to the task scheduling method 600 provided in this application, when the task data sent by the business logic module of the target system includes task allocation rules, the target task among multiple tasks to be executed can be allocated to the target thread among multiple created threads according to the task allocation rules. By adding task allocation rules to the task data, the business logic module can influence the task allocation process of the middleware. After the multiple tasks are allocated to the multiple threads through the task allocation process, the multiple tasks can be executed efficiently through the multiple threads according to the preset task topology.
[0037] In some embodiments, the task scheduling method 300 further includes: during the startup of the target process, performing the following steps: when the task data includes thread binding rules, binding a target thread among the plurality of threads to a target computing core of the target system according to the thread binding rules. Taking an autonomous driving system as an example, it may include multiple computing cores. Furthermore, regarding the type of computing core to which it is bound, it may be, for example, a CPU core, a GPU core, an FPGA (Field-Programmable Gate Array), an ASIC (Application-Specific Integrated Circuit), etc. In a target system, such as an autonomous driving system, when the middleware schedules tasks, it can bind different threads to corresponding computing cores to execute corresponding tasks according to actual needs; in other words, it assigns tasks to the hardware most suitable for processing that type of task. Figure 5BAs shown in the example, a thread binding rule can instruct that thread Thread_1 (the target thread) be bound to a specific CPU core (the target processing core), while threads Thread_2 and Thread_3 are bound to different CPU cores. As another example, a thread binding rule can instruct how all these threads are bound; for example, binding thread_1 to the first CPU core, thread_2 to the second CPU core, and thread_3 to a GPU core. For business logic modules, thread binding rules can be determined based on various factors, including but not limited to at least one of the following: the type of processing core, the current load on the processing core, the computational requirements of the task, and real-time requirements.
[0038] In some embodiments, the task scheduling method 300 further includes: during the startup of the target process, performing the following steps: when the task data includes thread priorities, mapping the thread priorities to the POSIX thread scheduling standard of the operating system where the target system resides. The business logic module can configure thread priorities, for example, configuring different priorities for multiple created threads. These configured thread priorities will be mapped internally by the middleware to the POSIX thread scheduling standard of the operating system (e.g., Linux, QNX, etc.) where the target system resides. The corresponding mapping formula can be determined and used according to the specific operating system type and the configured thread priorities.
[0039] Taking Linux as the operating system of the target system as an example, at the middleware level, the thread priorities configured in the business logic modules need to be mapped to the Linux thread scheduling standard. Specifically, in Linux systems, thread priorities typically use "nice" values (ranging from -20 to 19, where -20 represents the highest priority and 19 represents the lowest priority) and real-time priorities (ranging from 1 to 99, where 1 represents the lowest real-time priority and 99 represents the highest real-time priority). Accordingly, the priorities configured in the business logic modules need to be converted to the corresponding "nice" values or real-time priorities so that the Linux system can understand them. It should be noted that the priority range configured in the business logic modules can be flexibly set according to actual needs. For example, if the thread priority range configured in the business logic modules is 1 to 14, where 1 represents the highest priority and 14 represents the lowest priority, then an example formula mapping to the Linux POSIX thread scheduling standard is as follows (for simplicity, the use of real-time priorities is omitted here):
[0040] nice_value=(priority-1)*3–20.
[0041] In this formula, "nice_value" represents the "nice" value of the Linux system, which can be calculated from the thread priority configured by the business logic module, represented by "priority". For example, using this formula, the lowest thread priority configured by the business logic module, 14, will be mapped to a "nice" value of 19 (representing the lowest priority), while the highest thread priority configured by the business logic module, 1, will be mapped to a "nice" value of -20 (representing the highest priority). Other thread priorities within the priority range configured by the business logic module (1 to 14 in this example) will also be mapped to the corresponding "nice" values. It should be noted that this formula is merely exemplary. Depending on the thread priority range configured by the business logic module and the specific operating system type, different mapping formulas can be determined to ensure that the thread priorities configured by the business logic module can be correctly converted and applied at the operating system level, thereby optimizing the task allocation and scheduling process and improving the response speed and stability of the target system.
[0042] In addition to the thread binding rules and thread priorities described in the above embodiments, alternatively or additionally, in some embodiments, the business logic module can configure corresponding names for the multiple threads created, giving the threads meaningful names (e.g., a thread's name can be related to the type or function of the task it performs). This facilitates developers in quickly locating the source of problems during debugging and logging. Furthermore, in complex systems, appropriate thread names help in understanding which tasks are being executed and the relationships between them, thereby facilitating troubleshooting and performance analysis.
[0043] Those skilled in the art will understand that, without creating contradiction, one or more features in a disclosed embodiment can be combined with one or more features in other embodiments to obtain new embodiments. For example, Figure 7 The illustration shows an example flowchart of a method for dynamically scheduling multiple tasks that combines features of several embodiments of this application. Figure 7 Steps 710, 720, and 740 shown can be referred to the above text regarding... Figure 6 The descriptions of steps 610, 620, and 640 are not repeated here. Figure 7As shown, in step 730, during the startup of the target process, the following steps are executed: In step 731, it is determined whether the business logic module has configured thread identifiers (i.e., assigning one or more tasks to threads with specific identifiers). If yes, step 733 (i.e., assigning tasks according to the thread identifiers in the task allocation rules) can be executed; if no, step 732 (i.e., assigning tasks using the default allocation algorithm) can be executed. After creating and initializing threads in step 734, in step 735, it is determined whether the business logic module has configured thread details (e.g., thread name, thread binding rules, thread priority, etc.). If yes, step 736 (i.e., considering thread details to perform corresponding processing, for example, binding the corresponding thread to the corresponding computing core according to the thread binding rules) can be executed; if no, no additional processing can be performed.
[0044] This application also provides a domain controller, including: a memory configured to store computer-executable instructions; and a processor configured to perform the various methods provided in the various embodiments described above when the computer-executable instructions are executed by the processor. Exemplarily, a domain controller can be as follows: Figure 2 The hardware devices corresponding to at least a portion of the middleware layer 222 in the illustrated system architecture 220 include processors, memory, and other necessary hardware resources for performing computational tasks in specific functional domains. These functional domains may include, for example, perception, decision planning, and vehicle control.
[0045] This application also provides a computer program product or computer program including computer-executable instructions that can be stored in a computer-readable storage medium. A processor of a computing device can read the computer-executable instructions from the computer-readable storage medium and execute the computer-executable instructions, causing the computing device to perform the various methods provided in the above embodiments. The computer-readable storage medium may be, for example, RAM, ROM, EEPROM, flash memory, CD-ROM, DVD, or other memory.
[0046] By studying the accompanying drawings, the disclosure, and the appended claims, those skilled in the art can understand and implement variations of the disclosed embodiments in practicing the claimed subject matter. In the claims, the word "comprising" does not exclude other elements or steps, and "a" or "an" does not exclude a plurality. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used advantageously.
Claims
1. A task scheduling method executed by middleware of a target system, comprising: Obtain task data sent by the business logic module of the target system; Based on the task data, determine multiple tasks to be executed; A target process for executing the plurality of tasks is started, wherein during the startup of the target process, the following steps S1-S2 are performed: S1. Create multiple threads corresponding to the target process; S2. When the task data includes task allocation rules, the target task among the plurality of tasks is allocated to the target thread among the plurality of threads according to the task allocation rules.
2. The method according to claim 1, wherein the task allocation rule includes multiple correspondences between the plurality of tasks and the plurality of threads, and wherein allocating a target task among the plurality of tasks to a target thread among the plurality of threads according to the task allocation rule includes: Based on the target correspondence among the multiple correspondences, the target task is assigned to the target thread.
3. The method according to claim 2, wherein the target thread has a target identifier, and the target correspondence is used to indicate the correspondence between the target task and the target thread having the target identifier.
4. The method according to claim 1, wherein the task allocation rule is determined by the business logic module based on at least one of the following factors of the plurality of tasks: task priority and task runtime.
5. The method of claim 1, further comprising performing the following steps during the startup of the target process: S3. When the task data does not include task allocation rules or there are still unallocated tasks among the multiple tasks after the processing of step S2, the corresponding tasks among the multiple tasks are allocated to the corresponding threads among the multiple threads according to the dependencies between the multiple tasks and the number of threads created.
6. The method according to claim 5, further comprising: After the multiple tasks are assigned to the multiple threads through steps S1-S3, the multiple tasks are executed through the multiple threads according to a preset task topology relationship, wherein the preset task topology relationship represents a preset association relationship between the multiple tasks.
7. The method according to claim 6, wherein the preset task topology is characterized by a directed acyclic graph (DAG).
8. The method of claim 1, further comprising performing the following steps during the startup of the target process: When the task data includes thread binding rules, the target thread among the multiple threads is bound to the target computing core of the target system according to the thread binding rules.
9. The method of claim 1, further comprising performing the following steps during the startup of the target process: When the task data includes thread priorities, the thread priorities are mapped to the POSIX thread scheduling standard of the operating system where the target system is located.
10. The method of claim 1, wherein the target system is an autonomous driving system for a vehicle, and wherein the business logic module includes at least one of the following modules in the autonomous driving system: The system includes a perception module, a decision-making and planning module, a positioning module, a control module, a prediction module, and a human-computer interaction module.
11. A domain controller, comprising: Memory, which is configured to store computer-executable instructions; A processor configured to perform the method according to any one of claims 1 to 10 when the computer-executable instructions are executed by the processor.
12. A computer program product comprising computer-executable instructions, wherein the computer-executable instructions, when executed by an executor, perform the method according to any one of claims 1 to 10.