System and method for vehicle controller multi-core system access to shared resources

Abstract

The application discloses a kind of vehicle controller multi-core system access shared resource system and method, including access information acquisition module, inter-core interrupt information determination module, inter-core interrupt sending module, shared resource access module, notification module;The application combines the application scene of automobile embedded system, the protection of inter-core shared resource is realized by the mode of inter-core interrupt request, relative to the traditional resource lock scheme, can more efficiently, quickly complete the protection of shared resource, improve the response speed and real-time performance of system;Ensure that shared resource access does not conflict, to avoid complex resource lock management and scheduling operation, improve the performance and stability of system;Meanwhile, by setting different priority inter-core interrupt request, the locked kernel can respond higher priority interrupt, to realize more fine scheduling management, can better adapt to different application scenarios and system requirements.

Description

Technical Field

[0001] This invention belongs to the field of shared resource access and scheduling technology in automotive embedded multi-core systems, specifically relating to a system and method for accessing shared resources in an automotive controller multi-core system. Background Technology

[0002] On multi-core processors, when multiple kernels need to share the same resource, a certain method is required to protect access to the shared resource. The traditional method is to achieve mutual exclusion access to the shared resource through resource locks. That is, a state variable of a shared resource is defined by atomic instructions or hardware peripherals that satisfy atomic operations, which represents its current access state. This is called defining a resource lock (or spinlock). When the kernel needs to access the shared resource, it prevents conflicts in accessing the shared resource by requesting, polling, waiting, and releasing the spinlock.

[0003] Resource locking is a general-purpose, high-granularity resource management solution widely used in general-purpose computer systems. However, implementing resource locks consumes significant system resources and requires handling numerous edge cases when accessing shared resources, resulting in substantial system overhead. Furthermore, the complexity increases with the number of defined resource locks, necessitating additional consideration of issues such as deadlocks and reducing system stability.

[0004] In automotive embedded systems, various hardware interrupt events need to be handled, requiring high real-time performance. Changes in resource lock states necessitate polling or asynchronous checks of their status by each kernel, which impacts real-time system response and is unsuitable for automotive embedded real-time system applications. Furthermore, commonly used multi-core chips have limited available resources, and traditional resource lock solutions further degrade system performance. Additionally, considering the relatively simple scenarios for inter-core access to shared resources in automotive embedded systems, this is primarily reflected in two aspects: First, automotive embedded applications statically determine the tasks and interrupts running by each kernel and the various scenarios for inter-core access to shared resources during the development phase, eliminating the possibility of dynamically creating new tasks and interrupts that could lead to unexpected inter-core access. Second, the common inter-core resource access scenario in automotive embedded systems involves two kernels reading and writing to a shared memory location separately, with few instances of multiple kernels writing simultaneously. Summary of the Invention

[0005] To address the issues of high system overhead and potential deadlocks and resource contention that can result from accessing shared resources in automotive embedded systems, this invention proposes a system and method for accessing shared resources in a multi-core automotive controller system.

[0006] A system for accessing shared resources in a multi-core automotive controller system to achieve one of the objectives of this invention includes an access information acquisition module, an inter-core interrupt information determination module, an inter-core interrupt sending module, a shared resource access module, and a notification module.

[0007] The access information acquisition module is used to acquire access information of the shared resource to be accessed; the access information includes the access methods and interrupt priorities of one or more other kernels Core1 to CoreX that may cause access conflicts to access the shared resource, X≧1;

[0008] The inter-core interrupt information determination module is used to determine the interrupt type and interrupt priority of the inter-core interrupt sent to kernels Core1 to CoreX based on the access information of kernels Core1 to CoreX to access the shared resource; the inter-core interrupt is used to prevent kernels Core1 to CoreX from accessing the shared resource to be accessed within a set time period;

[0009] The inter-core interrupt sending module is used to send inter-core interrupts to kernels Core1 to CoreX one by one according to the determined inter-core interrupt type and interrupt priority;

[0010] The shared resource access module is used to access the shared resource to be accessed after all inter-core interrupts have been responded to;

[0011] The notification module is used to notify the kernels Core1 to CoreX to exit the inter-core interrupt of this response after the shared resource access is completed.

[0012] A method for accessing shared resources in a multi-core automotive controller system to achieve the second objective of this invention includes the following steps:

[0013] S1. Obtain access information for the shared resource to be accessed; the access information includes the access methods and interrupt priorities of one or more other kernels Core1 to CoreX that may cause access conflicts to access the shared resource, X≧1;

[0014] S2. Determine the interrupt type and interrupt priority of the inter-core interrupt sent to kernels Core1 to CoreX based on the access information of kernels Core1 to CoreX to the shared resource; the inter-core interrupt is used to prevent kernels Core1 to CoreX from accessing the shared resource to be accessed within a set time period;

[0015] S3. Based on the determined inter-core interrupt type and priority, send inter-core interrupts to kernels Core1 to CoreX one by one; after all inter-core interrupts have been responded to, start accessing the shared resource to be accessed;

[0016] S4. After the shared resource access is completed, notify the kernel Core1 to CoreX to exit the inter-core interrupt.

[0017] Beneficial effects:

[0018] 1. This invention protects shared resources between kernels by using inter-kernel interrupt requests, and pre-sets locking events to prevent deadlocks and other abnormal situations. Compared with traditional resource lock schemes, it can protect shared resources more efficiently and quickly, improving the system's response speed and real-time performance.

[0019] 2. This solution is designed for automotive embedded systems. When the number of kernels is small and the time spent accessing shared resources is short, one or more kernels can be stopped directly to ensure that there are no conflicts in accessing shared resources. This avoids complex resource lock management and scheduling operations and improves the performance and stability of the system.

[0020] 3. By setting different priorities for inter-core interrupt requests, locked kernels can respond to higher-priority interrupts, thereby achieving more granular scheduling management and better adapting to different application scenarios and system requirements. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of the structure of the present invention;

[0022] Figure 2 This is a diagram illustrating the access types and interrupt priorities for shared resource access.

[0023] Figure 3 This is a flowchart illustrating the process of accessing shared resources. Detailed Implementation

[0024] The following detailed embodiments are provided to explain the technical solutions of the claims of this invention, so that those skilled in the art can understand the claims. The scope of protection of this invention is not limited to the following specific embodiments. Any modifications made by those skilled in the art that incorporate the technical solutions of the claims but differ from the following detailed embodiments are also within the scope of protection of this invention.

[0025] In the description of this invention, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0026] This application includes an embodiment of a method for a multi-core automotive controller system to access shared resources: such as... Figure 3 As shown, it includes the following steps:

[0027] S1. Obtain access information for the shared resource to be accessed; the access information includes the access methods and interrupt priorities of one or more other kernels Core1 to CoreX that may cause access conflicts to access the shared resource, X≧1;

[0028] S2. Determine the interrupt type and interrupt priority of the inter-core interrupt sent to kernels Core1 to CoreX based on the access information of kernels Core1 to CoreX to the shared resource; the inter-core interrupt is used to prevent kernels Core1 to CoreX from accessing the shared resource to be accessed within a set time period;

[0029] S3. Send inter-core interrupts to kernels Core1 to CoreX one by one according to the determined inter-core interrupt type and interrupt priority; after all inter-core interrupts have been responded to, start accessing the shared resource to be accessed;

[0030] S4. After the shared resource access is completed, notify the kernel Core1 to CoreX to exit the inter-core interrupt.

[0031] In the above technical solution, after sending inter-core interrupts to kernels Core1 to CoreX one by one in step S3, the following is also included:

[0032] Set a shared resource access time semaphore TdoneTimeout as the timeout period for other kernels Core1 to CoreX that will be locked to wait for the shared resource access to be completed; the specific duration of TdoneTimeout is determined by the kernel that initiated the request based on the longest actual access time to the shared resource.

[0033] Kernel Core1 to CoreX initialize response status variables FB0 to FBX respectively. FBi (i∈1,X) is used to indicate whether Corei (i∈1,X) has responded to the inter-core interrupt; for example, FB0=0 indicates that Core0 has not responded to the inter-core interrupt, and FB1=1 indicates that Core1 has responded to the inter-core interrupt. This is done to ensure consistency in software programming. Figure 3 Although Core2 does not access shared resource X, setting FB2=1 indicates that Core2 has responded to the inter-core interrupt. This allows you to avoid worrying about which kernels actually have access conflicts during the actual programming process, and simply poll the corresponding FBi variable for each kernel.

[0034] Define an access completion semaphore, AccDoneX, to indicate whether the kernel that initiated the shared resource access request has completed accessing the shared resource; for example, AccDoneX = 0 represents that the kernel that initiated the request (e.g., ...) has completed accessing the shared resource. Figure 3 CoreN in the code did not complete access to the shared resource X.

[0035] The above technical solution, after sending inter-core interrupts to kernels Core1 through CoreX one by one, also includes:

[0036] Initiate a check for timeout responses from other kernels, with the timeout threshold set to TfbTimeout. The specific duration of TfbTimeout is determined based on the system characteristics of all kernels, and is generally the maximum value of the interrupt response latency of all kernels, to ensure that each kernel can respond to inter-kernel interrupt requests from other kernels within this duration when the system is running normally.

[0037] Within the TfbTimeout duration, the kernel that initiates the shared resource access request polls the status FB0 to FBX of other kernels Core1 to CoreX in response to this inter-core interrupt.

[0038] Within the TfbTimeout timeout period, once all kernels have set FB0 to FBX to the responded flag, it indicates that other kernels have entered a locked access state for the shared resource. Figure 3 CoreN in the kernel starts accessing shared resources. After the access is completed, the access completion semaphore AccDoneX is set to 1 to indicate that the access is complete, so as to notify other kernels to exit the inter-core interrupt.

[0039] In the above technical solution, if all kernels Core1 to CoreX fail to respond to the inter-core interrupt within the TfbTimeout period, the access request for the shared resource fails; at the same time, the access completion semaphore AccDoneX is set to complete so that other kernels that have responded to the inter-core interrupt can exit the inter-core interrupt normally.

[0040] When kernels Core1 through CoreX begin responding to inter-core interrupts, they set their corresponding response status variables FB0 through FBX to notify the kernels waiting to access the shared resource that their access to the shared resource has been locked. Each kernel from Core1 to CoreX then initiates a timeout check to wait for the shared resource access to complete, setting this timeout duration to TdoneTimeout. Within the TdoneTimeout duration, kernels Core1 through CoreX poll whether the access completion semaphore AccDoneX is in a completed state. If it is, they exit the inter-core interrupt; otherwise, they continue waiting. If the waiting time for access completion exceeds TdoneTimeout, kernels Core1 through CoreX directly exit the inter-core interrupt.

[0041] In the above technical solution, each kernel can define at least two interrupt priorities, corresponding to the shared resource access levels that may occur due to hardware interrupts and system tasks, respectively. When access to a shared resource is required, an inter-kernel interrupt of the corresponding level is sent to other kernels based on which other kernels may access the resource and the access status in other kernels via hardware interrupts or system tasks. Access permissions to shared resources can be further subdivided based on the type of hardware interrupt or system task, expanding to two or more interrupt priority levels. This refines the granularity of shared resource management. A locked kernel can only respond to higher-priority interrupts or tasks, allowing other kernels with shared resource access conflicts to respond to other high-priority interrupts unrelated to the current shared resource access.

[0042] by Figure 3 Taking the kernel Core0 as an example, from Figure 2 It can be seen that Core0 accesses shared resource X within a task. Therefore, when shared resource X is accessed by kernel CoreN, CoreN sends an interrupt of type software interrupt to Core0, with a priority higher than the inter-core interrupt accessed by this system task. After Core0 responds to this inter-core interrupt sent by CoreN, it can still normally respond to all other hardware interrupts and other software interrupts with a priority higher than the system task access. This method not only locks the shared resource but also allows other kernels to flexibly respond to other higher priority interrupts or other types of interrupts.

[0043] Once the access is complete, the access completion semaphore AccDoneX = 1 is set to indicate that the access is complete. The kernel that was requested to lock waits for the kernel that initiated the access request to complete the access to the shared resource by polling the access completion semaphore AccDoneX during the inter-kernel interrupt. After that, it exits the interrupt and continues normal program scheduling and execution.

[0044] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0045] This application also includes a technical solution for a system for a multi-core automotive controller to access shared resources, comprising an access information acquisition module, an inter-core interrupt information determination module, an inter-core interrupt sending module, a shared resource access module, and a notification module;

[0046] The access information acquisition module is used to acquire access information of the shared resource to be accessed; the access information includes the access methods and interrupt priorities of one or more other kernels Core1 to CoreX that may cause access conflicts to access the shared resource, X≧1;

[0047] The inter-core interrupt information determination module is used to determine the interrupt type and interrupt priority of the inter-core interrupt sent to kernels Core1 to CoreX based on the access information of kernels Core1 to CoreX to the shared resource; the inter-core interrupt is used to prevent kernels Core1 to CoreX from accessing the shared resource to be accessed within a set time period;

[0048] The inter-core interrupt sending module is used to send inter-core interrupts to kernels Core1 to CoreX one by one according to the determined inter-core interrupt type and interrupt priority;

[0049] The shared resource access module is used to access the shared resource to be accessed after all inter-core interrupts have been responded to;

[0050] The notification module is used to notify the kernels Core1 to CoreX to exit the inter-core interrupt of this response after the shared resource access is completed.

[0051] In the above technical solution, the method for determining the priority of inter-core interrupts sent to kernels Core1 to CoreX includes:

[0052] Obtain the access methods and priorities of kernels Core1 to CoreX when accessing the shared resource. The access methods include hardware interrupt access and system task access.

[0053] If the kernel accesses the shared resource via hardware access, an inter-core interrupt of type hardware interrupt is sent to the kernel, and the priority of the inter-core interrupt is higher than the priority of the hardware interrupt access.

[0054] If the kernel accesses the shared resource via system task access, an inter-kernel interrupt of type software interrupt is sent to the kernel, and the priority of the inter-kernel interrupt is higher than that of the system task access.

[0055] like Figure 2 As shown, for shared resource X, it is accessed by system tasks of kernel Core0 or by hardware interrupts of kernel Core1. Core2 will not access it, and CoreN accesses it in an interrupt or task. Therefore, for kernel CoreN that wants to access shared resource X, the interrupt level of the corresponding inter-core interrupt can be determined. That is, when CoreN requests access to shared resource X, Core0 and Core1 need to respond to the inter-core interrupt, and their corresponding priorities need to be higher than the priorities of all tasks of Core0 and the priorities of all interrupts of Core1, so that Core0 and Core1 will not access shared resource X.

[0056] The above technical solution also includes a first timing module, which is initiated by each kernel Core1 to CoreX that responds to the inter-core interrupt. When kernel Core1 to CoreX responds to the inter-core interrupt sent by the inter-core interrupt sending module, the timing starts. When the timing exceeds a first preset duration (TdoneTimeout in this embodiment), the inter-core interrupt response ends.

[0057] The above technical solution also includes a second timing module. The timing is initiated by the kernel accessing the shared resource. The timing starts after the inter-core interrupt sending module sends an inter-core interrupt to kernel Core1 to CoreX. If the timing exceeds the second preset time (TfbTimeout in this embodiment) and fails to detect that all kernels Core1 to CoreX have responded to the inter-core interrupt, the inter-core interrupt request is cancelled.

[0058] The above technical solution also includes a response status control module. The response status (FB0 to FBX in this embodiment) is used to identify whether the kernel Core1 to CoreX responds to the inter-core interrupt sent by the inter-core interrupt sending module. This status is set by each kernel.

[0059] The above technical solution also includes an access completion semaphore control module. The access completion semaphore is used to identify whether the kernel requesting access to the shared resource has completed accessing the shared resource. The semaphore is set by the kernel accessing the shared resource.

[0060] The contents not described in detail in this specification are existing technologies known to those skilled in the art.

Claims

1. A system for accessing shared resources in a multi-core automotive controller system, characterized in that, It includes an access information acquisition module, an inter-core interrupt information determination module, an inter-core interrupt sending module, a shared resource access module, and a notification module; The access information acquisition module is used to acquire access information of the shared resource to be accessed; the access information includes the access methods and interrupt priorities of one or more other kernels Core1 to CoreX that may cause access conflicts to access the shared resource, where X≧1; The inter-core interrupt information determination module is used to determine the interrupt type and interrupt priority of the inter-core interrupt sent to kernel Core1~CoreX based on the access information of kernel Core1~CoreX to the shared resource; the inter-core interrupt is used to prevent kernel Core1~CoreX from accessing the shared resource to be accessed within a set time period; Set a shared resource access time semaphore TdoneTimeout as the timeout period for other kernels Core1~CoreX that will be locked to wait for the shared resource access to be completed; the specific duration of TdoneTimeout is determined by the kernel that initiated the request based on the longest actual access time to the shared resource. The inter-core interrupt sending module is used to send inter-core interrupts to kernels Core1 to CoreX one by one according to the determined inter-core interrupt type and interrupt priority; The shared resource access module is used to access the shared resource to be accessed after all inter-core interrupts have been responded to; The notification module is used to notify the kernels Core1~CoreX to exit the inter-core interrupt of this response after the shared resource access is completed; In the inter-core interrupt information determination module, the methods for determining the interrupt type and priority of inter-core interrupts sent to kernels Core1~CoreX include: Obtain the access methods and interrupt priorities of kernel Core1~CoreX accessing the shared resource, including hardware interrupt access and system task access; If the kernel accesses the shared resource via hardware access, an inter-core interrupt of type hardware interrupt is sent to the kernel, and the priority of the inter-core interrupt is higher than the priority of the hardware interrupt access. If the kernel accesses the shared resource via system task access, an inter-kernel interrupt of type software interrupt is sent to the kernel, and the priority of the inter-kernel interrupt is higher than that of the system task access.

2. The system for accessing shared resources in a multi-core automotive controller system as described in claim 1, characterized in that, It includes a first timing module, which is initiated by each kernel Core1 to CoreX that responds to the inter-core interrupt. When kernel Core1 to CoreX responds to the inter-core interrupt sent by the inter-core interrupt sending module, the timing starts. When the timing exceeds a first preset duration, the inter-core interrupt response ends.

3. The system for accessing shared resources in a multi-core automotive controller system as described in claim 1, characterized in that, The system includes a second timing module, which is initiated by the kernel accessing the shared resource. The timing starts when the inter-core interrupt sending module sends an inter-core interrupt to kernels Core1 to CoreX. If the timing exceeds a second preset duration and all kernels Core1 to CoreX fail to respond to the inter-core interrupt, the requested inter-core interrupt is canceled.

4. The system for accessing shared resources in a multi-core automotive controller system as described in claim 1, characterized in that, It includes a response status control module, wherein the response status is used to identify whether the kernel Core1~CoreX responds to the inter-core interrupt sent by the inter-core interrupt sending module.

5. The system for accessing shared resources in a multi-core automotive controller system as described in claim 1, characterized in that, It includes an access completion semaphore control module, wherein the access completion semaphore is used to identify whether the kernel requesting access to the shared resource has completed accessing the shared resource.

6. A method for a multi-core automotive controller system to access shared resources, characterized in that, The steps include the following: S1. Obtain access information for the shared resource to be accessed; the access information includes the access methods and interrupt priorities of one or more other kernels Core1 to CoreX that may cause access conflicts to access the shared resource, X≧1; S2. Determine the interrupt type and interrupt priority of the inter-core interrupt sent to kernels Core1 to CoreX based on the access information of kernels Core1 to CoreX to the shared resource; the inter-core interrupt is used to prevent kernels Core1 to CoreX from accessing the shared resource to be accessed within a set time period; Set a shared resource access time semaphore TdoneTimeout as the timeout period for other kernels Core1~CoreX that will be locked to wait for the shared resource access to be completed; the specific duration of TdoneTimeout is determined by the kernel that initiated the request based on the longest actual access time to the shared resource. S3. Based on the determined inter-core interrupt type and priority, send inter-core interrupts to kernels Core1 to CoreX one by one; after all inter-core interrupts have been responded to, start accessing the shared resources to be accessed; S4. After the shared resource access is completed, notify the kernel Core1~CoreX to exit the inter-core interrupt; The methods for determining the interrupt type and priority of inter-core interrupts sent to kernels Core1 to CoreX include: Obtain the access methods and interrupt priorities of kernel Core1~CoreX accessing the shared resource, including hardware interrupt access and system task access; If the kernel accesses the shared resource via hardware access, an inter-core interrupt of type hardware interrupt is sent to the kernel, and the priority of the inter-core interrupt is higher than the priority of the hardware interrupt access. If the kernel accesses the shared resource via system task access, an inter-kernel interrupt of type software interrupt is sent to the kernel, and the priority of the inter-kernel interrupt is higher than that of the system task access.

7. The method for accessing shared resources in a multi-core automotive controller system as described in claim 6, characterized in that, In step S3, after sending inter-core interrupts to kernels Core1 through CoreX one by one, the following steps are also included: Set a shared resource access time semaphore TdoneTimeout to represent the timeout period for other kernels Core1~CoreX that will be locked to wait for the shared resource access to complete; Kernel Core1~CoreX initialize response status variables FB0~FBX respectively, and FBi (i∈1,X) is used to indicate whether Corei (i∈1,X) responded to this inter-core interrupt; Set up an access completion semaphore AccDoneX to indicate whether the kernel that initiated the shared resource access request has completed accessing the shared resource; The methods for determining the interrupt type and priority of inter-core interrupts sent to kernels Core1 to CoreX include: Obtain the access methods and interrupt priorities of kernel Core1~CoreX accessing the shared resource, including hardware interrupt access and system task access; If the kernel accesses the shared resource via hardware access, an inter-core interrupt of type hardware interrupt is sent to the kernel, and the priority of the inter-core interrupt is higher than the priority of the hardware interrupt access. If the kernel accesses the shared resource via system task access, an inter-kernel interrupt of type software interrupt is sent to the kernel, and the priority of the inter-kernel interrupt is higher than that of the system task access.

8. The method for accessing shared resources in a multi-core automotive controller system as described in claim 7, characterized in that, After sending inter-core interrupts to kernels Core1 through CoreX one by one, it also includes: Initiate a check for timeout responses from other kernels, with the timeout threshold set to TfbTimeout. Within the TfbTimeout duration, the kernel that initiated the shared resource access request polls the status of other kernels Core1~CoreX in response to this inter-core interrupt, FB0~FBX. Within the TfbTimeout timeout period, after all kernels set FB0~FBX to the responded flag, the kernel begins to access the shared resources.

9. The method for accessing shared resources in a multi-core automotive controller system as described in claim 8, characterized in that, If all kernels Core1 to CoreX fail to respond to the inter-core interrupt within the TfbTimeout period, the access request for the shared resource fails; at the same time, the access completion semaphore AccDoneX is set to complete so that other kernels that have responded to the inter-core interrupt can exit the inter-core interrupt normally. Once kernels Core1 through CoreX begin responding to this inter-core interrupt, they set their corresponding response status variables FB0 through FBX to notify the kernels waiting to access the shared resource that their access to the shared resource has been locked. Each kernel from Core1 to CoreX then initiates a timeout check to wait for the shared resource access to complete, setting this timeout duration to TdoneTimeout. Within the TdoneTimeout duration, kernels Core1 through CoreX poll whether the access completion semaphore AccDoneX is in a completed state. If it is, they exit this inter-core interrupt; otherwise, they continue waiting. If the waiting time for access completion exceeds TdoneTimeout, they exit this inter-core interrupt directly.

Images