Task congestion processing method and device, control system, vehicle, storage medium, program product and chip system

Abstract

The invention relates to a task congestion processing method and device, a control system, a vehicle, a storage medium, a program product and a chip system, and the method comprises the steps that a first processor obtains information generated when a second processor executes a task from a shared memory; the first processor judges whether the task operated by the second processor is congested or not based on the information; and the first processor outputs prompt information of congestion of the second processor under the condition that the tasks operated by the second processor are congested. The method is used for automatically detecting the running state of the multi-core system.

Description

Technical Field

[0001] This disclosure relates to the field of vehicle control technology, and in particular to methods, devices, control systems, vehicles, storage media, software products, and chip systems for handling traffic congestion. Background Technology

[0002] In the field of embedded control, when a processor is running a periodic task, it may become congested because a task gets stuck in an infinite loop, deadlock, or resource waiting, which will cause the processor to malfunction.

[0003] Congestion issues in embedded control systems are often difficult to troubleshoot, preventing the processor from functioning properly. Summary of the Invention

[0004] To overcome the problems existing in related technologies, this disclosure provides a task congestion handling method, apparatus, control system, vehicle, storage medium, program product, and chip system.

[0005] According to some embodiments of this disclosure, a task congestion handling method is provided, including:

[0006] The first processor obtains information generated by the second processor during the execution of its tasks from shared memory.

[0007] Based on the information, the first processor determines whether the task being run by the second processor is experiencing congestion;

[0008] If the task being run by the second processor becomes congested, the first processor outputs a congestion warning message for the second processor.

[0009] In some embodiments of the first aspect, the shared memory stores the storage address of information of the second processor;

[0010] The step of obtaining the information of the second processor from the shared memory includes:

[0011] Obtain the storage address of the second processor's information from the shared memory, and obtain the second processor's information from that storage address.

[0012] Shared memory stores only pointers to fixed memory addresses corresponding to multiple processors, rather than the frequently changing information itself. This effectively avoids multiple processors simultaneously performing frequent write operations on shared memory, eliminating data races, read / write conflicts, and data consistency issues.

[0013] In some embodiments of the first aspect, the information includes the set running frequency, actual running time, and actual number of runs of the periodic task run by the second processor;

[0014] Based on the information, the first processor determines whether the task being run by the second processor is congested, including:

[0015] The first processor determines whether the periodic task running by the second processor is congested based on the set running frequency, actual running time, and actual number of runs of the periodic task running by the second processor.

[0016] This method can automatically detect the operating status of a multi-core system without physical debuggers, without interrupting the operation of the control system, and without relying on external tools. By enabling multiple processors to monitor each other, it effectively avoids monitoring failures caused by single points of failure, ensures continuous monitoring of the multi-core operating status in the control system, and generates prompts when task congestion is detected to prompt staff to handle block congestion. This allows developers to promptly review the code logic of the congested core to ensure the normal operation of the processor.

[0017] In some embodiments of the first aspect, the first processor determines whether the periodic task being run by the second processor is congested based on the set running frequency, actual running time, and actual number of runs of the periodic task being run by the second processor, including:

[0018] The first processor determines the preset number of times the periodic task to be run by the second processor based on the set operating frequency and the actual running time;

[0019] The first processor determines whether the periodic task run by the second processor is congested based on the preset number of runs and the actual number of runs.

[0020] By comparing the preset number of runs of periodic tasks with the actual number of runs, the state detection of whether the second processor is congested is transformed into a numerical comparison, thereby enabling a fast and accurate judgment of the running task status of the second processor.

[0021] In some embodiments of the first aspect, the first processor determines whether the periodic task run by the second processor is congested based on the preset number of runs and the actual number of runs, including:

[0022] If the actual number of runs equals the preset number of runs, the first processor determines that the periodic task run by the second processor is not congested.

[0023] If the actual number of runs is less than the preset number of runs, the first processor waits for a preset time. If the actual number of runs of the periodic task run by the second processor does not change after the preset time, it is determined that the periodic task run by the second processor is congested.

[0024] When the actual number of times a task running on the second processor is detected to be less than the preset number of times, instead of immediately determining that the task is congested, a preset observation window is introduced. This delayed confirmation mechanism effectively filters out accidental counting delays caused by instantaneous high system load, reasonable task preemption, or short-term resource waiting, thereby significantly reducing the risk of false alarms and ensuring the accuracy of the first processor's judgment.

[0025] In some embodiments of the first aspect, the method further includes:

[0026] When the first processor's occupancy rate indicates that the first processor's occupancy rate has reached a preset first occupancy rate threshold, the third processor is triggered to monitor whether the tasks running on the second processor are congested based on the information of the second processor in the shared memory; the occupancy rate of the third processor has not reached the preset first occupancy rate threshold.

[0027] By sensing the utilization rate of the first processor in real time, its monitoring responsibilities are intelligently transferred to the less loaded third processor. This effectively avoids competition for computing resources between the monitoring task and other tasks running on the first processor when the first processor is under high load, preventing the first processor from being overloaded. This ensures that the performance of the first processor is not affected by the need to monitor the status of tasks running on the second processor, thus guaranteeing the normal use of the first processor.

[0028] In some embodiments of the first aspect, the triggering of the third processor to monitor whether the task being run by the second processor is congested based on information from the second processor in the shared memory includes:

[0029] The first processor sends a first adjustment instruction to a preset fourth processor, so that the fourth processor determines the third processor based on the utilization rate of at least one processor other than the first processor and the second processor, and sends a first trigger instruction to the third processor;

[0030] Alternatively, the first processor determines the third processor based on the utilization rate of at least one processor other than the first processor and the second processor, and sends a second trigger instruction to the third processor.

[0031] It can ensure that when the first processor is overloaded, the monitoring task of the second processor is quickly transferred, thereby avoiding the failure or overload of a single monitoring node, which would prevent the task running status of the second processor from being monitored. This makes the control system more flexible in detecting the process of each processor executing tasks.

[0032] In some embodiments of the first aspect, the method further includes:

[0033] When congestion occurs in the task being run by the second processor, the first processor determines the location of the congestion point based on the information.

[0034] When congestion is detected in a task running on the second processor, the system can accurately pinpoint the congestion point based on information stored in shared memory. This allows developers to directly review the problematic code logic at the congestion point, thereby significantly reducing after-sales maintenance costs and time.

[0035] In some embodiments of the first aspect, the information further includes execution context information generated when the second processor performs periodic tasks;

[0036] Determining the location of the blockage based on the information includes:

[0037] Based on the execution context information, the first processor locates the line of code where congestion occurred during the execution of the task by the second processor, and identifies it as the congestion point.

[0038] After congestion is confirmed, in-depth analysis of the execution context information can be performed, avoiding the need for the first processor to continuously perform high-overhead in-depth diagnostics of the task's running status during the normal operation of the second processor's task. This saves the first processor's operating resources and reduces the monitoring overhead of the control system on the processor's running status.

[0039] In some embodiments of the first aspect, the method further includes:

[0040] Based on the execution context information, the first processor performs stack backtracking on the process of the second processor executing the task to obtain the function call chain generated during the execution of the task by the second processor.

[0041] Based on locating the bottleneck line of code and revealing the location of the fault, the system can fully reproduce the complete execution sequence of the periodic task from the start of execution to the sending of the fault through stack backtrace of the function call chain. It clearly reveals the logical context of function calls during execution, enabling developers to directly and clearly infer the cause of the bottleneck based on the function call sequence, thereby significantly reducing after-sales maintenance costs and time.

[0042] In some embodiments of the first aspect, the method further includes:

[0043] When the occupancy rate of the first processor reaches a preset second occupancy rate threshold, the first processor triggers the fifth processor to determine the bottleneck location based on the information of the second processor in the shared memory; the occupancy rate of the fifth processor does not reach the preset second occupancy rate threshold.

[0044] By sensing the occupancy rate of the second processor, the system intelligently determines when congestion occurs on the second processor and transfers the task of analyzing the specific congestion point to the less loaded fifth processor. This effectively avoids competition for computing resources between the task analyzing the specific congestion point and other tasks running on the first processor when the first processor is under high load, preventing the first processor from being overloaded. This ensures that the performance of the first processor is not affected by the need to analyze the specific congestion point of the task running on the second processor, thus guaranteeing the normal use of the first processor.

[0045] In some embodiments of the first aspect, the triggering of the fifth processor to determine the location of the blockage based on information from the second processor in the shared memory includes:

[0046] The first processor sends a second adjustment instruction to a preset sixth processor, so that the sixth processor determines the fifth processor based on the utilization rate of at least one processor other than the first processor and the second processor, and sends a third trigger instruction to the fifth processor;

[0047] Alternatively, the first processor determines the fifth processor based on the utilization rate of at least one processor other than the first processor and the second processor, and sends a fourth trigger instruction to the fifth processor.

[0048] By sensing the utilization rate of the first processor, the analysis task of the specific bottleneck location is intelligently transferred to the fifth processor with a lighter load. This effectively avoids the competition for computing resources between the analysis task of the specific bottleneck location and other tasks running on the first processor when the first processor is under high load, preventing the first processor from being overloaded. This ensures that the performance of the first processor is not affected by the need to analyze the status of the specific bottleneck location in the second processor, thus guaranteeing the normal use of the first processor.

[0049] According to some embodiments of the present disclosure, a task congestion handling apparatus is provided. The apparatus is disposed in a first processor of a control system, the control system further comprising a second processor and shared memory. The apparatus includes:

[0050] The acquisition module is configured so that the first processor acquires information generated by the second processor during the execution of a task from shared memory;

[0051] The judgment module is configured to determine, based on the information, whether the task being run by the second processor is experiencing congestion.

[0052] The prompt module is configured to output a congestion prompt message for the second processor when the task being run by the second processor becomes congested.

[0053] In some embodiments of the second aspect, the information includes the set running frequency, actual running time, and actual number of runs of the periodic task run by the second processor;

[0054] The judgment module is also configured to:

[0055] The first processor determines whether the periodic task running by the second processor is congested based on the set running frequency, actual running time, and actual number of runs of the periodic task running by the second processor.

[0056] In some embodiments of the second aspect, the determining module is further configured to:

[0057] The first processor determines the preset number of times the periodic task to be run by the second processor based on the set operating frequency and the actual running time;

[0058] The first processor determines whether the periodic task run by the second processor is congested based on the preset number of runs and the actual number of runs.

[0059] In some embodiments of the second aspect, the determining module is further configured to:

[0060] If the actual number of runs equals the preset number of runs, the first processor determines that the periodic task run by the second processor is not congested.

[0061] If the actual number of runs is less than the preset number of runs, the first processor waits for a preset time. If the actual number of runs of the periodic task run by the second processor does not change after the preset time, it is determined that the periodic task run by the second processor is congested.

[0062] In some embodiments of the second aspect, the task congestion processing apparatus further includes:

[0063] The first triggering module is configured to, when the first processor indicates that the utilization rate of the first processor has reached a preset first utilization rate threshold, trigger the third processor to monitor whether the task running on the second processor is congested based on the information of the second processor in the shared memory; the utilization rate of the third processor has not reached the preset first utilization rate threshold.

[0064] In some embodiments of the second aspect, the first triggering module is further configured to:

[0065] The first processor sends a first adjustment instruction to a preset fourth processor, so that the fourth processor determines the third processor based on the utilization rate of at least one processor other than the first processor and the second processor, and sends a first trigger instruction to the third processor;

[0066] Alternatively, the first processor determines the third processor based on the utilization rate of at least one processor other than the first processor and the second processor, and sends a second trigger instruction to the third processor.

[0067] In some embodiments of the second aspect, the task congestion processing apparatus further includes:

[0068] The determination module is configured to determine the location of the congestion point based on the information when the first processor encounters congestion in the task being run by the second processor.

[0069] In some embodiments of the second aspect, the information further includes execution context information generated when the second processor performs periodic tasks;

[0070] The determining module is further configured to:

[0071] Based on the execution context information, the first processor locates the line of code where congestion occurred during the execution of the task by the second processor, and identifies it as the congestion point.

[0072] In some embodiments of the second aspect, the determining module is further configured to:

[0073] Based on the execution context information, the first processor performs stack backtracking on the process of the second processor executing the task to obtain the function call chain generated during the execution of the task by the second processor.

[0074] In some embodiments of the second aspect, the task congestion processing apparatus further includes:

[0075] The second trigger module is configured to trigger the fifth processor to determine the bottleneck location based on the information of the second processor in the shared memory when the first processor's occupancy rate indicates that the first processor's occupancy rate has reached a preset second occupancy rate threshold; wherein the fifth processor's occupancy rate has not reached the preset second occupancy rate threshold.

[0076] In some embodiments of the second aspect, the second triggering module is further configured to:

[0077] The first processor sends a second adjustment instruction to a preset sixth processor, so that the sixth processor determines the fifth processor based on the utilization rate of at least one processor other than the first processor and the second processor, and sends a third trigger instruction to the fifth processor;

[0078] Alternatively, the first processor determines the fifth processor based on the utilization rate of at least one processor other than the first processor and the second processor, and sends a fourth trigger instruction to the fifth processor.

[0079] According to some embodiments of this disclosure, a control system is provided, including a first processor, a second processor, and shared memory;

[0080] The control system is used to employ the task congestion handling method in any of the above embodiments, wherein the first processor obtains information generated by the second processor during task execution from the shared memory; based on the information, it determines whether the task being run by the second processor is congested; and if the task being run by the second processor is congested, it outputs a congestion warning message for the second processor.

[0081] According to some embodiments of this disclosure, a vehicle is provided, including the control system of any of the above embodiments.

[0082] According to some embodiments of this disclosure, a computer-readable storage medium is provided, the storage medium storing a computer program or instructions, which, when executed by a processor of an electronic device, enable the electronic device to perform a congestion handling method of the first aspect, including:

[0083] The first processor obtains information generated by the second processor during the execution of a task from the shared memory.

[0084] Based on the information, the first processor determines whether the task being run by the second processor is experiencing congestion;

[0085] If the task being run by the second processor becomes congested, the first processor outputs a congestion warning message for the second processor.

[0086] According to some embodiments of this disclosure, a computer program product is provided, including a computer program, wherein the computer program is executed by a processor as a first aspect of a task congestion processing method, comprising:

[0087] The first processor obtains information generated by the second processor during the execution of a task from the shared memory.

[0088] Based on the information, the first processor determines whether the task being run by the second processor is experiencing congestion;

[0089] If the task being run by the second processor becomes congested, the first processor outputs a congestion warning message for the second processor.

[0090] According to some embodiments of this disclosure, a chip system is provided, the chip system including a processing unit and an interface circuit, the processing unit acquiring program instructions through the interface circuit, the program instructions being executed by the processing unit, the processing unit being used to execute a task congestion processing method of the first aspect, including:

[0091] The first processor obtains information generated by the second processor during the execution of a task from the shared memory.

[0092] Based on the information, the first processor determines whether the task being run by the second processor is experiencing congestion;

[0093] If the task being run by the second processor becomes congested, the first processor outputs a congestion warning message for the second processor.

[0094] The technical solutions provided by the embodiments of this disclosure can include the following beneficial effects: they can automatically complete the detection of the operating status of a multi-core system without physical debuggers, without interrupting the operation of the control system, and without relying on external tools; by enabling multiple processors to monitor each other, this method effectively avoids monitoring failure caused by single point of failure, ensures continuous detection of the operating status of multiple cores in the control system, and when task congestion is detected, it can generate prompt information to prompt staff to handle block congestion, enabling developers to promptly review the code logic of the congested core to ensure the normal operation of the processor.

[0095] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0096] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0097] Figure 1 This is a flowchart illustrating a task congestion handling method according to some embodiments of the present disclosure.

[0098] Figure 2 This is a block diagram illustrating a task congestion handling apparatus according to some embodiments of the present disclosure.

[0099] Figure 3 This is a block diagram illustrating a task congestion handling apparatus according to some embodiments of the present disclosure.

[0100] Figure 4 This is a block diagram of another task congestion handling apparatus shown according to some embodiments of the present disclosure.

[0101] Figure 5 This is a block diagram illustrating yet another task congestion handling apparatus according to some embodiments of the present disclosure.

[0102] Figure 6 This is a functional block diagram of a vehicle according to some embodiments of the present disclosure.

[0103] Figure 7 This is a schematic diagram of the structure of a chip system according to some embodiments of the present disclosure. Detailed Implementation

[0104] Some embodiments of this disclosure will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. Various changes, modifications, and equivalents of the methods, apparatus, and / or systems described herein will become apparent upon understanding this disclosure. For example, the order of operations described herein is merely illustrative and is not limited to those orders set forth herein, but can be changed as will become apparent upon understanding this disclosure, except for operations that must be performed in a particular order. Furthermore, for clarity and brevity, descriptions of features known in the art may be omitted.

[0105] The embodiments described in the following examples of this disclosure are not representative of all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0106] Figure 1 This is a flowchart illustrating a task congestion handling method according to some embodiments of the present disclosure, such as... Figure 1 As shown, the task congestion handling method is used in the first processor of the control system. The control system also includes a second processor and shared memory. The task congestion handling method includes the following steps.

[0107] In step S11, the first processor obtains information generated by the second processor during the execution of the task from the shared memory.

[0108] A control system refers to an embedded computer system that includes multiple processors. For example, a control system can be a vehicle control system, which is used to realize real-time functions such as vehicle engine control, vehicle stability, and autonomous driving.

[0109] The first processor can be any one of the multiple processors included in the control system. As a monitor, the first processor performs the task of monitoring whether other processors are experiencing congestion.

[0110] The second processor can be any one of the multiple processors included in the control system, excluding the first processor. The second processor, as the monitored entity, is monitored by the first processor. The second processor is used to save information generated during task execution to shared memory.

[0111] As an example, the first processor may be a second processor determined from at least one processor in the control system other than the first processor, based on a pre-set monitoring relationship. The monitoring relationship can refer to a predefined logical rule or configuration table describing the relationship between different processors, that is, the monitoring party and the monitored party.

[0112] For example, in a quad-core system, the monitoring relationship can be pre-configured as follows: processor 0 monitors processors 1 and 2; processor 1 monitors processors 0 and 3, or it can be configured as follows: processors 0 and 1 monitor each other, processors 3 and 4 monitor each other, etc., thus forming a cross-monitoring network to avoid the failure of a core that only performs monitoring.

[0113] Alternatively, the program running the first processor can be pre-programmed to monitor the second processor. When the first processor starts running, it will begin monitoring whether congestion occurs on the second processor.

[0114] Alternatively, the first processor could be a second processor that needs to be monitored, determined manually by the developers.

[0115] It should be noted that this application does not limit the method by which the first processor determines the corresponding second processor.

[0116] Shared memory refers to a pre-configured memory region that can be directly accessed by multiple processors in the system.

[0117] Multiple processors can communicate with each other by writing data to or reading data from shared memory.

[0118] Information refers to a collection of key data recorded by the second processor to save the current execution state of a task when the task being run by the second processor is switched. The tasks run by the second processor may include periodic tasks, which are tasks that are repeatedly executed at fixed time intervals, such as sensor data reading and control law calculation.

[0119] Task switching refers to the processor disengaging from its current task and switching to another. Secondly, the processor can, at the moment of switching, completely write all the key data reflecting the processor's operating state accumulated during the entire execution process from the last switch to the current switch into the corresponding memory address.

[0120] Task switching can be understood as the node that triggers the second processor to write information about each task to be executed in shared memory.

[0121] As an example, the information includes, but is not limited to: a program counter, which indicates the address of the instruction being executed when the task is interrupted; a stack pointer, which indicates the current top position of the stack for a periodic task; other critical registers, such as link registers, status registers, and general-purpose registers, which together constitute the complete processor state required for the task to continue running; and information such as the task's management metadata, which describes the task's own attributes and resource status, such as the task's identifier, priority, status, and the base address and size range of the stack.

[0122] As an example, the first processor can periodically access a common memory region that can be read and written by all processors, and read from it runtime data written and updated by the second processor regarding the relevant runtime status during the execution of tasks by the second processor.

[0123] In step S12, the first processor determines, based on the information, whether the task being run by the second processor is congested.

[0124] Task congestion refers to a state in which a task cannot be executed on time because it is stuck in an infinite loop, deadlocked, or waiting for processing resources for too long.

[0125] In step S13, if the task being run by the second processor becomes congested, the first processor outputs a congestion warning message for the second processor.

[0126] The prompts can be structured diagnostic data reports. These prompts can transform information about congestion within the secondary processor into engineered information that developers can quickly understand, locate, and address.

[0127] The presentation of prompts can take many forms to suit different scenarios. For example, they can be structured logs or visual reports.

[0128] The aforementioned task congestion handling method can automatically detect the operational status of a multi-core system without the need for a physical debugger, without interrupting the operation of the control system, and without relying on external tools. By enabling multiple processors to monitor each other, this method effectively avoids monitoring failures caused by single points of failure, ensuring continuous monitoring of the multi-core operational status in the control system. Furthermore, when task congestion is detected, it can generate prompts to alert staff to handle block congestion, allowing developers to promptly review the code logic of the congested core to ensure the normal operation of the processor.

[0129] In some optional embodiments, the information includes the set running frequency, actual running time, and actual number of runs of the periodic task run by the second processor;

[0130] Step S12 includes:

[0131] The first processor determines whether the periodic tasks running on the second processor are congested based on the set running frequency, actual running time, and actual number of runs of the periodic tasks running on the second processor.

[0132] The actual number of executions is typically determined by a counter associated with a periodic task running in the second processor, which increments the counter after each successful execution of the periodic task. The count of this counter indicates the number of times the periodic task has been successfully executed.

[0133] The actual runtime can be recorded by a timer bound to the periodic task, which starts counting from the first execution of the periodic task, and the timer's count indicates the total duration of the periodic task running periodically.

[0134] In this embodiment, the first processor does not directly perceive the logical state of the periodic task running in the second processor, but indirectly determines the running state of the periodic task by using two quantifiable features: the actual number of runs and the actual running time.

[0135] Specifically, the first processor determines whether the periodic tasks running on the second processor are congested based on the set running frequency, actual running time, and actual number of runs of the periodic tasks run on the second processor. This includes the following steps:

[0136] The first processor determines the preset number of times the periodic task to be run by the second processor based on the set operating frequency and the actual running time.

[0137] The first processor determines whether the periodic tasks run by the second processor are congested based on the preset number of runs and the actual number of runs.

[0138] The above-mentioned task congestion handling method transforms the state detection of whether the second processor is congested into a numerical comparison by comparing the preset number of times the periodic task is run with the actual number of times it is run. This enables a fast and accurate judgment of the task status of the second processor.

[0139] In one embodiment, the step of the first processor determining whether a periodic task run by the second processor is congested based on a preset number of runs and the actual number of runs includes:

[0140] If the actual number of runs equals the preset number of runs, the first processor determines that the periodic tasks run by the second processor are not congested.

[0141] If the actual number of runs by the first processor is less than the preset number of runs, it waits for a preset time. If the actual number of runs of the periodic task run by the second processor does not change after the preset time, it is determined that the periodic task run by the second processor is congested.

[0142] Specifically, the first processor can determine that when the actual number of times the periodic task run by the second processor is less than the preset number of times, it waits for a preset time and then obtains the new actual number of times the periodic task is run again after the preset time. If the new actual number of times does not increase, the first processor can determine that the periodic task run by the second processor is congested.

[0143] As an example, if the set running frequency of a periodic task running in the second processor is 100ms / time, the actual number of times it runs is 3, and the actual running time is 1000ms, then the first processor can determine that the preset number of times the periodic task runs is 1000ms / 100ms / time = 10 times. Since the actual number of times the periodic task runs is 3 times, which is less than the preset number of times it runs is 10 times, the first processor can determine that the periodic task has not been successfully executed in multiple execution cycles, and thus determines that the periodic task is congested.

[0144] For example, if a periodic task running in the second processor is set to run at a frequency of 100ms / time, and actually runs 3 times with an actual runtime of 1000ms, the first processor can determine that the periodic task has not been successfully executed in multiple execution cycles. However, the first processor can wait for a preset time and then obtain the new actual number of runs for the periodic task after the preset time. If the actual number of runs is still 3, the first processor can determine that the periodic task is congested.

[0145] The above-mentioned task congestion handling method does not immediately determine that the task is congested when it detects that the actual number of times a task running on the second processor is less than the preset number of times. Instead, it introduces a preset observation window. This delayed confirmation mechanism effectively filters out the accidental counting lag caused by instantaneous high system load, reasonable task preemption, or short-term resource waiting, thereby significantly reducing the risk of false alarms and ensuring the accuracy of the first processor's judgment.

[0146] It should be noted that the first processor can either continuously monitor the information of the second processor or perform detection according to a preset monitoring frequency.

[0147] In one embodiment, when the first processor detects the information of the second processor according to a preset monitoring frequency, a tolerance threshold can be set. When the first processor monitors the actual number of times and the actual running time of the periodic task running in the second processor for the first time, and determines that the actual number of times the periodic task runs is inconsistent with the preset number of times, the first processor can compare the difference between the actual number of times the periodic task runs and the preset number of times with the tolerance threshold. If the difference is less than the tolerance threshold, the first processor can first consider that the periodic task running in the second processor is not congested. Only when the difference between the actual number of times the periodic task runs and the preset number of times is greater than or equal to the tolerance threshold, does the first processor determine that the periodic task running in the second processor is congested.

[0148] Alternatively, the first processor may wait for a preset time if the difference between the actual number of times the periodic task is run and the preset number of times it is run does not reach the tolerance threshold. If, after the preset time, the difference between the actual number of times the periodic task is run and the preset number of times it is run is less than the tolerance threshold, the first processor may assume that the periodic task is not congested. If, after the preset time, the difference between the actual number of times the periodic task is run and the preset number of times it is run is greater than or equal to the tolerance threshold, the first processor may assume that the periodic task is congested.

[0149] The above-mentioned task congestion handling method, by setting a tolerance threshold, enables the control system to tolerate periodic task failures caused by occasional, instantaneous system jitter, allowing periodic tasks to have a limited number of recoverable, short-term anomalies. This effectively filters system noise and ensures that the first processor is only triggered when the congestion problem of the second processor persists and worsens, greatly reducing the false alarm rate.

[0150] In some alternative embodiments, the shared memory stores the storage address of information of the second processor;

[0151] Step S11 includes:

[0152] The first processor obtains the storage address of the second processor's information from the shared memory, and then obtains the second processor's information from that storage address.

[0153] As an example, the shared memory may maintain an address index table that includes the storage addresses of information corresponding to multiple processors in the control system. These storage addresses point to locations in the control system's memory where information for a second processor is stored.

[0154] In this embodiment, the first processor can first access the shared memory, query the pre-established address index table, and find the storage address of the second processor's information; then it can directly access the specific location in the memory of the control system pointed to by the storage address and read the second processor's information from it.

[0155] In the above-mentioned task congestion handling method, the first processor can obtain the storage address of the second processor's information through shared memory, and then access the storage location of the actual running data accordingly. The shared memory only stores pointers to fixed memory addresses corresponding to multiple processors, rather than the frequently changing information itself. This effectively avoids multiple processors performing frequent information write operations to the shared memory at the same time, eliminating data competition, read-write conflicts, and data consistency problems. It also avoids the repetitive operation of multiple processors writing information to the shared memory after writing it to a fixed memory address, making the operation of the control system smoother.

[0156] In some optional embodiments, the task congestion handling method further includes:

[0157] If the utilization rate of the first processor reaches a preset first utilization rate threshold, the third processor is triggered to monitor whether the tasks running on the second processor are congested based on the information of the second processor in the shared memory; if the utilization rate of the third processor does not reach the preset first utilization rate threshold.

[0158] The first utilization threshold refers to a predefined percentage value used to indicate the critical point at which the first processor enters a high-load or overload state. When the utilization of the first processor exceeds the first utilization threshold, it can be considered that the first processor cannot handle additional monitoring tasks.

[0159] In this embodiment, the utilization rate of the first processor can be checked continuously or periodically. When the utilization rate is detected to reach or exceed the preset first utilization rate threshold, it can be considered that the first processor is in an overload state. At this time, the first processor cannot execute the high-load monitoring and diagnostic process, thereby triggering a third processor to take over from the first processor and monitor the status of the tasks running in the second processor (i.e., execute steps S11-S13). The utilization rate of the third processor needs to be lower than the preset first utilization rate threshold, that is, it is not in an overload state.

[0160] The above-mentioned task congestion handling method intelligently transfers the monitoring responsibilities of the first processor to the less loaded third processor by sensing the utilization rate of the first processor in real time. This effectively avoids the competition for computing resources between the monitoring task and other tasks running on the first processor when the first processor is under high load, prevents the first processor from being overloaded, and ensures that the performance of the first processor will not be affected by the need to monitor the status of tasks running on the second processor, thus ensuring the normal use of the first processor.

[0161] In some optional embodiments, the third processor is triggered to monitor whether the task being run by the second processor is congested, based on information from the second processor in shared memory, including:

[0162] The first processor sends a first adjustment instruction to a preset fourth processor, so that the fourth processor determines the third processor based on the utilization rate of at least one processor other than the first processor and the second processor, and sends a first trigger instruction to the third processor.

[0163] Alternatively, the first processor determines the third processor based on the utilization rate of at least one processor other than the first and second processors, and sends a second trigger instruction to the third processor.

[0164] In this embodiment, when the first processor is unable to execute the monitoring task of the second processor due to high load, a collaborative decision-making process can be initiated to find the globally optimal processor to replace the monitoring of whether the second processor's running task is congested.

[0165] Specifically, when the occupancy status of the first processor indicates that the occupancy rate of the first processor has reached a first occupancy rate threshold, the first processor may send a first adjustment instruction to a preset fourth processor, so that the fourth processor can obtain the occupancy rate of at least one processor other than the first processor and the second processor, and for example, the processor with the lowest occupancy rate can be designated as the third processor. The fourth processor sends a first trigger instruction to the third processor, so that the third processor can obtain information about the second processor from the shared memory. Based on the information, the fourth processor determines whether the task being run by the second processor is congested.

[0166] The fourth processor can be a pre-specified processor used to adjust the monitoring and monitored relationship among multiple processors.

[0167] In this situation, after determining that it is overloaded, the first processor does not automatically select a third processor to take over. Instead, it sends a first adjustment instruction to a preset fourth processor that can adjust the monitoring and monitored relationship between multiple processors. After receiving the first adjustment instruction, the fourth processor can execute a better resource selection algorithm, actively query the current utilization rate of all other processors except the first and second processors, and select the one with the lowest or relatively low utilization rate as the successor to the second processor's monitoring task.

[0168] Alternatively, if the occupancy status of the first processor indicates that the occupancy rate of the first processor has reached a first occupancy rate threshold, the first processor can directly obtain the occupancy rate of at least one processor other than the first processor and the second processor, and for example, the processor with the lowest occupancy rate can be designated as the third processor, and a second trigger instruction can be sent to the third processor to enable the third processor to obtain the information of the second processor from the shared memory; and based on the information, determine whether the task running on the second processor is congested.

[0169] In this situation, after determining that it is overloaded, the first processor can actively query the current utilization rate of all other processors except the second processor, and select the one with the lowest or relatively low utilization rate to take over the monitoring task of the second processor.

[0170] The aforementioned task congestion handling method, through a dual scheduling path design, provides a flexible and reliable task handover method. Whether it is centralized scheduling implemented through the fourth processor or distributed scheduling initiated by the first processor, it can ensure that when the first processor is overloaded, the transfer of monitoring tasks of the second processor is quickly triggered. This avoids the situation where a single monitoring node fails or is overloaded, making it impossible to monitor the task running status of the second processor. This makes the control system's detection of the task execution process of each processor more flexible.

[0171] In some optional embodiments, the task congestion handling method further includes:

[0172] When congestion occurs in the tasks running on the second processor, the first processor determines the location of the congestion point based on the information.

[0173] For example, a bottleneck location refers to the specific location in the program where the code causing periodic tasks to become congested.

[0174] As an example, the first processor can perform specific analysis on the information during the second processor's task execution to determine the specific location of the bottleneck that caused the task congestion, thereby achieving precise location of the bottleneck.

[0175] The aforementioned task congestion handling can accurately pinpoint the congestion point based on information stored in shared memory when congestion is detected in a task running on the second processor. This allows developers to directly review the problematic code logic at the congestion point, thereby significantly reducing after-sales maintenance costs and time.

[0176] In some optional embodiments, the information may also include execution context information generated when the second processor performs periodic tasks;

[0177] Based on the information, the location of the bottleneck is determined, including:

[0178] Based on the execution context information, the first processor locates the line of code where congestion occurred during the execution of the task by the second processor, and identifies it as the congestion point.

[0179] Execution context information refers to the set of data saved when a periodic task is switched off by the processor, indicating the complete execution status of that periodic task. This may include information such as the program counter, stack pointer, frame pointer, and link registers.

[0180] The address stored in the program counter register directly corresponds to the memory address of the instruction that the second processor is executing when the task running in the second processor is switched.

[0181] By matching the memory address with a pre-configured program debug symbol table, the memory address can be converted into source code file names, function names, and precise line numbers, thereby identifying the line of code where congestion is occurring. The debug symbol table is a database that maps memory addresses to source code files, functions, and line numbers.

[0182] The above-mentioned task congestion handling method can perform in-depth analysis of execution context information after congestion is determined, avoiding the need for the first processor to continuously perform high-overhead in-depth diagnosis of the task's running status during the normal operation of the task on the second processor. This saves the first processor's operating resources and reduces the monitoring overhead of the control system on the processor's running status.

[0183] In some alternative embodiments, the task congestion method further includes:

[0184] Based on the execution context information, the first processor performs stack backtracking on the process of the second processor executing the task, and obtains the function call chain generated during the execution of the task by the second processor.

[0185] Stack backtracking refers to the process of analyzing the stack memory data structure to reverse-engineer the periodic tasks executed by the second processor and the function call relationships in the execution history of the program involved.

[0186] A function call chain refers to a sequence arranged chronologically during the execution of a periodic task. It describes all the function call relationships experienced from the current execution of the periodic task by the second processor until the bottleneck occurs.

[0187] As an example, the first processor can use the stack pointer in the execution context information to locate the private stack of the periodic task executed by the second processor in memory. Then, following predetermined compiler and architecture rules, it traverses and parses the entire stack memory layer by layer from the top of the stack. During this process, the first processor can extract key return addresses and frame pointers from each function stack frame. These addresses, after being parsed by the debug symbol table, can be converted into corresponding function names. Finally, the first processor can organize these function names in the order of their calls, thereby reconstructing the entire sequence of function calls from the current execution of the periodic task by the second processor until the code behavior that caused the bottleneck.

[0188] The above-mentioned task congestion handling method can, based on locating the congestion line of code and revealing the location of the fault, fully reproduce the complete execution sequence of the periodic task from the start of execution to the sending of the fault through the function call chain generated by stack backtrace. It clearly reveals the logical context of function calls during execution, enabling developers to directly and clearly infer the cause of the congestion based on the function call sequence, thereby significantly reducing after-sales maintenance costs and time.

[0189] In some alternative embodiments, the task congestion method further includes:

[0190] If the occupancy rate of the first processor reaches a preset second occupancy threshold, the first processor triggers the fifth processor to determine the bottleneck location based on the information of the second processor in the shared memory; if the occupancy rate of the fifth processor does not reach the preset second occupancy threshold.

[0191] The second utilization threshold is also a predefined percentage value, used to indicate the baseline point at which the first processor is overloaded. When the utilization rate of the first processor exceeds the second utilization threshold, it can be considered that the first processor cannot handle additional specific bottleneck analysis tasks.

[0192] As an example, the second occupancy threshold can be greater than the first occupancy threshold, meaning that the requirement to determine that the first processor cannot perform the monitoring task is lower than the requirement to determine that the first processor cannot further analyze information to determine the specific bottleneck location. Alternatively, the second occupancy threshold can be the same as the first occupancy threshold.

[0193] In this embodiment, at any time after the first processor determines whether the task running by the second processor is congested based on information, it can trigger a check of the first processor's occupancy rate. When it is detected that the occupancy rate reaches or exceeds a preset second occupancy rate threshold, it can be considered that the first processor is in an overloaded state. At this time, the first processor cannot execute the high-load specific congestion point location analysis task, thereby triggering a fifth processor to take over from the first processor and perform the task of determining the congestion point location of the task running in the second processor. The occupancy rate of the fifth processor needs to be lower than the preset second occupancy rate threshold, that is, it is not in an overloaded state.

[0194] The aforementioned task congestion handling method, by sensing the occupancy rate of the second processor, intelligently determines the task that performs specific congestion location analysis after congestion occurs on the second processor, and transfers the task to the less loaded fifth processor. This effectively avoids competition for computing resources between the task analyzing specific congestion locations and other tasks running on the first processor when the first processor is under high load, preventing the first processor from being overloaded. This ensures that the performance of the first processor is not affected by the need to analyze the specific congestion locations of tasks running on the second processor, thus guaranteeing the normal use of the first processor.

[0195] In some optional embodiments, the fifth processor is triggered to determine the location of the bottleneck based on information from the second processor in shared memory, including:

[0196] The first processor sends a second adjustment instruction to a preset sixth processor, so that the sixth processor determines the fifth processor based on the utilization rate of at least one processor other than the first processor and the second processor, and sends a third trigger instruction to the fifth processor;

[0197] Alternatively, the first processor determines the fifth processor based on the utilization rate of at least one processor other than the first and second processors, and sends a fourth trigger instruction to the fifth processor.

[0198] Specifically, when the occupancy status of the first processor indicates that the occupancy rate of the first processor has reached a second occupancy rate threshold, the first processor may send a second adjustment instruction to a preset sixth processor, so that the sixth processor can obtain the occupancy rate of at least one processor other than the first processor and the second processor, and for example, the processor with the lowest occupancy rate can be designated as the fifth processor. The sixth processor sends a third trigger instruction to the fifth processor, so that the fifth processor can obtain information about the second processor from the shared memory; and based on the information, determine the location of the bottleneck.

[0199] The sixth processor can also be a pre-designated processor used to adjust the relationship between the analyzed blockage locations and the locations of the blockages being analyzed among multiple processors. The sixth processor and the fourth processor can be the same processor.

[0200] In this situation, after determining that it is overloaded, the first processor does not automatically select a fifth processor to take over. Instead, it sends a second adjustment instruction to a preset sixth processor that can adjust the relationship between the analysis of the bottleneck position and the analysis of the bottleneck position among multiple processors. After receiving the second adjustment instruction, the sixth processor can execute a better resource selection algorithm, actively query the current occupancy rate of all other processors except the first and second processors, and select the one with the lowest or relatively low occupancy rate as the successor to the second processor's specific bottleneck position analysis task.

[0201] Alternatively, if the occupancy status of the first processor indicates that the occupancy rate of the first processor has reached the second occupancy rate threshold, the first processor can directly obtain the occupancy rate of at least one processor other than the first processor and the second processor, and for example, the processor with the lowest occupancy rate can be designated as the fifth processor, and a fourth trigger instruction can be sent to the fifth processor to enable the fifth processor to obtain the information of the second processor from the shared memory; and based on the information, determine the location of the bottleneck.

[0202] In one embodiment, regardless of whether the utilization rate of the first processor reaches the first utilization rate threshold, the first processor is used to determine whether the task running on the second processor is congested. If the task running on the second processor is determined to be congested, the utilization rate of the first processor is evaluated. When the utilization rate of the first processor reaches the second utilization rate threshold, it can be considered that the first processor is not suitable for specific analysis of the information of the second processor. At this time, the information of the second processor can be allocated to other processors for analysis to determine the bottleneck location of the task running on the second processor.

[0203] In another embodiment, if the first processor has already transferred the monitoring task of the task run by the second processor to the third processor, the third processor can continue to perform the analysis task of the specific blockage location. The occupancy rate of the third processor is lower than the preset first occupancy rate threshold, while the second occupancy rate threshold is greater than or equal to the first occupancy rate threshold. Therefore, the third processor meets the occupancy rate requirement for performing the analysis of the specific blockage location by default.

[0204] The aforementioned task congestion handling method, by sensing the utilization rate of the first processor, intelligently transfers the analysis task of the specific congestion point to the fifth processor with a lighter load. This effectively avoids the competition for computing resources between the analysis task of the specific congestion point and other tasks running on the first processor when the first processor is under high load, preventing the first processor from being overloaded. This ensures that the performance of the first processor is not affected by the need to analyze the status of the specific congestion point in the second processor, thus guaranteeing the normal use of the first processor.

[0205] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0206] Figure 2 This is a block diagram illustrating a task congestion handling apparatus 200 according to some embodiments of the present disclosure. (Refer to...) Figure 2 The congestion handling device includes an acquisition module 201, a judgment module 202, and a prompting module 203.

[0207] The acquisition module 201 is configured so that the first processor can acquire information generated by the second processor during the execution of a task from the shared memory.

[0208] The judgment module 202 is configured so that the first processor determines, based on information, whether the task running on the second processor is congested;

[0209] The prompt module 203 is configured to output a congestion prompt message for the second processor when the task being run by the first processor becomes congested.

[0210] In some optional embodiments, the information includes the set running frequency, actual running time, and actual number of runs of the periodic task run by the second processor;

[0211] Module 202 is also configured as follows:

[0212] The first processor determines whether the periodic tasks running on the second processor are congested based on the set running frequency, actual running time, and actual number of runs of the periodic tasks running on the second processor.

[0213] In some optional embodiments, the determination module 202 is further configured to:

[0214] The first processor determines the preset number of times the periodic task to be run by the second processor based on the set operating frequency and the actual running time.

[0215] The first processor determines whether the periodic tasks run by the second processor are congested based on the preset number of runs and the actual number of runs.

[0216] In some optional embodiments, the determination module 202 is further configured to:

[0217] If the actual number of runs equals the preset number of runs, the first processor determines that the periodic tasks run by the second processor are not congested.

[0218] If the actual number of runs by the first processor is less than the preset number of runs, it waits for a preset time. If the actual number of runs of the periodic task run by the second processor does not change after the preset time, it is determined that the periodic task run by the second processor is congested.

[0219] In some optional embodiments, the shared memory stores the storage address of information about the second processor;

[0220] Module 201 is also configured as follows:

[0221] The first processor obtains the storage address of the second processor's information from the shared memory, and then obtains the second processor's information from that storage address.

[0222] like Figure 3 As shown, in some optional embodiments, the task congestion processing device 200 further includes:

[0223] The first trigger module 204 is configured such that when the first processor indicates that the utilization rate of the first processor has reached a preset first utilization rate threshold, the third processor is triggered to monitor whether the task running on the second processor is congested based on the information of the second processor in the shared memory; the utilization rate of the third processor has not reached the preset first utilization rate threshold.

[0224] In some optional embodiments, the first trigger module 204 is further configured to:

[0225] The first processor sends a first adjustment instruction to a preset fourth processor, so that the fourth processor determines the third processor based on the utilization rate of at least one processor other than the first processor and the second processor, and sends a first trigger instruction to the third processor.

[0226] Alternatively, the first processor determines the third processor based on the utilization rate of at least one processor other than the first and second processors, and sends a second trigger instruction to the third processor.

[0227] like Figure 4 As shown, in some optional embodiments, the task congestion processing device 200 further includes:

[0228] The determination module 205 is configured to determine the location of the congestion point based on information when the task running on the second processor is congested.

[0229] In some optional embodiments, the information also includes execution context information generated when the second processor performs periodic tasks;

[0230] The determination module 205 is also configured to: the first processor locates the line of code that is congested during the execution of the task by the second processor based on the execution context information, and uses it as the congestion point.

[0231] In some optional embodiments, the determining module 205 is further configured to:

[0232] Based on the execution context information, the first processor performs stack backtracking on the process of the second processor executing the task, and obtains the function call chain generated during the execution of the task by the second processor.

[0233] like Figure 5 As shown, in some optional embodiments, the task congestion processing device 200 further includes:

[0234] The second trigger module 206 is configured such that when the first processor indicates that the occupancy rate of the first processor has reached a preset second occupancy rate threshold, the first processor triggers the fifth processor to determine the bottleneck location based on the information of the second processor in the shared memory; the occupancy rate of the fifth processor has not reached the preset second occupancy rate threshold.

[0235] In some optional embodiments, the second trigger module 206 is further configured to:

[0236] The first processor sends a second adjustment instruction to a preset sixth processor, so that the sixth processor determines the fifth processor based on the utilization rate of at least one processor other than the first processor and the second processor, and sends a third trigger instruction to the fifth processor;

[0237] Alternatively, the first processor determines the fifth processor based on the utilization rate of at least one processor other than the first and second processors, and sends a fourth trigger instruction to the fifth processor.

[0238] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0239] Figure 6 This is a block diagram illustrating a vehicle 600 according to an exemplary embodiment. For example, vehicle 600 can be a hybrid vehicle, a non-hybrid vehicle, an electric vehicle, a fuel cell vehicle, or other types of vehicle. Vehicle 600 can be an intelligent assisted driving vehicle, a semi-intelligent assisted driving vehicle, or a non-intelligent assisted driving vehicle.

[0240] Reference Figure 6 The vehicle 600 may include various subsystems, such as an infotainment system 610, a perception system 620, a decision control system 630, a drive system 640, and a computing platform 650. The vehicle 600 may also include more or fewer subsystems, and each subsystem may include multiple components. Furthermore, each subsystem and each component of the vehicle 600 can be interconnected via wired or wireless means.

[0241] In some embodiments, the infotainment system 610 may include a communication system, an entertainment system, and a navigation system, etc.

[0242] The perception system 620 may include several sensors for sensing information about the environment surrounding the vehicle 600. For example, the perception system 620 may include a global positioning system (which may be GPS, BeiDou, or other positioning systems), an inertial measurement unit (IMU), lidar, millimeter-wave radar, ultrasonic radar, and a camera device.

[0243] The decision control system 630 may include a computing system, a vehicle controller, a steering system, a throttle, and a braking system.

[0244] The drive system 640 may include components that provide powered motion to the vehicle 600. In one embodiment, the drive system 640 may include an engine, an energy source, a transmission system, and wheels. The engine may be one or a combination of internal combustion engines, electric motors, and compressed air engines. The engine is capable of converting energy provided by the energy source into mechanical energy.

[0245] Some or all of the functions of vehicle 600 are controlled by computing platform 650. Computing platform 650 may include at least one processor 651 and memory 652, processor 651 can execute instructions 653 stored in memory 652.

[0246] Processor 651 can be any conventional processor, such as a commercially available CPU. Processors may also include graphics processing units (GPUs), field-programmable gate arrays (FPGAs), systems-on-chips (SoCs), application-specific integrated circuits (ASICs), or combinations thereof.

[0247] The memory 652 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0248] In addition to instruction 653, memory 652 can also store data, such as road maps, route information, vehicle position, direction, speed, and other data. The data stored in memory 652 can be used by computing platform 650.

[0249] In this embodiment of the disclosure, processor 651 may execute instruction 653 to complete all or part of the steps of the above-described task congestion handling method.

[0250] In some embodiments of this disclosure, a computer-readable storage medium including instructions is also provided, such as a memory including instructions that can be executed by a processor of a device to perform the methods described above. For example, the computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0251] A computer-readable storage medium, when instructions in the storage medium are executed by a processor of a mobile terminal, enables the mobile terminal to perform a task congestion handling method, the method comprising:

[0252] The first processor obtains information generated by the second processor during the execution of its tasks from shared memory.

[0253] The first processor uses information to determine whether the task being run by the second processor is congested.

[0254] If the task being run by the second processor becomes congested, the first processor will output a congestion warning message for the second processor.

[0255] In some optional embodiments, the information includes the set running frequency, actual running time, and actual number of runs of the periodic task run by the second processor;

[0256] Based on the information, the first processor determines whether the task being run by the second processor is congested, including:

[0257] The first processor determines whether the periodic tasks running on the second processor are congested based on the set running frequency, actual running time, and actual number of runs of the periodic tasks running on the second processor.

[0258] In some optional embodiments, the first processor determines whether the periodic task being run by the second processor is congested based on the set running frequency, actual running time, and actual number of runs of the periodic task being run by the second processor, including:

[0259] The first processor determines the preset number of times the periodic task to be run by the second processor based on the set operating frequency and the actual running time.

[0260] The first processor determines whether the periodic tasks run by the second processor are congested based on the preset number of runs and the actual number of runs.

[0261] In some optional embodiments, the first processor determines whether the periodic task run by the second processor is congested based on a preset number of runs and the actual number of runs, including:

[0262] If the actual number of runs equals the preset number of runs, the first processor determines that the periodic tasks run by the second processor are not congested.

[0263] If the actual number of runs by the first processor is less than the preset number of runs, it waits for a preset time. If the actual number of runs of the periodic task run by the second processor does not change after the preset time, it is determined that the periodic task run by the second processor is congested.

[0264] In some optional embodiments, the shared memory stores the storage address of information about the second processor;

[0265] The first processor obtains information about the second processor from shared memory, including:

[0266] The first processor obtains the storage address of the second processor's information from the shared memory, and then obtains the second processor's information from that storage address.

[0267] In some optional embodiments, the method further includes:

[0268] If the utilization rate of the first processor reaches a preset first utilization rate threshold, the third processor is triggered to monitor whether the tasks running on the second processor are congested based on the information of the second processor in the shared memory; if the utilization rate of the third processor does not reach the preset first utilization rate threshold.

[0269] In some optional embodiments, a third processor is triggered to monitor whether the tasks running on the second processor are experiencing congestion, based on information from the second processor in shared memory, including:

[0270] The first processor sends a first adjustment instruction to a preset fourth processor, so that the fourth processor determines the third processor based on the utilization rate of at least one processor other than the first processor and the second processor, and sends a first trigger instruction to the third processor.

[0271] Alternatively, the first processor determines the third processor based on the utilization rate of at least one processor other than the first and second processors, and sends a second trigger instruction to the third processor.

[0272] In some optional embodiments, the method further includes:

[0273] When congestion occurs in the tasks running on the second processor, the first processor determines the location of the congestion point based on the information.

[0274] In some optional embodiments, the information also includes execution context information generated when the second processor performs periodic tasks;

[0275] The first processor determines the location of the bottleneck based on the information, including:

[0276] Based on the execution context information, the first processor locates the line of code where congestion occurred during the execution of the task by the second processor, and identifies it as the congestion point.

[0277] In some optional embodiments, the method further includes:

[0278] Based on the execution context information, the first processor performs stack backtracking on the process of the second processor executing the task, and obtains the function call chain generated during the execution of the task by the second processor.

[0279] In some optional embodiments, the method further includes:

[0280] If the occupancy rate of the first processor reaches a preset second occupancy threshold, the first processor triggers the fifth processor to determine the bottleneck location based on the information of the second processor in the shared memory; if the occupancy rate of the fifth processor does not reach the preset second occupancy threshold.

[0281] In some optional embodiments, the fifth processor is triggered to determine the location of the bottleneck based on information from the second processor in shared memory, including:

[0282] The first processor sends a second adjustment instruction to a preset sixth processor, so that the sixth processor determines the fifth processor based on the utilization rate of at least one processor other than the first processor and the second processor, and sends a third trigger instruction to the fifth processor;

[0283] Alternatively, the first processor determines the fifth processor based on the utilization rate of at least one processor other than the first and second processors, and sends a fourth trigger instruction to the fifth processor.

[0284] This disclosure also provides a computer program product, including a computer program executed by a processor to perform a task congestion handling method, the method comprising:

[0285] The first processor obtains information generated by the second processor during the execution of its tasks from shared memory.

[0286] The first processor uses information to determine whether the task being run by the second processor is congested.

[0287] If the task being run by the second processor becomes congested, the first processor will output a congestion warning message for the second processor.

[0288] In some optional embodiments, the information includes the set running frequency, actual running time, and actual number of runs of the periodic task run by the second processor;

[0289] Based on the information, the first processor determines whether the task being run by the second processor is congested, including:

[0290] The first processor determines whether the periodic tasks running on the second processor are congested based on the set running frequency, actual running time, and actual number of runs of the periodic tasks running on the second processor.

[0291] In some optional embodiments, the first processor determines whether the periodic task being run by the second processor is congested based on the set running frequency, actual running time, and actual number of runs of the periodic task being run by the second processor, including:

[0292] The first processor determines the preset number of times the periodic task to be run by the second processor based on the set operating frequency and the actual running time.

[0293] The first processor determines whether the periodic tasks run by the second processor are congested based on the preset number of runs and the actual number of runs.

[0294] In some optional embodiments, the first processor determines whether the periodic task run by the second processor is congested based on a preset number of runs and the actual number of runs, including:

[0295] If the actual number of runs equals the preset number of runs, the first processor determines that the periodic tasks run by the second processor are not congested.

[0296] If the actual number of runs by the first processor is less than the preset number of runs, it waits for a preset time. If the actual number of runs of the periodic task run by the second processor does not change after the preset time, it is determined that the periodic task run by the second processor is congested.

[0297] In some optional embodiments, the shared memory stores the storage address of information about the second processor;

[0298] The first processor obtains information about the second processor from shared memory, including:

[0299] The first processor obtains the storage address of the second processor's information from the shared memory, and then obtains the second processor's information from that storage address.

[0300] In some optional embodiments, the method further includes:

[0301] If the utilization rate of the first processor reaches a preset first utilization rate threshold, the third processor is triggered to monitor whether the tasks running on the second processor are congested based on the information of the second processor in the shared memory; if the utilization rate of the third processor does not reach the preset first utilization rate threshold.

[0302] In some optional embodiments, a third processor is triggered to monitor whether the tasks running on the second processor are experiencing congestion, based on information from the second processor in shared memory, including:

[0303] The first processor sends a first adjustment instruction to a preset fourth processor, so that the fourth processor determines the third processor based on the utilization rate of at least one processor other than the first processor and the second processor, and sends a first trigger instruction to the third processor.

[0304] Alternatively, the first processor determines the third processor based on the utilization rate of at least one processor other than the first and second processors, and sends a second trigger instruction to the third processor.

[0305] In some optional embodiments, the method further includes:

[0306] When congestion occurs in the tasks running on the second processor, the first processor determines the location of the congestion point based on the information.

[0307] In some optional embodiments, the information also includes execution context information generated when the second processor performs periodic tasks;

[0308] The first processor determines the location of the bottleneck based on the information, including:

[0309] Based on the execution context information, the first processor locates the line of code where congestion occurred during the execution of the task by the second processor, and identifies it as the congestion point.

[0310] In some optional embodiments, the method further includes:

[0311] Based on the execution context information, the first processor performs stack backtracking on the process of the second processor executing the task, and obtains the function call chain generated during the execution of the task by the second processor.

[0312] In some optional embodiments, the method further includes:

[0313] If the occupancy rate of the first processor reaches a preset second occupancy threshold, the first processor triggers the fifth processor to determine the bottleneck location based on the information of the second processor in the shared memory; if the occupancy rate of the fifth processor does not reach the preset second occupancy threshold.

[0314] In some optional embodiments, the fifth processor is triggered to determine the location of the bottleneck based on information from the second processor in shared memory, including:

[0315] The first processor sends a second adjustment instruction to a preset sixth processor, so that the sixth processor determines the fifth processor based on the utilization rate of at least one processor other than the first processor and the second processor, and sends a third trigger instruction to the fifth processor;

[0316] Alternatively, the first processor determines the fifth processor based on the utilization rate of at least one processor other than the first and second processors, and sends a fourth trigger instruction to the fifth processor.

[0317] Some embodiments of this disclosure also provide a chip system, such as Figure 7 As shown, the chip system includes at least one processor 701 and at least one interface circuit 702. The processor 701 and the interface circuit 702 are interconnected via lines. For example, the interface circuit 702 can be used to receive signals from other devices (e.g., the memory of an electronic device). As another example, the interface circuit 702 can be used to send signals to other devices (e.g., the processor 701). Exemplarily, the interface circuit 702 can read instructions stored in memory and send those instructions to the processor 701. When the instructions are executed by the processor 701, the task congestion processing device can perform the steps in the above embodiments. Of course, the chip system may also include other discrete devices, and some embodiments of this disclosure do not specifically limit this.

[0318] In some embodiments of this disclosure, the interface circuit 702 can acquire data, program instructions, and / or information from the internal storage area of ​​the chip system; it can also acquire data, program instructions, and / or information from outside the chip system.

[0319] Optionally, the chip system also includes a memory 703, which is used to store necessary computer programs and data.

[0320] Those skilled in the art will also understand that the various illustrative logical blocks and steps listed in the embodiments of this application can be implemented by electronic hardware, computer software, or a combination of both. Whether such functionality is implemented through hardware or software depends on the specific application and the overall system design requirements. Those skilled in the art can implement the described functionality using various methods for each specific application, but such implementation should not be construed as exceeding the scope of protection of the embodiments of this application.

[0321] Furthermore, the term “exemplary” is used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “exemplary” is not necessarily to be construed as advantageous compared to other aspects or designs. Rather, the use of the term “exemplary” is intended to present the concept in a concrete manner. As used herein, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or.” That is, unless otherwise specified or clear from the context, “X applies A or B” is intended to mean any of the natural inclusive arrangements. That is, “X applies A or B” satisfies any of the foregoing instances if X applies A; X applies B; or both X applies A and B. Additionally, unless otherwise specified or clear from the context to refer to the singular form, the articles “a” and “an” as used in this application and the appended claims are generally understood to mean “one or more.”

[0322] Similarly, although this disclosure has been shown and described with respect to one or more implementations, equivalent variations and modifications will occur to those skilled in the art upon reading and understanding this specification and the accompanying drawings. This disclosure includes all such modifications and variations and is limited only by the scope of the claims. In particular, with respect to the various functions performed by the components described above (e.g., elements, resources, etc.), unless otherwise indicated, the terminology used to describe such components is intended to correspond to any component (functionally equivalent) that performs the specific function of the described component, even if structurally not equivalent to the disclosed structure. Furthermore, although specific features of this disclosure may have been disclosed with respect to only one of several implementations, such features may be combined with one or more other features of other implementations, as may be desired and advantageous to any given or particular application. Moreover, with regard to the terms “comprising,” “owning,” “having,” “having,” or variations thereof as used in the detailed description or claims, such terms are intended to be inclusive in a manner similar to the term “including.”

[0323] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0324] It should be understood that the module division in the embodiments of this application is illustrative and only represents a logical functional division. In actual implementation, there may be other division methods. Furthermore, the functional modules in the various embodiments of this application can be integrated into a single processor, exist as separate physical entities, or be integrated into a single module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0325] The terms "unit," "module," etc., used in this specification can be used to refer to computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution. In the embodiments of this application, "unit" and "module" have the same meaning and can be used interchangeably.

[0326] Those skilled in the art will recognize that the various illustrative logical blocks and steps described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application. In the several embodiments provided in this application, it should be understood that the disclosed apparatus, devices, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for example, the division of units is merely a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the shown or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0327] The unit described as a separate component may or may not be physically separate. The component shown as a unit may or may not be a physical unit; that is, it may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0328] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0329] In the above embodiments, the functions of each functional unit can be implemented entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. This computer program product includes one or more computer instructions (programs). When the computer program instructions (programs) are loaded and executed on a computer, all or part of the processes or functions illustrated in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs, DVDs), or semiconductor media (e.g., solid-state disks, SSDs), etc.

[0330] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the technology, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods shown in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

Claims

1. A method for handling task congestion, characterized in that, include: The first processor obtains information generated by the second processor during the execution of its tasks from shared memory. Based on the information, the first processor determines whether the task being run by the second processor is experiencing congestion; If the task being run by the second processor becomes congested, the first processor outputs a congestion warning message for the second processor.

2. The task congestion handling method according to claim 1, characterized in that, The shared memory contains the storage address of information about the second processor; The first processor obtains information about the second processor from the shared memory, including: The first processor obtains the storage address of the second processor's information from the shared memory, and obtains the second processor's information from that storage address.

3. The task congestion handling method according to claim 1, characterized in that, The information includes the set running frequency, actual running time, and actual number of runs of the periodic tasks run by the second processor; Based on the information, the first processor determines whether the task being run by the second processor is congested, including: The first processor determines whether the periodic task running by the second processor is congested based on the set running frequency, actual running time, and actual number of runs of the periodic task running by the second processor.

4. The task congestion handling method according to claim 3, characterized in that, The first processor determines whether the periodic task being run by the second processor is congested based on the set running frequency, actual running time, and actual number of runs of the periodic task being run by the second processor, including: The first processor determines the preset number of times the periodic task to be run by the second processor based on the set operating frequency and the actual running time; The first processor determines whether the periodic task run by the second processor is congested based on the preset number of runs and the actual number of runs.

5. The task congestion handling method according to claim 4, characterized in that, The first processor determines whether the periodic task run by the second processor is congested based on the preset number of runs and the actual number of runs, including: If the actual number of runs equals the preset number of runs, the first processor determines that the periodic task run by the second processor is not congested. If the actual number of runs is less than the preset number of runs, the first processor waits for a preset time. If the actual number of runs of the periodic task run by the second processor does not change after the preset time, it is determined that the periodic task run by the second processor is congested.

6. The task congestion handling method according to claim 1, characterized in that, The method further includes: When the first processor's occupancy rate reaches a preset first occupancy rate threshold, the first processor triggers the third processor to monitor whether the task running on the second processor is congested; the occupancy rate of the third processor does not reach the preset first occupancy rate threshold.

7. The task congestion handling method according to claim 6, characterized in that, The triggering of the third processor, based on information from the second processor in the shared memory, involves monitoring whether the tasks running on the second processor are experiencing congestion, including: The first processor sends a first adjustment instruction to a preset fourth processor, so that the fourth processor determines the third processor based on the utilization rate of at least one processor other than the first processor and the second processor, and sends a first trigger instruction to the third processor; Alternatively, the first processor determines the third processor based on the utilization rate of at least one processor other than the first processor and the second processor, and sends a second trigger instruction to the third processor.

8. The task congestion handling method according to any one of claims 1-7, characterized in that, The method further includes: When congestion occurs in the task being run by the second processor, the first processor determines the location of the congestion point based on the information.

9. The task congestion handling method according to claim 8, characterized in that, The information also includes execution context information generated when the second processor performs periodic tasks; Determining the location of the blockage based on the information includes: Based on the execution context information, the first processor locates the line of code where congestion occurred during the execution of the task by the second processor, and identifies it as the congestion point.

10. The task congestion handling method according to claim 9, characterized in that, The method further includes: Based on the execution context information, the first processor performs stack backtracking on the process of the second processor executing the task to obtain the function call chain generated during the execution of the task by the second processor.

11. The task congestion handling method according to claim 8, characterized in that, The method further includes: When the occupancy rate of the first processor reaches a preset second occupancy rate threshold, the first processor triggers the fifth processor to determine the bottleneck location based on the information of the second processor in the shared memory; the occupancy rate of the fifth processor does not reach the preset second occupancy rate threshold.

12. The task congestion handling method according to claim 11, characterized in that, The triggering of the fifth processor, based on information from the second processor in the shared memory, determines the location of the blockage, including: The first processor sends a second adjustment instruction to a preset sixth processor, so that the sixth processor determines the fifth processor based on the utilization rate of at least one processor other than the first processor and the second processor, and sends a third trigger instruction to the fifth processor; Alternatively, the first processor determines the fifth processor based on the utilization rate of at least one processor other than the first processor and the second processor, and sends a fourth trigger instruction to the fifth processor.

13. A task congestion handling device, characterized in that, include: The acquisition module is configured so that the first processor acquires information generated by the second processor during the execution of a task from shared memory; The judgment module is configured to determine, based on the information, whether the task being run by the second processor is experiencing congestion. The prompt module is configured to output a congestion prompt message for the second processor when the task being run by the second processor becomes congested.

14. The task congestion handling device according to claim 13, characterized in that, The shared memory contains the storage address of information about the second processor; The acquisition module is further configured to: The first processor obtains the storage address of the second processor's information from the shared memory, and obtains the second processor's information from that storage address.

15. The task congestion handling device according to claim 13, characterized in that, The information includes the set running frequency, actual running time, and actual number of runs of the periodic tasks run by the second processor; The judgment module is also configured to: The first processor determines whether the periodic task running by the second processor is congested based on the set running frequency, actual running time, and actual number of runs of the periodic task running by the second processor.

16. The task congestion handling device according to claim 15, characterized in that, The judgment module is also configured to: The first processor determines the preset number of times the periodic task to be run by the second processor based on the set operating frequency and the actual running time; The first processor determines whether the periodic task run by the second processor is congested based on the preset number of runs and the actual number of runs.

17. The task congestion handling device according to claim 16, characterized in that, The judgment module is also configured to: If the actual number of runs equals the preset number of runs, the first processor determines that the periodic task run by the second processor is not congested. If the actual number of runs is less than the preset number of runs, the first processor waits for a preset time. If the actual number of runs of the periodic task run by the second processor does not change after the preset time, it is determined that the periodic task run by the second processor is congested.

18. The task congestion handling device according to claim 13, characterized in that, The task congestion handling device also includes: The first triggering module is configured to trigger a third processing module to monitor whether the task running on the second processor is congested when the first processor's occupancy rate reaches a preset first occupancy rate threshold, as indicated by the first processor's occupancy status indicator; wherein the third processor's occupancy rate does not reach the preset first occupancy rate threshold.

19. The task congestion handling device according to claim 18, characterized in that, The first trigger module is also configured to: The first processor sends a first adjustment instruction to a preset fourth processor, so that the fourth processor determines the third processor based on the utilization rate of at least one processor other than the first processor and the second processor, and sends a first trigger instruction to the third processor; Alternatively, the first processor determines the third processor based on the utilization rate of at least one processor other than the first processor and the second processor, and sends a second trigger instruction to the third processor.

20. The task congestion handling apparatus according to any one of claims 13-19, characterized in that, The task congestion handling device also includes: The determination module is configured to determine the location of the congestion point based on the information when the first processor encounters congestion in the task being run by the second processor.

21. The task congestion handling device according to claim 20, characterized in that, The information also includes execution context information generated when the second processor performs periodic tasks; The determining module is further configured to: Based on the execution context information, the first processor locates the line of code where congestion occurred during the execution of the task by the second processor, and identifies it as the congestion point.

22. The task congestion handling device according to claim 21, characterized in that, The determining module is further configured to: Based on the execution context information, the first processor performs stack backtracking on the process of the second processor executing the task to obtain the function call chain generated during the execution of the task by the second processor.

23. The task congestion handling device according to claim 20, characterized in that, The task congestion handling device also includes: The second trigger module is configured to trigger the fifth processor to determine the bottleneck location based on the information of the second processor in the shared memory when the first processor's occupancy rate indicates that the first processor's occupancy rate has reached a preset second occupancy rate threshold; wherein the fifth processor's occupancy rate has not reached the preset second occupancy rate threshold.

24. The task congestion handling device according to claim 23, characterized in that, The second trigger module is also configured as follows: The first processor sends a second adjustment instruction to a preset sixth processor, so that the sixth processor determines the fifth processor based on the utilization rate of at least one processor other than the first processor and the second processor, and sends a third trigger instruction to the fifth processor; Alternatively, the first processor determines the fifth processor based on the utilization rate of at least one processor other than the first processor and the second processor, and sends a fourth trigger instruction to the fifth processor.

25. A control system, characterized in that, Includes a first processor, a second processor, and shared memory; The control system is used to employ the task congestion handling method according to any one of claims 1-12, wherein the first processor obtains information generated by the second processor during task execution from the shared memory; Based on the information, it is determined whether the task being run by the second processor is experiencing congestion; If the task running on the second processor becomes congested, a congestion warning message for the second processor will be output.

26. A vehicle, characterized in that, Includes the control system as described in claim 25.

27. A computer-readable storage medium, characterized in that, The storage medium stores a computer program or instructions that, when executed by a processor of an electronic device, enable the electronic device to perform a task congestion handling method, the method comprising: The first processor obtains information generated by the second processor during the execution of a task from the shared memory. Based on the information, the first processor determines whether the task being run by the second processor is experiencing congestion; If the task being run by the second processor becomes congested, the first processor outputs a congestion warning message for the second processor.

28. A computer program product, characterized in that, Includes a computer program, which is executed by a processor, a task congestion handling method, comprising: The first processor obtains information generated by the second processor during the execution of a task from the shared memory. Based on the information, the first processor determines whether the task being run by the second processor is experiencing congestion; If the task being run by the second processor becomes congested, the first processor outputs a congestion warning message for the second processor.

29. A chip system, characterized in that, The chip system includes a processing unit and an interface circuit. The processing unit obtains program instructions through the interface circuit, and the program instructions are executed by the processing unit. The processing unit is used to execute a task congestion handling method, including: The first processor obtains information generated by the second processor during the execution of a task from the shared memory. Based on the information, the first processor determines whether the task being run by the second processor is experiencing congestion; If the task being run by the second processor becomes congested, the first processor outputs a congestion warning message for the second processor.

Images