Vehicle-mounted process resource management method and system and vehicle
Through configuration files and Cgroup interfaces, the thread pool and thread attributes are dynamically adjusted, and the cross-platform API is provided, which solves the problems of insufficient resource management of onboard processes and low thread scheduling efficiency, and achieves efficient resource utilization and compatibility improvement.
Patent Information
- Application Number
- CN202411306869.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-19
- Publication Date
- 2025-01-17
AI Technical Summary
In the existing technology, inadequate resource management of on-vehicle processes, low thread scheduling efficiency and poor cross-platform compatibility lead to excessive resource utilization and waste, affecting processing speed and development difficulty.
By creating a configuration file to define resource limit parameters, calling the Cgroup interface to set resource limits, dynamically create and manage thread pools, configuring thread attributes and monitoring mechanisms, providing a cross-platform API interface to uniformly manage processes and thread resources.
It avoids excessive resource utilization and waste, improves thread execution efficiency and response speed, and reduces development difficulty and maintenance costs.
Smart Images

Figure CN119322666A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of vehicle technology, and in particular to a vehicle-mounted process resource management method, system, electronic equipment, storage medium and vehicle. Background Art
[0002] At present, in the development of intelligent driving and cockpit applications, the application logic involved is relatively complex and the scenarios are diverse. For storage-type applications, in order to improve the disk access speed and time, multi-threaded and multi-IO operations will be involved. For algorithm-type applications, in order to improve the calculation speed and shorten the response time, CPU calculation of high-frequency words will be involved. For communication middleware, the request or data of the upper-level application will be sent to the counterparty, which will increase memory consumption during the data flow process, especially for sensor data, such as camera, lidar, and radar. The data volume is relatively large and the frequency is high. Transmission through shared memory within the process will occupy system memory resources.
[0003] In the prior art, during the execution of an application process, there is no restriction on the CPU, memory, and IO of the current process, and no system resource management and control is performed on the process, resulting in the resource-consuming process being used and occupied indefinitely, thereby slowing down the processing speed of other application processes or causing insufficient resources, and the overall process running slowly;
[0004] Multiple threads are defined in the process to handle tasks. There is no personalized interface setting for thread scheduling strategy and thread priority. Instead, the system default solution is used, which does not achieve the optimal effect.
[0005] When creating a thread within a process, the system interface is called directly, which makes the thread unmonitorable and unmanageable. In addition, the creation and destruction of the thread will occupy resources and reduce the processing speed.
[0006] Therefore, the present application provides a vehicle process resource management method to solve the above technical problems. Summary of the invention
[0007] The purpose of the present invention is to provide a vehicle-mounted process resource management method, system, electronic device, storage medium and vehicle to solve the technical problems of insufficient resource management, low thread scheduling efficiency and poor cross-platform compatibility in the prior art.
[0008] In order to solve the above technical problems, the present invention provides a vehicle-mounted process resource management method, comprising:
[0009] Creating at least one configuration file for defining resource restriction parameters for each in-vehicle application process;
[0010] Read and parse the created configuration file to extract the resource restriction parameters of each vehicle application process;
[0011] Calling the Cgroup interface, creating a corresponding Cgroup for each in-vehicle application process based on the resource limit parameters, and setting corresponding resource limits;
[0012] In response to the in-vehicle application process being initialized, dynamically creating and managing a thread pool according to the resource restriction parameters;
[0013] Configure the thread attribute setting interface, which is used by the vehicle application process to dynamically configure the thread scheduling strategy, priority and affinity according to task requirements;
[0014] Configure the thread monitoring mechanism to monitor the execution time and status of each thread and recycle the corresponding threads;
[0015] Configure cross-platform API interfaces to uniformly call interfaces related to process resource management and thread management.
[0016] In some specific embodiments, creating at least one configuration file for defining resource restriction parameters of each vehicle application process further includes:
[0017] The configuration file includes a JSON configuration file, and the resource restriction parameters include a CPU usage restriction, a memory usage restriction, and an input and output operation restriction;
[0018] defining in the configuration file a unique identifier of each in-vehicle application process and the resource restriction parameters associated with the corresponding process;
[0019] Setting a default value and a maximum value for each of the resource limit parameters;
[0020] Defining the dependency of the resource restriction parameters for each in-vehicle application process in the configuration file, so as to consider the mutual influence between processes when allocating resources;
[0021] Setting a verification mechanism for verifying that the resource restriction parameters in the configuration file comply with the resource allocation strategy of the vehicle computing environment;
[0022] An update mechanism is provided to dynamically update the resource limitation parameters during the operation of the vehicle-mounted application process to adapt to different operation scenarios and performance requirements.
[0023] In some specific embodiments, in response to the in-vehicle application process being initialized, dynamically creating and managing a thread pool according to the resource restriction parameters further includes:
[0024] Create a thread pool management service to maintain the life cycle and status information of threads in the thread pool;
[0025] Implementing thread creation logic in the thread pool management service, including thread initialization, task allocation and execution;
[0026] Configure a dynamic adjustment mechanism to automatically adjust the thread pool size based on the real-time resource requirements of the vehicle application process and the system load;
[0027] Configure the resource recycling logic of the thread pool to remove threads from the thread pool when they are idle for a long time.
[0028] In some specific embodiments, a thread attribute setting interface is configured for the vehicle application process to dynamically configure the thread scheduling strategy, priority and affinity according to task requirements, further comprising:
[0029] Configure the thread scheduling strategy setting interface, which is used for the vehicle application process to select the scheduling strategy according to the real-time performance and computational complexity of the task;
[0030] Configure the thread priority setting interface to dynamically adjust the execution priority of the thread according to the importance of the task in the vehicle application process;
[0031] Configure the thread affinity setting interface, which is used by the vehicle application process to bind threads to specific CPU cores to reduce thread migration and context switching;
[0032] Configure a persistence mechanism for thread attribute settings so that the thread scheduling policy, priority, and affinity can be restored to their previous state after the vehicle application process is restarted.
[0033] In some specific embodiments, configuring a thread monitoring mechanism to monitor the execution time and state of each thread and recycle the corresponding thread further includes:
[0034] Configure the thread execution time monitoring mechanism to record the execution start and end time of each thread;
[0035] Configure the thread status monitoring mechanism to track the running status of each thread in real time, including ready, running, blocked and dead status;
[0036] Configure the thread task execution monitoring mechanism to monitor the execution progress and completion status of thread tasks;
[0037] Configure the thread resource recycling policy to recycle the resources of monitored threads that have no tasks to execute for a long time into the thread pool.
[0038] In some specific embodiments, a cross-platform API interface is configured to uniformly call interfaces related to process resource management and thread management, further comprising:
[0039] Configure the encapsulation of cross-platform API interfaces so that in-vehicle application processes under different operating systems can call resource management functions through a unified interface;
[0040] Configure the version management mechanism of the API interface so that the in-vehicle application process can seamlessly use the latest API interface during the upgrade or migration process;
[0041] Configure API interface security verification to ensure that only authorized vehicle application processes can call resource management related API interfaces;
[0042] Configure performance monitoring and optimization of the API interface to ensure the stability and response speed of the API interface under high concurrency and high load conditions.
[0043] Based on the same concept, the present invention also provides a vehicle-mounted process resource management system, comprising:
[0044] A configuration file setting and parsing module, configured to create at least one configuration file for defining resource restriction parameters of each vehicle application process;
[0045] Read and parse the created configuration file to extract the resource restriction parameters of each vehicle application process;
[0046] Calling the Cgroup interface, creating a corresponding Cgroup for each in-vehicle application process based on the resource limit parameters, and setting corresponding resource limits;
[0047] a thread pool management module configured to dynamically create and manage a thread pool according to the resource restriction parameters in response to initialization of the vehicle-mounted application process;
[0048] A thread attribute interface configuration module, configured as a thread attribute setting interface, is used for the vehicle application process to dynamically configure the thread scheduling strategy, priority and affinity according to task requirements;
[0049] A thread monitoring mechanism configuration module is configured to configure a thread monitoring mechanism to monitor the execution time and state of each thread and recycle the corresponding thread;
[0050] The cross-platform API interface configuration module is configured to configure the cross-platform API interface for uniformly calling interfaces related to process resource management and thread management.
[0051] Based on the same concept, the present invention also provides an electronic device, including: a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other through the communication bus; a computer program is stored in the memory, and when the computer program is executed by the processor, the processor executes the steps of the vehicle process resource management method.
[0052] Based on the same concept, the present invention also provides a computer-readable storage medium storing a computer program executable by an electronic device. When the computer program runs on the electronic device, the electronic device executes the steps of the vehicle process resource management method.
[0053] Based on the same concept, the present invention also provides a vehicle, wherein the vehicle is provided with the vehicle-mounted process resource management system as described above.
[0054] Compared with the prior art, the beneficial effects are:
[0055] The present invention discloses an on-vehicle process resource management method, system, electronic device, storage medium and vehicle, which avoid excessive occupation and waste of resources, improve the efficiency and response speed of thread execution, and reduce development difficulty and maintenance cost. BRIEF DESCRIPTION OF THE DRAWINGS
[0056] Figure 1 It is a flowchart of a vehicle process resource management method of the present invention in some specific embodiments;
[0057] Figure 2 It is a schematic diagram of the architecture of a vehicle process resource management method of the present invention in some applications;
[0058] Figure 3 It is a schematic diagram of a process resource interface calling flow of a vehicle-mounted process resource management method in some applications of the present invention;
[0059] Figure 4 It is a schematic diagram of thread scheduling parameters and thread pool creation process of a vehicle-mounted process resource management method in some applications of the present invention;
[0060] Figure 5 It is a schematic diagram of a data link for implementing a vehicle-mounted process resource management method of the present invention in some applications;
[0061] Figure 6 It is a schematic diagram of the structure of a vehicle-mounted process resource management system in some specific embodiments of the present invention;
[0062] Figure 7 It is a schematic diagram of the structure of an electronic device in some specific embodiments of the present invention. DETAILED DESCRIPTION
[0063] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present application.
[0064] The terms used in the embodiments of the present application are only for the purpose of describing specific embodiments, and are not intended to limit the present application. The singular forms "a", "said" and "the" used in the embodiments of the present application and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings, and "multiple" generally includes at least two.
[0065] It should be understood that the term "and / or" used in this article is only a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article generally indicates that the associated objects before and after are in an "or" relationship.
[0066] It should be understood that although the terms first, second, third, etc. may be used to describe in the embodiments of the present application, these descriptions should not be limited to these terms. These terms are only used to distinguish the descriptions. For example, without departing from the scope of the embodiments of the present application, the first may also be referred to as the second, and similarly, the second may also be referred to as the first.
[0067] As used herein, the words "if" and "if" may be interpreted as "at the time of" or "when" or "in response to determining" or "in response to detecting", depending on the context. Similarly, the phrases "if it is determined" or "if (stated condition or event) is detected" may be interpreted as "when it is determined" or "in response to determining" or "when detecting (stated condition or event)" or "in response to detecting (stated condition or event)", depending on the context.
[0068] It should also be noted that the term "includes", "comprising" or any other variation thereof is intended to cover non-exclusive inclusion, so that a commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprising a ..." do not exclude the existence of other identical elements in the commodity or device including the elements.
[0069] It should be particularly noted that any symbols and / or numbers in the specification that are not marked in the accompanying drawings are not drawing marks.
[0070] Reference Figure 1 , a vehicle process resource management method, comprising:
[0071] S101, creating at least one configuration file for defining resource restriction parameters of each vehicle-mounted application process; reading and parsing the created configuration file, extracting the resource restriction parameters of each vehicle-mounted application process; calling a Cgroup interface, creating a corresponding Cgroup for each vehicle-mounted application process based on the resource restriction parameters, and setting corresponding resource restrictions;
[0072] It is understandable that at least one configuration file is created to define the resource restriction parameters of each in-vehicle application process. The configuration file adopts JSON format for easy parsing and processing. For example, for an in-vehicle navigation application, its configuration file is as follows:
[0073]
[0074]
[0075] In this example, NavigationApp is the unique identifier of the in-vehicle navigation application. CpuLimit, MemoryLimit, and IoLimit define the CPU usage limit, memory usage limit, and IO operation limit of the application process, respectively.
[0076] The created configuration file is read and parsed through the configuration file parser. The parser can recognize the JSON format and extract the resource limit parameters of each vehicle application process from it. The parser stores the parameters in an internal data structure for use in subsequent steps.
[0077] For example, the parser parses the above JSON configuration file into the following internal representation:
[0078]
[0079] The Cgroup interface provided by the operating system is called, and based on the parsed resource limit parameters, a corresponding Cgroup is created for each in-vehicle application process, and corresponding resource limits are set.
[0080] For example, for the navigation app above, do the following:
[0081] CreateCgroup("NavigationApp",navigationAppLimits.cpuLimit,navigationAppLimits.memoryLimit,navigationAppLimits.ioLimit);
[0082] The CreateCgroup function is a hypothetical API call that receives the application name and resource limit parameters, then creates a Cgroup at the operating system level and configures its resource limits.
[0083] In some of the applications, at least one configuration file is created to define resource limitation parameters for each vehicle-mounted application process, the configuration file includes a JSON configuration file, and the resource limitation parameters include CPU usage limitation, memory usage limitation, and input and output operation limitation; a unique identifier for each vehicle-mounted application process and resource limitation parameters associated with the corresponding process are defined in the configuration file; a default value and a maximum value are set for each resource limitation parameter; a dependency relationship of the resource limitation parameters is defined for each vehicle-mounted application process in the configuration file to consider the mutual influence between processes when allocating resources; a verification mechanism is set to verify that the resource limitation parameters in the configuration file comply with the resource allocation strategy of the vehicle-mounted computing environment; and an update mechanism is set to dynamically update the resource limitation parameters of the vehicle-mounted application process at runtime to adapt to different operating scenarios and performance requirements.
[0084] It is understandable that one or more configuration files in JSON format are created to define resource restriction parameters of the vehicle application process. Each process has a unique identifier in the configuration file and is associated with corresponding resource restriction parameters.
[0085] For example, for the in-vehicle information system and the autonomous driving system, the configuration files are as follows:
[0086]
[0087]
[0088] In this example, InfotainmentSystem and AutoDriveSystem are unique identifiers of the in-vehicle application processes. The resource limit parameters for each process include CPU usage limit (CpuLimit), memory usage limit (MemoryLimit), and input and output operation limit (IoLimit). Each parameter is set with a default value and a maximum value to ensure flexibility and safety in resource allocation.
[0089] In the configuration file, the resource limit parameter dependencies between processes are defined.
[0090] For example, InfotainmentSystem depends on AutoDriveSystem, and when allocating resources, the system will consider the resource requirements and mutual impact of these two processes.
[0091] Set up a verification mechanism to verify whether the resource restriction parameters in the configuration file comply with the resource allocation strategy of the vehicle computing environment. This includes checking whether the parameter value is within the defined maximum and default ranges, and whether it meets the resource allocation rules of the vehicle system.
[0092] In order to adapt to different operating scenarios and performance requirements, a mechanism for dynamically updating resource limitation parameters is provided for vehicle application processes.
[0093] For example, when the in-vehicle information system detects that the user is playing a video, it will request to increase its CPU usage limit and memory usage limit. The update request is implemented through the following API call:
[0094] UpdateResourceLimits("InfotainmentSystem",{"CpuLimit":"40%","MemoryLimit":"384MB"});
[0095] The UpdateResourceLimits function is a hypothetical API call that receives the application name and updated resource limit parameters, and then dynamically adjusts the resource limits of the application process.
[0096] S102, in response to the in-vehicle application process being initialized, dynamically creating and managing a thread pool according to the resource restriction parameters;
[0097] It can be understood that threads in the thread pool are dynamically created and managed, the size of the thread pool is automatically adjusted according to the real-time resource requirements of the on-board application process and the system load, and thread resources that have been idle for a long time are effectively recycled to improve the overall performance and resource utilization of the system.
[0098] In some of these applications, in response to the initialization of the in-vehicle application process, a thread pool is dynamically created and managed according to resource limitation parameters, and a thread pool management service is created to maintain the life cycle and status information of threads in the thread pool; thread creation logic is implemented in the thread pool management service, including thread initialization, task allocation and execution; a dynamic adjustment mechanism is configured to automatically adjust the size of the thread pool according to the real-time resource requirements and system load of the in-vehicle application process; and the resource recovery logic of the thread pool is configured to remove threads from the thread pool when there are threads that have been idle for a long time.
[0099] It is understandable that when the in-vehicle application process is initialized, the resource limitation parameters of the process are read.
[0100] For example, for an in-car navigation application, the resource restriction parameters are as follows:
[0101]
[0102] Create a thread pool management service based on the resource limit parameters of the vehicle application process. This service is responsible for maintaining the life cycle and status information of the threads in the thread pool. The creation of the thread pool management service can be implemented through the following pseudo code:
[0103] ThreadPoolManager navigationThreadPool=newThreadPoolManager("NavigationApp",maxThreads,minThreads);
[0104] Among them, maxThreads and minThreads are determined according to the resource limit parameters defined in the configuration file.
[0105] In the thread pool management service, the thread creation logic is implemented, including thread initialization, task allocation and execution. The thread creation can be implemented by the following pseudo code:
[0106]
[0107] In order to automatically adjust the thread pool size according to the real-time resource requirements of the vehicle application process and the system load, the thread pool management service is configured with a dynamic adjustment mechanism. This mechanism can be implemented by the following pseudo code:
[0108]
[0109] In order to effectively utilize resources, when there are threads that are idle for a long time, configure the resource recycling logic of the thread pool to remove these threads from the thread pool. The resource recycling logic can be implemented by the following pseudo code:
[0110]
[0111]
[0112] In the above embodiment, the getSystemLoad() function is used to obtain the current system load, highLoadThreshold and lowLoadThreshold are preset load thresholds for triggering thread pool size adjustment, and idleThreshold is a preset idle time threshold for determining whether a thread is idle for a long time.
[0113] S103, configuring a thread attribute setting interface, which is used by the vehicle application process to dynamically configure the thread scheduling strategy, priority and affinity according to task requirements;
[0114] It can be understood that flexibly configuring the scheduling policy, priority, and affinity of threads, and ensuring that these properties can be persisted and restored after the process restart, can improve the overall performance and responsiveness of the system.
[0115] In some of these applications, a thread attribute setting interface is configured, which is used for the vehicle-mounted application process to dynamically configure the scheduling strategy, priority and affinity of the thread according to task requirements; a thread scheduling strategy setting interface is configured, which is used for the vehicle-mounted application process to select the scheduling strategy according to the real-time and computational complexity of the task; a thread priority setting interface is configured, which is used for the vehicle-mounted application process to dynamically adjust the execution priority of the thread according to the importance of the task; a thread affinity setting interface is configured, which is used for the vehicle-mounted application process to bind the thread to a specific CPU core to reduce thread migration and context switching; a thread attribute setting persistence mechanism is configured, which is used to restore the thread scheduling strategy, priority and affinity to the previous state after the vehicle-mounted application process is restarted.
[0116] It is understandable that a thread scheduling strategy setting interface is provided to allow the vehicle application process to select the most appropriate scheduling strategy according to the real-time nature and computational complexity of the task.
[0117] For example, for tasks that require fast response, such as emergency braking systems, a real-time scheduling strategy can be selected. The following is an example implementation of the scheduling strategy setting interface:
[0118]
[0119]
[0120] Among them, SchedulingPolicy is an enumeration type that defines different scheduling policies, such as REAL_TIME, NORMAL, BACKGROUND, etc.
[0121] The vehicle application process can call this interface as follows:
[0122] Thread emergencyThread=getThreadById("emergency_braking_thread");
[0123] setThreadSchedulingPolicy(emergencyThread,SchedulingPolicy.REAL_TIME);
[0124] Provides a thread priority setting interface to allow the vehicle application process to dynamically adjust the execution priority of the thread according to the importance of the task.
[0125] For example, for high-priority tasks, such as navigation updates, you can set a higher priority. The following is an example implementation of the priority setting interface:
[0126] void setThreadPriority(Thread thread,int priority){
[0127] thread.setPriority(priority);
[0128] }
[0129] Among them, priority is an integer value, which indicates the priority of the thread. The larger the value, the higher the priority.
[0130] The vehicle application process can call this interface as follows:
[0131] Thread navigationUpdateThread=getThreadById("navigation_update_thread");
[0132] setThreadPriority(navigationUpdateThread,HIGH_PRIORITY);
[0133] Provides a thread affinity setting interface that allows the vehicle application process to bind threads to specific CPU cores to reduce thread migration and context switching. The following is an example implementation of the affinity setting interface:
[0134]
[0135]
[0136] Where cpuCoreIds is a list of integers representing the CPU core IDs on which the thread should run.
[0137] The vehicle application process can call this interface as follows:
[0138] Thread computeIntensiveThread=getThreadById("compute_intensive_thread");
[0139] List <integer>coreIds=Arrays.asList(0,1);
[0140] setThreadAffinity(computeIntensiveThread,coreIds);
[0141] In order to restore the thread scheduling policy, priority, and affinity after the in-vehicle application process is restarted, a persistence mechanism is configured. This mechanism saves the current properties of the thread to persistent storage and reapplies these properties when the process is restarted. The following is an example implementation of the persistence mechanism:
[0142]
[0143] Among them, PersistentStorage is a hypothetical persistent storage class, and ThreadAttributes is a class used to store thread attributes. When the in-vehicle application process is started, the restoreThreadAttributes method can be called to restore the thread attributes.
[0144] S104, configuring a thread monitoring mechanism to monitor the execution time and state of each thread and recycle the corresponding thread;
[0145] It can be understood that monitoring the execution time and status of threads and timely recovering thread resources that have been idle for a long time can improve the overall performance and resource utilization of the system.
[0146] In some of the applications, a thread monitoring mechanism is configured to monitor the execution time and status of each thread and recycle the corresponding threads; a thread execution time monitoring mechanism is configured to record the execution start time and end time of each thread; a thread status monitoring mechanism is configured to track the running status of each thread in real time, including ready, running, blocked and dead status; a thread task execution monitoring mechanism is configured to monitor the execution progress and completion status of thread tasks; a thread resource recovery strategy is configured to recycle the resources of a monitored thread that has no task execution for a long time into the thread pool.
[0147] It is understandable that a thread execution time monitoring mechanism is configured to record the execution start time and end time of each thread.
[0148] For example, this can be achieved by adding a timestamp attribute to the thread object. Each thread object can contain the following attributes:
[0149]
[0150] When the thread starts executing, record the start time:
[0151] void onStartThreadExecution(Thread thread){
[0152] thread.setStartTime(System.currentTimeMillis());
[0153] }
[0154] When the thread execution ends, the end time is recorded:
[0155] void onEndThreadExecution(Thread thread){
[0156] thread.setEndTime(System.currentTimeMillis());
[0157] }
[0158] Configure a thread status monitoring mechanism to track the running status of each thread in real time, including ready, running, blocked, and dead states.
[0159] For example, this can be achieved by maintaining a state machine that updates the state of the thread based on the thread's events:
[0160]
[0161] Configure a thread task execution monitoring mechanism to monitor the execution progress and completion status of thread tasks.
[0162] For example, this can be achieved by adding progress and completion status properties to the task object:
[0163]
[0164]
[0165] The thread updates the task progress while executing the task:
[0166] void updateTaskProgress(Task task,double progress){
[0167] task.setProgress(progress);
[0168] }
[0169] After the task is completed, update the task completion status:
[0170] void onTaskCompletion(Task task){
[0171] task.setCompleted(true);
[0172] }
[0173] Configure a thread resource recycling strategy to recycle the resources of a thread back to the thread pool when a thread that has no tasks to execute for a long time is monitored.
[0174] For example, this can be achieved by the following steps:
[0175] 1. Check the thread's idle time regularly.
[0176] 2. If the thread idle time exceeds the preset threshold, its resources will be recycled.
[0177]
[0178] Among them, ThreadPool is a class for managing thread pools, and reclaimThreadResources is a method used to reclaim thread resources and return them to the thread pool.
[0179] S105, configuring a cross-platform API interface for uniformly calling interfaces related to process resource management and thread management.
[0180] It is understandable that a unified resource management interface is provided for in-vehicle application processes under different operating systems, and the security, version compatibility and performance stability of the API interface under high load conditions are ensured.
[0181] In some of these applications, cross-platform API interfaces are configured to uniformly call interfaces related to process resource management and thread management; cross-platform API interface encapsulation is configured so that vehicle-mounted application processes under different operating systems can call resource management functions through a unified interface; a version management mechanism for the API interface is configured so that vehicle-mounted application processes can seamlessly use the latest API interface during the upgrade or migration process; security verification of the API interface is configured to ensure that only authorized vehicle-mounted application processes can call API interfaces related to resource management; performance monitoring and optimization of the API interface are configured to ensure the stability and response speed of the API interface under high concurrency and high load conditions.
[0182] It is understandable that a set of cross-platform API interfaces is designed so that vehicle-mounted application processes under different operating systems can call resource management functions through a unified interface.
[0183] For example, you can create a class called CrossPlatformResourceManager that provides a series of methods to manage process and thread resources that can be recognized and called by different operating systems.
[0184]
[0185]
[0186] In order to ensure that the in-vehicle application process can seamlessly use the latest API interface during the upgrade or migration process, a version management mechanism for the API interface is implemented.
[0187] For example, this can be achieved by including a version number in the API call, or by maintaining an API version mapping table to manage different versions of the API.
[0188]
[0189] In order to ensure that only authorized in-vehicle application processes can call resource management-related API interfaces, a security verification mechanism for the API interface is implemented.
[0190] This can be accomplished, for example, by validating an authorization token or digital certificate of the calling process.
[0191]
[0192]
[0193] In order to ensure the stability and response speed of the API interface under high concurrency and high load conditions, a performance monitoring and optimization mechanism for the API interface is implemented.
[0194] For example, this can be achieved by monitoring the response time of API calls and system resource usage, and optimizing as needed.
[0195]
[0196]
[0197] Assume that a cross-platform navigation application needs to run on Linux and QNX operating systems. The navigation application sets its resource limits by calling the setProcessResourceLimits method of the CrossPlatformResourceManager class. When the application is upgraded to a new version, APIVersionManager ensures that the application can seamlessly switch to the new version of the API. At each API call, the secureAPICall method verifies the application's authorization token to ensure security. At the same time, APIPerformanceMonitor monitors the performance of API calls and optimizes when performance bottlenecks are detected.
[0198] Combine the following Figures 2 to 5 The following describes the embodiments of the vehicle process resource management method of the present invention in some applications:
[0199] This embodiment uses configuration files to limit system resources cpu, memory, and io for each application, and can configure each process independently. In terms of system resource management, control is allocated separately for each scenario.
[0200] Based on the thread interface of the operating system, the thread pool is encapsulated and an API interface is provided. When the process is initialized, the number of threads to be created is determined by the process input parameters, and empty tasks are pre-applied in the thread pool to reduce the time required for dynamic thread creation;
[0201] Provides an interface to set thread properties, including thread scheduling policy, thread priority, and affinity;
[0202] Provide single-instance thread monitoring, monitor the execution time and status of threads created in the current process, and report threads that have no tasks for a long time to the thread pool, which will recycle them to save resources;
[0203] Provides cross-system portable API interfaces that can be ported to Android, QNX, and Linux, shortening the development cycle and improving development efficiency.
[0204] like Figure 2 As shown, in order to achieve configurable management of process resources, personalized configuration of thread execution priority, affinity, and scheduling strategy, a cross-platform porting API interface is provided, and ThreadPool and the CPU, memory, and IO resource information of the process are encapsulated based on the operating system. The resource information of the process is defined in the json configuration file, and the defined fields are as follows: CpuLimit, MemoryLimit, IoLimit, which are parsed through Json. After the information is read, the system Cgroup is called through libcgroup to set the parameter value and create the corresponding process. After the process is created, the thread pool size is created according to the input parameters in the creation process. In order to prevent the thread pool from being created infinitely, the maximum number of thread pools will be set. When the maximum thread pool setting value is exceeded, the creation fails. In the thread creation process, the thread creation and destruction interface is encapsulated based on the system's posix interface. The interface is used to set and obtain the thread's scheduling parameters, scheduling strategy, priority, and affinity.
[0205] like Figure 3 As shown, the application calls the provided API interface, the platform is not limited to Android, QNX, and Linux, creates an object, parses the configuration file related to the process resource setting and caches it in the map, calls the system interface, and sets the above parameters.
[0206] like Figure 4 As shown, the functional API interface for setting and obtaining thread scheduling parameters, scheduling policies, priorities, and affinities can be directly called by the application and set to the threads created in the process, and can also be set to the threads in the thread pool after creating the thread pool object. The thread pool is based on the system thread encapsulation. During the thread pool creation process, it supports setting thread scheduling policies, priorities, and affinities. The application can reasonably divide and use threads under different scheduling parameters and reasonably allocate CPU resources. After the thread pool is created, create an empty task and submit it to the thread pool, wait for the application to obtain the empty task from the thread pool, reassign a new task, and execute it. In addition, a singleton ThreadPoolMonitor will be created inside the process to monitor the thread execution status and thread task execution time of all thread pools in the current process.
[0207] This embodiment is described below in conjunction with application scenarios:
[0208] like Figure 5 As shown, the first case: manage the threads within the process, and the application process calls the thread creation and management interface. When creating the thread, the thread scheduling parameters, scheduling policy, thread affinity and priority are set.
[0209] The second case: the application process calls the exposed API interface to create a cgroup object. When creating the process object, it reads the configuration file of the current process, parses the setting parameters of the process's Cpu, Memory, and IO, and calls the system interface to set the parameter values of the current process. After the process is created, the thread pool creation interface is called to create threads in the current thread pool according to the configuration items of the thread pool, and set the thread scheduling parameters, scheduling policies, thread affinity, and priority. After the thread is created, an empty task is created and submitted to the task queue. When the application object needs to execute tasks in parallel, it obtains an empty task pointer from the task queue, assigns the task function to be executed to the task pointer, and submits the task to the task queue.
[0210] For the method steps disclosed in the above embodiments, the method steps are described as a series of action combinations for the purpose of simple description, but those skilled in the art should know that the embodiments of the present invention are not limited by the order of the actions described, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of the present invention.
[0211] like Figure 6 As shown, the present invention also provides a vehicle-mounted process resource management system, comprising:
[0212] The configuration file setting and parsing module 201 is configured to create at least one configuration file for defining resource restriction parameters of each vehicle-mounted application process; read and parse the created configuration file to extract the resource restriction parameters of each vehicle-mounted application process; call the Cgroup interface, create a corresponding Cgroup for each vehicle-mounted application process based on the resource restriction parameters, and set corresponding resource restrictions;
[0213] The thread pool management module 202 is configured to dynamically create and manage the thread pool according to the resource restriction parameters in response to the initialization of the vehicle application process;
[0214] The thread attribute interface configuration module 203 is configured to configure the thread attribute setting interface, which is used for the vehicle application process to dynamically configure the thread scheduling strategy, priority and affinity according to the task requirements;
[0215] The thread monitoring mechanism configuration module 204 is configured to configure a thread monitoring mechanism to monitor the execution time and state of each thread and recycle the corresponding thread;
[0216] The cross-platform API interface configuration module 205 is configured to configure a cross-platform API interface for uniformly calling interfaces related to process resource management and thread management.
[0217] It is worth noting that although only some basic functional modules are disclosed in the embodiments of the present invention, it does not mean that the composition of the present system is limited to the above basic functional modules. On the contrary, what the present embodiment wants to express is that on the basis of the above basic functional modules, those skilled in the art can arbitrarily add one or more functional modules in combination with the prior art to form an infinite number of embodiments or technical solutions. In other words, the present system is open rather than closed. Just because the present embodiment only discloses individual basic functional modules, it cannot be considered that the protection scope of the claims of the present invention is limited to the disclosed basic functional modules. At the same time, for the convenience of description, the above devices are described in terms of functions and are described separately in various units and modules. Of course, when implementing the present invention, the functions of each unit and module can be implemented in the same or one or more software and / or hardware.
[0218] like Figure 7 As shown, the present invention also provides an electronic device, comprising: a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other through the communication bus; a computer program is stored in the memory, and when the computer program is executed by the processor, the processor executes the steps of the vehicle process resource management method.
[0219] Figure 7 Schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. Figure 7 The electronic device provided in the embodiment of the present invention includes: one or more processors 710 and a storage device 720; the processor 710 in the electronic device may be one or more, Figure 7 A processor 710 is taken as an example; the storage device 720 is used to store one or more programs; the one or more programs are executed by the one or more processors 710, so that the one or more processors 710 implement the vehicle process resource management method as described in any one of the embodiments of the present invention.
[0220] The electronic device may further include: an input device 730 and an output device 740 .
[0221] The processor 710, storage device 720, input device 730 and output device 740 in the electronic device can be connected via a bus or other means. Figure 7 The example of connecting through bus is taken in the following.
[0222] The storage device 720 in the electronic device is a computer-readable storage medium that can be used to store one or more programs, which can be software programs, computer executable programs, and modules, such as program instructions / modules corresponding to the vehicle process resource management method provided in the embodiment of the present invention. The processor 710 executes various functional applications and data processing of the electronic device by running the software programs, instructions, and modules stored in the storage device 720, that is, the vehicle process resource management method in the above method embodiment is implemented.
[0223] The storage device 720 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created according to the use of the electronic device, etc. In addition, the storage device 720 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some instances, the storage device 720 may further include a memory remotely arranged relative to the processor 710, and these remote memories may be connected to the device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.
[0224] The input device 730 may be used to receive input digital or character information and generate key signal input related to user settings and function control of the electronic device. The output device 740 may include a display device such as a display screen.
[0225] The present invention also provides a computer-readable storage medium storing a computer program executable by an electronic device. When the computer program runs on the electronic device, the electronic device executes the steps of the vehicle process resource management method.
[0226] Specifically, the computer storage medium of the embodiment of the present invention can adopt any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples (non-exhaustive list) of computer-readable storage media include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present embodiment, the computer-readable storage medium can be any tangible medium containing or storing a program, which can be used by an instruction execution system, device or device or used in combination with it.
[0227] The present invention also provides a vehicle, wherein the vehicle is provided with the vehicle-mounted process resource management system as described above.
[0228] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.< / integer>
Claims
1. A vehicle-mounted process resource management method, characterized in that: include: Creating at least one configuration file for defining resource restriction parameters for each in-vehicle application process; Read and parse the created configuration file to extract the resource restriction parameters of each vehicle application process; Calling the Cgroup interface, creating a corresponding Cgroup for each in-vehicle application process based on the resource limit parameters, and setting corresponding resource limits; In response to the in-vehicle application process being initialized, dynamically creating and managing a thread pool according to the resource restriction parameters; Configure the thread attribute setting interface, which is used by the vehicle application process to dynamically configure the thread scheduling strategy, priority and affinity according to task requirements; Configure the thread monitoring mechanism to monitor the execution time and status of each thread and recycle the corresponding threads; Configure cross-platform API interfaces to uniformly call interfaces related to process resource management and thread management.
2. The vehicle process resource management method according to claim 1, characterized in that: Creating at least one configuration file for defining resource restriction parameters for each vehicle application process, further comprising: The configuration file includes a JSON configuration file, and the resource restriction parameters include a CPU usage restriction, a memory usage restriction, and an input and output operation restriction; defining in the configuration file a unique identifier of each in-vehicle application process and the resource restriction parameters associated with the corresponding process; Setting a default value and a maximum value for each of the resource limit parameters; Defining the dependency of the resource restriction parameters for each in-vehicle application process in the configuration file, so as to consider the mutual influence between processes when allocating resources; Setting a verification mechanism for verifying that the resource restriction parameters in the configuration file comply with the resource allocation strategy of the vehicle computing environment; An update mechanism is provided to dynamically update the resource limitation parameters during the operation of the vehicle-mounted application process to adapt to different operation scenarios and performance requirements.
3. The vehicle process resource management method according to claim 1, characterized in that: In response to the in-vehicle application process being initialized, dynamically creating and managing a thread pool according to the resource restriction parameters further includes: Create a thread pool management service to maintain the life cycle and status information of threads in the thread pool; Implementing thread creation logic in the thread pool management service, including thread initialization, task allocation and execution; Configure a dynamic adjustment mechanism to automatically adjust the thread pool size based on the real-time resource requirements of the vehicle application process and the system load; Configure the resource recycling logic of the thread pool to remove threads from the thread pool when they are idle for a long time.
4. The vehicle-mounted process resource management method according to claim 1, characterized in that: The thread attribute setting interface is used for the vehicle application process to dynamically configure the thread scheduling strategy, priority and affinity according to the task requirements, further including: Configure the thread scheduling strategy setting interface, which is used for the vehicle application process to select the scheduling strategy according to the real-time performance and computational complexity of the task; Configure the thread priority setting interface to dynamically adjust the execution priority of the thread according to the importance of the task in the vehicle application process; Configure the thread affinity setting interface, which is used by the vehicle application process to bind threads to specific CPU cores to reduce thread migration and context switching; Configure a persistence mechanism for thread attribute settings so that the thread scheduling policy, priority, and affinity can be restored to their previous state after the vehicle application process is restarted.
5. The vehicle-mounted process resource management method according to claim 1, characterized in that: Configure the thread monitoring mechanism to monitor the execution time and status of each thread and recycle the corresponding thread, further including: Configure the thread execution time monitoring mechanism to record the execution start and end time of each thread; Configure the thread status monitoring mechanism to track the running status of each thread in real time, including ready, running, blocked and dead status; Configure the thread task execution monitoring mechanism to monitor the execution progress and completion status of thread tasks; Configure the thread resource recycling policy to recycle the resources of monitored threads that have no tasks to execute for a long time into the thread pool.
6. The vehicle-mounted process resource management method according to claim 1, characterized in that: Configuring a cross-platform API interface for uniformly calling interfaces related to process resource management and thread management further includes: Configure the encapsulation of cross-platform API interfaces so that in-vehicle application processes under different operating systems can call resource management functions through a unified interface; Configure the version management mechanism of the API interface so that the in-vehicle application process can seamlessly use the latest API interface during the upgrade or migration process; Configure API interface security verification to ensure that only authorized vehicle application processes can call resource management related API interfaces; Configure performance monitoring and optimization of the API interface to ensure the stability and response speed of the API interface under high concurrency and high load conditions.
7. A vehicle-mounted process resource management system, characterized in that: include: A configuration file setting and parsing module, configured to create at least one configuration file for defining resource restriction parameters of each vehicle application process; Read and parse the created configuration file to extract the resource restriction parameters of each vehicle application process; Calling the Cgroup interface, creating a corresponding Cgroup for each in-vehicle application process based on the resource limit parameters, and setting corresponding resource limits; a thread pool management module configured to dynamically create and manage a thread pool according to the resource restriction parameters in response to initialization of the vehicle-mounted application process; A thread attribute interface configuration module, configured as a thread attribute setting interface, is used for the vehicle application process to dynamically configure the thread scheduling strategy, priority and affinity according to task requirements; A thread monitoring mechanism configuration module is configured to configure a thread monitoring mechanism to monitor the execution time and state of each thread and recycle the corresponding thread; The cross-platform API interface configuration module is configured to configure the cross-platform API interface for uniformly calling interfaces related to process resource management and thread management.
8. An electronic device, characterized in that: include: A processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus; a computer program is stored in the memory, and when the computer program is executed by the processor, the processor executes the steps of the method described in any one of claims 1 to 6.
9. A computer-readable storage medium, characterized in that: It stores a computer program executable by an electronic device, and when the computer program runs on the electronic device, the electronic device executes the steps of the method described in any one of claims 1 to 6.
10. A vehicle, characterized in that: The vehicle is provided with the on-board process resource management system as claimed in claim 7.
Citation Information
Cited By
PreemptRT-based application real-time automatic optimization method and system
CN120276870A
Process execution management and processing method of vehicle-mounted SOC
CN121680963A