A critical resource scheduling method, electronic equipment and storage medium

Abstract

This application discloses a critical resource scheduling method, electronic device, and storage medium, relating to the field of heterogeneous core communication. The method includes: obtaining the inter-core call topology by analyzing the relationships between critical sections in a multi-core processor and their calls to different processor cores; and determining the resources accessed by each critical section by parsing each critical section, thus obtaining the resource dependencies of each critical section. Then, based on the inter-core call topology and resource dependencies of each critical section, cross-core shared resources and single-core exclusive resources are identified. Spinlocks are used to protect cross-core shared resources, while interrupt masking is used to protect single-core exclusive resources. This scheme employs different protection operations for different types of shared resources (e.g., cross-core shared resources and single-core exclusive resources), thereby avoiding the problem of ineffective protection of cross-core shared resources due to unreasonable allocation of spinlocks and interrupt masking in critical sections.

Description

Technical Field

[0001] This application relates to the field of heterogeneous communication technology, and in particular to a critical resource scheduling method, electronic device and storage medium. Background Technology

[0002] In a multi-core processor architecture, a critical section is a code segment that accesses shared resources (such as memory variables, files, and hardware devices). Shared resources that processes need to access mutually exclusively are also called critical resources. Since multiple processor cores may execute different threads simultaneously, if multiple threads enter the critical section at the same time, it will lead to data races, resulting in program errors or data inconsistencies. To ensure the correct execution of the critical section, synchronization mechanisms must be used to ensure that only one thread can enter the critical section at any given time.

[0003] Spinlocks and interrupt masks are typically used to protect the atomicity of critical region operations. Traditional solutions have an unreasonable allocation of spinlocks and interrupt masks in critical regions, which cannot protect shared resources in cross-core scenarios. Summary of the Invention

[0004] In view of the above problems, this application provides a critical resource scheduling method, electronic device, and storage medium to solve the problem that the allocation of protection operations for critical resources in multi-core processor architectures is unreasonable, failing to protect shared resources in cross-core scenarios. The specific solution is as follows:

[0005] Firstly, this application provides a critical resource scheduling method, the method comprising:

[0006] Analyze the relationships between critical sections in a multi-core processor and their calls by different processor cores to obtain the inter-core call topology corresponding to each critical section;

[0007] Analyze the resource access information of each critical section to determine the resource dependencies of each critical section;

[0008] Based on the inter-core call topology and resource dependency relationships corresponding to each critical section, cross-core shared resources and single-core exclusive resources are identified.

[0009] For the protection scope of the cross-core shared resource marking spinlock, and for the scope of the single-core exclusive resource marking interruption masking, obtain the lock policy configuration for the critical resource;

[0010] When running multi-core services, the critical resources are invoked according to the locking policy of the critical resources.

[0011] In one possible implementation, analyzing the relationships between critical sections in a multi-core processor and their calls by different processor cores to obtain the inter-core call topology corresponding to each critical section includes:

[0012] During the process of the multi-core processor running the multi-core service, the log probes implanted in each critical section are used to record the call relationship between the critical section and different processor cores of the multi-core processor, so as to obtain the inter-core call topology corresponding to each critical section.

[0013] In one possible implementation, the step of parsing the resource access information of each critical section to determine the resource dependencies of each critical section includes:

[0014] Analyze the resource access instructions of each critical section to identify the critical resources accessed by each critical section;

[0015] Based on the critical resources accessed by each critical section, a mapping relationship between shared resources and critical sections in the multi-core processor is established, and shared resources accessed by at least two critical sections are identified to obtain the resource dependencies of each critical section.

[0016] In one possible implementation, identifying cross-core shared resources and single-core exclusive resources based on the inter-core call topology and resource dependencies corresponding to each critical section includes:

[0017] Based on critical sections, the inter-core call topology and resource dependencies are correlated and matched to identify cross-core shared resources accessed by at least two processor cores, as well as single-core exclusive resources accessed by only one processor core.

[0018] In one possible implementation, the association and matching of the inter-core call topology and the resource dependencies based on critical sections includes:

[0019] For any critical section, the target processor core that calls the critical section is determined according to the inter-core call topology, and the target shared resource accessed by the critical section is determined according to the resource dependency relationship.

[0020] Establish a mapping relationship between the target processor cores and the target shared resources corresponding to the same critical section.

[0021] In one possible implementation, the method further includes:

[0022] For single-core exclusive resources accessed more frequently than a preset frequency, a preset threshold for enabling interrupt masking is configured. The preset threshold is used to enable interrupt masking when the local cache resources of the processor core are lower than the preset threshold.

[0023] In one possible implementation, configuring the invocation of the critical resource according to the locking policy of the critical resource when running multi-core services includes:

[0024] When running the multi-core service in a multi-core processor, if the critical resource accessed by the current processor core is a single-core exclusive resource, determine whether the local cache resource of the current processor core is lower than the preset threshold.

[0025] If the local cache resources of the current processor core are higher than or equal to the preset threshold, local cache resources are allocated to the multi-core services running on the current processor core;

[0026] If the local cache resources of the current processor core are lower than the preset threshold, the critical section corresponding to the single-core exclusive resource is invoked, and interrupt masking is enabled when entering the critical section corresponding to the single-core exclusive resource. When exiting the critical section corresponding to the single-core exclusive resource, the interrupt status of the current processor core is restored.

[0027] In one possible implementation, configuring the invocation of the critical resource according to the locking policy of the critical resource when running multi-core services includes:

[0028] When running the multi-core service within a multi-core processor, if the critical resource accessed by the current processor core is a cross-core shared resource, then after acquiring the spinlock corresponding to the cross-core shared resource, the cross-core shared resource is accessed, and the spinlock is released when the cross-core shared resource is released.

[0029] A second aspect of this application provides an electronic device, including at least one multi-core processor and a memory connected to the multi-core processor, wherein the memory is used to store a computer program;

[0030] The multi-core processor is used to execute the computer program to enable the electronic device to implement the method as described in the first aspect or any implementation thereof.

[0031] A third aspect of this application provides a computer-readable storage medium carrying one or more computer programs that, when executed by an electronic device, enable the electronic device to perform the method described in the first aspect or any implementation thereof.

[0032] A fourth aspect of this application provides a computer program product including computer-readable instructions that, when executed on an electronic device, cause the electronic device to perform the method described in the first aspect or any implementation thereof.

[0033] By employing the aforementioned technical solution, this application provides a method for optimizing the critical resource scheduling strategy of a multi-core processor. This method obtains the inter-core call topology of each critical section within a multi-core processor, where different processor cores call each critical section. It further analyzes the global variables of accessed resources in each critical section to determine the resource dependencies of each critical section. Then, based on the inter-core call topology and resource dependencies of each critical section, it identifies cross-core shared resources and single-core exclusive resources. Spinlocks are used for protection of cross-core shared resources, while interrupt masking is used for protection of single-core exclusive resources. It is evident that this scheme can accurately identify different types of shared resources, such as cross-core shared resources and single-core exclusive resources, and employs different protection operations for each type of shared resource. This avoids the problem of ineffective protection of cross-core shared resources due to unreasonable allocation of spinlocks and interrupt masking in critical sections. Furthermore, it avoids the problem of excessive cache coherence overhead caused by uniformly applying spinlocks to shared resources. Attached Figure Description

[0034] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0035] Figure 1 This application provides a schematic diagram of the structure of a diagnostic routing system;

[0036] Figure 2 A flowchart of a critical resource scheduling method provided in this application;

[0037] Figure 3 A schematic diagram of the processing flow of a multi-core architecture device with a transport protocol layer module in a diagnostic routing scenario provided in this application;

[0038] Figure 4 A schematic diagram of a critical resource scheduling device provided in this application;

[0039] Figure 5 This application provides a schematic diagram of the structure of an electronic device with a transport protocol layer routing module. Detailed Implementation

[0040] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0041] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0042] To facilitate understanding of the embodiments of this application, the terms involved in this application will be briefly explained first.

[0043] 1. Spinlock

[0044] Spin locks are a locking mechanism used to protect shared resources in multi-threaded concurrent access. Spin lock implementations are based on atomic operations (such as Compare-and-Swap (CAS) instructions) and a loop-checking mechanism. When a thread attempts to acquire a spin lock, if the spin lock is not held, it immediately acquires it and enters the critical section; if the spin lock is held, the thread enters a loop state, continuously repeating this atomic operation (i.e., constantly checking if the spin lock has been released) until it successfully acquires it. This atomicity is crucial because it prevents multiple threads from simultaneously misjudging the lock state and each believing they have acquired the spin lock, thus ensuring the correctness of mutual exclusion access.

[0045] 2. Interruption shielding

[0046] Interrupt masking essentially prevents the processor from responding to some or all external interrupt requests for a specific period of time, thereby ensuring that critical code segments currently being executed are not unexpectedly interrupted.

[0047] 3. Diagnose the route

[0048] Diagnostic routing is primarily used in automotive electronic systems. It routes diagnostic requests to the appropriate electronic control unit (ECU) via a gateway, enabling diagnostic testing of all ECUs supporting diagnostic functions throughout the vehicle via a single bus. In finished vehicles, electronic components are directly connected via wiring harnesses; diagnostic routing technology allows for diagnostic testing of individual components without disconnecting the wiring harnesses.

[0049] like Figure 1As shown, the diagnostic routing system includes a diagnostic instrument (which can be called a host computer), a multi-core processor device containing a transport protocol layer routing (TpR) module, and a controller (which can be called a slave computer).

[0050] The address mapping relationship for heterogeneous communication in the TpR module is designed based on the diagnostic routing table, i.e., the address mapping relationship between the diagnostic instrument and the controller. After the diagnostic instrument initiates a diagnostic request, the TpR module forwards the diagnostic request to the target controller. After the target controller processes the diagnostic request, it returns a diagnostic response through the same path.

[0051] As previously mentioned, traditional solutions suffer from unreasonable allocation of spinlocks and interrupt masks for critical resources. This can manifest as incorrect selection of the original domain protection operation (e.g., selecting interrupt masking when spinlocks should be selected), incorrect scope, incorrect granularity, incorrect timing, or incorrect sequence. The root cause is the inability to effectively identify the usage of shared resources in multi-core scenarios, leading to over-protection and / or under-protection within the same codebase.

[0052] For example, if only interrupt masking is used to protect cross-core shared resources, shared buffers or global send / receive queues can be accessed by both the external interrupt context of the current processor core and threads from other cores. In practice, if only interrupt masking of the current processor core is used when updating the queue, without using spinlocks that can be synchronized across cores, it will result in the current processor core not being interrupted by external interrupts, but other cores still being able to concurrently access the shared resource. This can lead to data corruption within the shared resource or the shared resource being in a contention state. Therefore, relying solely on interrupt masking in a multi-core environment cannot guarantee mutual exclusion for shared resource access, because interrupt masking is only effective for the current processor core; other processor cores can still access the shared resource in parallel. Relying solely on spinlocks also has limitations; multiple processor cores may simultaneously read and modify the lock variable, causing the shared resource to be in a contention state.

[0053] In view of this, this application provides a critical resource scheduling method. This method analyzes the relationships between critical sections in a multi-core processor and their calls by different processor cores to obtain the inter-core call topology of each critical section, i.e., the detailed information on how each critical section is called by different processor cores. Furthermore, it determines the resources accessed by each critical section by parsing each critical section, thus obtaining the resource dependencies of each critical section. It also identifies cross-core shared resources (i.e., shared resources accessed by critical sections of multiple processor cores) and single-core exclusive resources. Finally, to address the conflict problem of cross-core shared resources, a layered protection mechanism is adopted for multi-core scenarios: for cross-core shared resources, spinlocks are used to achieve mutual exclusion access, meaning only one processor core can access the resource at any given time; for single-core exclusive resources, interrupt masking ensures atomic operation, guaranteeing that the current thread's access operation to the single-core exclusive resource is an indivisible whole and will not be interrupted by other threads. As can be seen, this scheme uses spinlock protection for cross-core shared resources and interrupt masking protection for single-core exclusive resources. Compared with the method of using spinlock protection for all shared resources, it effectively reduces the system overhead of resource contention protection cache consistency in multi-core processor architecture while ensuring the atomicity of critical resource scheduling, and significantly improves the communication reliability and system response efficiency of multi-core processor architecture.

[0054] The critical resource scheduling optimization method provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0055] Reference Figure 2 , Figure 2 This is a flowchart illustrating a critical resource scheduling method provided in an embodiment of this application. The method is applied to a device containing a multi-core processor. Figure 2 As shown, the method may include the following steps:

[0056] S101 analyzes the relationship between critical sections in a multi-core processor and their calls by different processor cores to obtain the inter-core call topology corresponding to each critical section.

[0057] In one possible implementation, a log probe can be implanted in the critical section, which can record the critical section being called in real time during its runtime.

[0058] For example, a log probe can be implanted in each critical section that a multi-core processor needs to execute. A log probe is an automated tool based on scripting technology specifically designed for collecting, monitoring, and analyzing system log data. For instance, in this embodiment, the log probe is a small piece of very fast-running code, with a millisecond-level execution speed that does not affect system real-time performance.

[0059] After a log probe is implanted into a critical section, it can record in real time the call status of the critical section, including the core identifier of the processor core that calls the critical section, such as an 8-bit core identifier, so as to identify which processor cores call the critical section and whether there are cross-core calls.

[0060] To fully cover and verify the cross-core and single-core resource call path scenarios of multi-core services, a simulated running environment for multi-core services can be constructed. During the running of the multi-core service in this simulated running environment, log probes embedded in each critical section are used to record in real time the situation in which the critical section is called by different processor cores, so as to obtain the inter-core call topology corresponding to each critical section, that is, the topological relationship of each critical section being called by different processor cores.

[0061] For example, in diagnostic routing scenarios for multi-core architectures, a host computer can be written in Python, and a slave computer can be simulated through a Controller Area Network (CAN) open environment (CANoe) device. A multi-core processor device containing a TpR module is connected between the simulated host computer and the simulated slave computer to create a simulated running environment for diagnostic routing services. This simulates the scenario where diagnostic requests trigger multi-core concurrent services. During this process, log probes in each critical section record in real time how the critical section is called by different processor cores.

[0062] S102, parse the resource access information of each critical section to determine the resource dependencies of each critical section.

[0063] In one possible implementation, the resource domains accessed by each critical section are identified by parsing the resource access instructions of each critical section, i.e., the shared resources accessed by each critical section, thus obtaining the resource dependencies of each critical section. In particular, it is necessary to identify conflicting resource domains that are accessed by at least two critical sections. When it is detected that at least two critical sections are alternately modifying the same shared resource, the shared resource is marked as a high-risk conflict domain.

[0064] For example, the LLVM static analysis framework can be used to perform forward analysis on the code in a multi-core processor. By parsing the global variables of the resource access instructions in the critical section and the critical section resources called by the main processes involved in the multi-core business, the resource dependencies of each critical section can be determined.

[0065] For example, taking the diagnostic routing scenario for multi-core architecture as an example, the resource access instructions of the critical section are parsed by the LLVM static analysis tool, as well as the shared resources called by each step of the three main processes involved in the TpR module: physical request, physical response, and functional request. The shared resources called by each critical section and the conflicting resource domains accessed by multiple critical sections are identified, and the conflicting resource domains are marked as high-risk conflict domains.

[0066] S103 identifies cross-core shared resources and single-core exclusive resources based on the inter-core call topology and resource dependencies corresponding to each critical section.

[0067] The data obtained in the first two steps, namely the inter-core call topology and resource dependencies, are associated and matched. That is, for any critical section, the processor core that calls the critical section is identified based on the inter-core call topology, and the shared resources accessed by the critical section are determined based on the resource dependencies. This identifies which processor core calls each shared resource, and further identifies which shared resources are called by at least two processor cores simultaneously (i.e., cross-core shared resources) and which shared resources are called by only one processor core (i.e., single-core exclusive resources).

[0068] S104 marks the protection scope of spinlocks for cross-core shared resources and the interrupt masking scope for single-core exclusive resources, and obtains the lock policy configuration for critical resources.

[0069] To protect all cross-core shared resources using spinlocks, it's necessary to mark the scope of the spinlocks, i.e., define the critical section range where the spinlocks are used. When marking the scope of the spinlocks, the granularity should be as precise as possible to a single cross-core shared resource. Within the critical section accessing this shared resource, mark the locking position (i.e., when the spinlock is acquired) and the unlocking position (i.e., when the spinlock is released). For example, lock before entering the critical section to access the cross-core shared resource and unlock after leaving the critical section.

[0070] Any shared variables, data structures, or hardware resources accessed within the scope must be protected by this spinlock to ensure that only one processor core can access these resources at a time.

[0071] For resources exclusively used by a single core, an interrupt masking mechanism is used for protection. Interrupt masking in critical sections is implemented using specific macro functions. Specifically, when marking interrupt masking points, the corresponding macro functions must be called at the beginning and end of the critical section. Calling the macro function at the beginning of the critical section saves the current interrupt state of the processor core before masking external interrupts. Saving the interrupt state provides a basis for subsequent state recovery. Masking external interrupts prevents hardware interrupts, scheduling preemption, and other behaviors from interrupting the current execution flow, ensuring the critical section is not affected by asynchronous events and guaranteeing the atomicity of access operations to shared resources. Calling the macro function at the end of the critical section restores the processor core's interrupt configuration based on the pre-saved interrupt state when the processor core exits the critical section, achieving reversible restoration of the interrupt masking state.

[0072] S105, when running multi-core services, the critical resource is invoked according to the locking policy of the critical resource.

[0073] When running the multi-core service within a multi-core processor, if the resource accessed by the current processor core is a cross-core shared resource, the cross-core shared resource is accessed after acquiring the spinlock corresponding to the cross-core shared resource, and the spinlock is released when the cross-core shared resource is released.

[0074] In one possible implementation, a threshold for enabling interrupt masking in cached resources can be set based on their access frequency for single-core exclusive resources. For example, instead of directly activating interrupt masking every time the resource is allocated or reclaimed, a cached resource threshold is first set, and interrupt masking is dynamically determined based on the resource access frequency and the remaining amount of local cache resources to reduce the system overhead caused by frequently enabling and disabling interrupts. Here, a small critical section refers to resource operations with short execution times and simple access operations.

[0075] For example, each processor core maintains its local cache resources. When a multi-core application requests a single-core dedicated cache resource, it prioritizes allocating the local cache resources of the current processor core and does not need to request global shared cache resources. Therefore, it does not need to mask external interrupts. Only when the local cache resources of the current processor core are lower than a preset threshold are external interrupts temporarily masked, and multiple cache resources are pulled from the global shared cache resources at once to fill the local cache. This is equivalent to merging the small critical sections that frequently access the single-core dedicated shared cache resources into low-frequency large critical sections, reducing the processing overhead of resource on / off interrupts.

[0076] The multi-core processor critical resource scheduling strategy optimization method provided in this embodiment analyzes the relationships between critical sections in a multi-core processor and their calls by different processor cores to obtain the inter-core call topology of each critical section, i.e., the detailed information on how each critical section is called by different processor cores. Furthermore, it determines the resources accessed by each critical section by parsing each critical section, thus obtaining the resource dependencies of each critical section. It also identifies cross-core shared resources (i.e., shared resources accessed by critical sections of multiple processor cores) and single-core exclusive resources. Finally, for cross-core shared resources, spinlocks are used to implement mutual exclusion access, meaning only one processor core can access the resource at a time; for single-core exclusive resources, interrupt masking ensures atomic operation. It is evident that, compared to using spinlocks to protect all shared resources, this scheme effectively reduces the system overhead of resource contention protection cache coherency in multi-core processor architectures while ensuring the atomicity of critical resource scheduling, significantly improving the communication reliability and system response efficiency of multi-core processor architectures.

[0077] The following example, using a diagnostic routing scenario for a multi-core architecture, illustrates how a device with a TpR module performs the diagnostic routing process using the optimized multi-core processor critical resource scheduling strategy provided in the above embodiments. Figure 3 As shown, a device with a TpR module is used to perform the following steps:

[0078] S201, Initialize transport protocol layer diagnostic routing parameters based on the received diagnostic request.

[0079] A diagnostic request is used to indicate the need for route diagnostics and resource initialization, such as various resources and routing channel parameters required for route diagnostics. For example, a device with a TpR module, upon receiving a diagnostic request from a diagnostic instrument, performs the following steps:

[0080] a1. Parse the identity identifiers in the diagnostic request, such as the diagnostic request ID and the diagnostic instrument ID; further, using the parsing rules established according to the diagnostic routing table (i.e., the diagnostic route mapping table between the diagnostic instrument and the target controller), parse to obtain the diagnostic response ID and the target controller ID corresponding to the diagnostic request ID;

[0081] a2, the TpR module queries the inter-core communication address mapping relationship established based on the diagnostic routing table (i.e., the address mapping relationship between the diagnostic instrument and the target controller) to obtain the routing channel between the diagnostic instrument ID and the target controller ID, and initializes the routing channel parameters, such as initializing the diagnostic routing channel, server response timeout resources, and client wait timeout resources. It then optimizes the critical resource protection operation using the critical resource scheduling optimization strategy obtained in the above embodiments. For example, during the resource protection code design phase, spinlock protection operations are set for cross-core shared resources involving timeout paths according to the critical resource scheduling optimization strategy; and interrupt masking protection operations are set for single-core exclusive resources involving timeout paths, ensuring that spinlocks and interrupt masks do not compete with high-speed data paths for the same hot lock, and that the added spinlocks compress the waiting time as much as possible.

[0082] In order to ensure the normal operation of the diagnostic routing communication process, the corresponding standard protocol requires that the scheduling of server response timeout tasks and client waiting timeout tasks must be maintained. To maintain the normal scheduling of the above two timeout tasks, it is necessary to allocate resources such as cross-core or single-core exclusive timer doubly linked lists and timer queues. These resources can be called server response timeout resources and client waiting timeout resources.

[0083] a3 outputs the diagnostic routing channel initialization result.

[0084] S202, the TpR module receives diagnostic request content data from the diagnostic instrument.

[0085] The diagnostic request content data is the data transmitted after the resource scenario initialization is completed. For example, this diagnostic request content data and the diagnostic request in S201 can be sent by the diagnostic instrument to a device with a TpR module through the same diagnostic request message. After receiving the diagnostic request message, the TpR module first parses it to obtain the diagnostic request, that is, it executes the resource scenario initialization process of the diagnostic route shown in S201, and then parses the data content obtained from the diagnostic request message.

[0086] The TpR module receives diagnostic request content data from the diagnostic instrument, checks whether the length of the diagnostic request content data conforms to the protocol specification, and if it does, parses the diagnostic request content data and stores the received diagnostic request content data into the buffer.

[0087] S203, TpR module transmits buffer data.

[0088] In one possible implementation, the process of the TpR module transferring buffer data may include the following steps:

[0089] b1 performs error detection on the data to be sent in the buffer (i.e., the received diagnostic request content data). If the data packet structure meets the requirements, b2 is executed; if the data packet has errors, the current process ends.

[0090] b2, retrieve the status of the transmission queue corresponding to the target diagnostic response ID;

[0091] The target diagnostic response ID is the diagnostic response identifier that corresponds to the diagnostic request ID of the diagnostic request message received this time.

[0092] A diagnostic route is essentially a point-to-point communication process of sending a diagnostic request to the target controller and waiting for the target controller's response. The transmission queue is used to store the diagnostic request and the diagnostic response returned by the target controller. Therefore, the mapping between the transmission queue and the diagnostic response ID bound to the target controller is easier to distinguish.

[0093] b3, if the queue is not full, data transmission will proceed immediately;

[0094] b4 If the queue is full, add it to the waiting list to wait for transmission, ensuring that the data is correctly forwarded to the target processor core. The entire process uses a spinlock to protect the transmission list resources.

[0095] For example, the TpR module maps diagnostic request content data to a transmission queue according to the diagnostic response ID. Multiple processor cores may write data to the same transmission queue at the same time. After the data transmission in the queue is completed or the timer of the timed task is reached, the resources are reclaimed from the transmission queue. That is, the transmission list resources (such as the transmission queue linked list used for cross-core forwarding of diagnostic data, the head / tail index of the queue, the shared state, etc.) are cross-core shared resources, so spinlock protection is required.

[0096] S204, send the cached data corresponding to the target controller to the target controller.

[0097] The target controller ID is bound to the diagnostic request ID and the diagnostic response ID. The target controller uses the bound diagnostic request ID to identify whether the diagnostic request content data is its own data, and uses the diagnostic response ID to send a diagnostic response message.

[0098] Error checking is performed on the data transmission result and diagnostic request ID based on S203. Specifically, the validity of the diagnostic request ID bound to the target controller is checked. After confirming that there are no errors, the corresponding transmission queue is obtained according to the diagnostic request ID, that is, the transmission queue corresponding to the diagnostic response ID. Based on the spinlock protection mechanism adopted for cross-core shared resources, the head of the transmission queue is accessed during the spinlock acquisition period to read the diagnostic request content data corresponding to the diagnostic request ID, and the diagnostic request content data is sent to the target processor core. After the transmission is completed, the transmission list resources, cache resources, transmission retry register, timer doubly linked list and other memory resources occupied by the data are released.

[0099] The processing flow of the transport protocol layer routing module for diagnostic routing in a multi-core architecture scenario provided in this embodiment sets different protection operations according to the type of shared resources, such as cross-core shared resources and single-core exclusive resources, when initializing the diagnostic routing parameters of the TpR module. Specifically, a spinlock protection mechanism is used for cross-core shared resources, and an interrupt masking protection mechanism is used for single-core exclusive resources. This avoids the problem of ineffective protection of cross-core shared resources due to unreasonable allocation of spinlocks and interrupt masks in critical sections. Furthermore, it avoids the problem of excessive cache consistency overhead caused by uniformly using spinlocks for shared resources.

[0100] The above describes a method for optimizing critical resource scheduling strategy for multi-core processors according to embodiments of this application. The apparatus for performing the above method will be described below.

[0101] Please see Figure 4 , Figure 4 This is a schematic diagram of a critical resource scheduling strategy optimization device for a multi-core processor provided in an embodiment of this application. Figure 4 As shown, the device includes:

[0102] The inter-core call relationship analysis module 101 is used to analyze the relationship between critical sections in a multi-core processor and different processor cores, and to obtain the inter-core call topology corresponding to each critical section.

[0103] The resource dependency resolution module 102 is used to resolve the resource access information of each critical section to determine the resource dependency relationship of each critical section.

[0104] The resource identification module 103 is used to identify cross-core shared resources and single-core exclusive resources based on the inter-core call topology and resource dependency relationships corresponding to each critical section.

[0105] The resource scheduling optimization module 104 is used to mark the protection scope of spin locks for cross-core shared resources and the interrupt shielding scope for single-core exclusive resources, thereby obtaining the lock policy configuration for critical resources.

[0106] The resource scheduling module 105 is used to configure and call the critical resource according to the locking policy of the critical resource when running multi-core business.

[0107] In one possible implementation, the inter-core call relationship analysis module 101 is specifically used to: during the process of the multi-core processor running the multi-core service, use the log probes implanted in each critical section to record the call relationship of the critical section being called by different processor cores of the multi-core processor, and obtain the inter-core call topology corresponding to each critical section.

[0108] In one possible implementation, the multi-core service is a diagnostic routing service for multi-core processors. The inter-core call relationship analysis module 101 is specifically used to: create a simulated operating environment for the diagnostic routing service. The simulated operating environment includes a simulated diagnostic instrument written using programming tools, a simulated controller using CANoe devices, and a multi-core processor containing a transport protocol layer routing module connected between the simulated diagnostic instrument and the simulated controller.

[0109] During the operation of the diagnostic routing service in the simulation environment, the log probes implanted in each critical section are used to record the call relationships between different processor cores of the multi-core processor and each critical section, thereby obtaining the inter-core call topology corresponding to each critical section.

[0110] In one possible implementation, the resource dependency resolution module 102 is specifically used for:

[0111] Analyze the resource access instructions of each critical section to identify the critical resources accessed by each critical section;

[0112] Based on the critical resources accessed by each critical section, a mapping relationship between shared resources and critical sections in the multi-core processor is established, and shared resources accessed by at least two critical sections are identified to obtain the resource dependencies of each critical section.

[0113] In one possible implementation, the resource identification module 103 is specifically used to: associate and match the inter-core call topology and the resource dependency relationship based on the critical section, and identify cross-core shared resources accessed by at least two processor cores, as well as single-core exclusive resources accessed by only one processor core.

[0114] In one possible implementation, the resource identification module 103 is used to associate and match the inter-core call topology and the resource dependency relationship based on the critical section, and to identify cross-core shared resources accessed by at least two processor cores, and single-core exclusive resources accessed by only one processor core, specifically for:

[0115] For any critical section, the target processor core that calls the critical section is determined according to the inter-core call topology, and the target shared resource accessed by the critical section is determined according to the resource dependency relationship.

[0116] Establish a mapping relationship between the target processor cores and the target shared resources corresponding to the same critical section.

[0117] In one possible implementation, the resource scheduling optimization module 104 is used to mark the interrupt masking scope for single-core exclusive resources, specifically for:

[0118] For single-core exclusive resources accessed more frequently than a preset frequency, a preset threshold for enabling interrupt masking is configured. The preset threshold is used to enable interrupt masking when the local cache resources of the processor core are lower than the preset threshold.

[0119] In one possible implementation, the resource scheduling module 105 is specifically used for:

[0120] When running the multi-core service in a multi-core processor, if the critical resource accessed by the current processor core is a single-core exclusive resource, determine whether the local cache resource of the current processor core is lower than the preset threshold.

[0121] If the local cache resources of the current processor core are higher than or equal to the preset threshold, local cache resources are allocated to the multi-core services running on the current processor core;

[0122] If the local cache resources of the current processor core are lower than the preset threshold, the critical section corresponding to the single-core exclusive resource is invoked, and interrupt masking is enabled when entering the critical section corresponding to the single-core exclusive resource. When exiting the critical section corresponding to the single-core exclusive resource, the interrupt status of the current processor core is restored.

[0123] When running the multi-core service within a multi-core processor, if the critical resource accessed by the current processor core is a cross-core shared resource, then after acquiring the spinlock corresponding to the cross-core shared resource, the cross-core shared resource is accessed, and the spinlock is released when the cross-core shared resource is released.

[0124] The critical resource scheduling strategy optimization device for multi-core processors provided in this application obtains the inter-core call topology of critical sections within a multi-core processor by an inter-core call relationship analysis module, and further determines the resource dependencies of each critical section by analyzing the global variables of accessed resources of each critical section through a resource dependency resolution module. Then, a resource identification module identifies cross-core shared resources and single-core exclusive resources based on the inter-core call topology and resource dependencies of each critical section. The resource scheduling optimization module uses spinlocks to protect cross-core shared resources and interrupt masking to protect single-core exclusive resources. This scheme uses different protection operations for different types of shared resources (e.g., cross-core shared resources and single-core exclusive resources), thereby avoiding the problem of ineffective protection of cross-core shared resources due to unreasonable allocation of spinlocks and interrupt masking in critical sections. Furthermore, it avoids the problem of excessive cache coherence overhead caused by uniformly using spinlocks for shared resources.

[0125] This application also provides an electronic device with a transport protocol layer routing module. (See reference...) Figure 5 The diagram illustrates a structural schematic suitable for implementing the electronic device in the embodiments of this application. The electronic device in the embodiments of this application can be a controller in an in-vehicle electronic system. Figure 5 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0126] like Figure 5 As shown, the electronic device may include a processing unit (e.g., a central processing unit, ECU, etc.) 201, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 202 or a program loaded from a storage device 208 into a random access memory (RAM) 203. When the electronic device is powered on, the RAM 203 also stores various programs and data required for the operation of the electronic device. The processing unit 201, ROM 202, and RAM 203 are interconnected via a bus 204. An input / output (I / O) interface 205 is also connected to the bus 204.

[0127] Typically, the following devices can be connected to I / O interface 205: input devices 206 including, for example, touchscreens, touchpads, keyboards, mice, etc.; output devices 207 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 208 including, for example, memory cards, hard drives, etc.; and communication devices 209. Communication device 209 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 5Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have instead.

[0128] This application also provides a computer program product including computer-readable instructions, which, when executed on an electronic device, cause the electronic device to implement any of the critical resource scheduling methods provided in this application.

[0129] This application also provides a computer-readable storage medium that carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any of the critical resource scheduling methods provided in this application.

[0130] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0131] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0132] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0133] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

Claims

1. A critical resource scheduling method, characterized in that, The method includes: Analyze the relationships between critical sections in a multi-core processor and their calls by different processor cores to obtain the inter-core call topology corresponding to each critical section; Analyze the resource access information of each critical section to determine the resource dependencies of each critical section; Based on the inter-core call topology and resource dependency relationships corresponding to each critical section, cross-core shared resources and single-core exclusive resources are identified. For the protection scope of the cross-core shared resource marking spinlock, and for the scope of the single-core exclusive resource marking interruption masking, obtain the lock policy configuration for the critical resource; When running multi-core services, the critical resources are invoked according to the locking policy of the critical resources.

2. The method according to claim 1, characterized in that, The analysis of the relationships between critical regions in a multi-core processor and their calls by different processor cores, to obtain the inter-core call topology corresponding to each critical region, includes: During the process of the multi-core processor running the multi-core service, the log probes implanted in each critical section are used to record the call relationship between the critical section and different processor cores of the multi-core processor, so as to obtain the inter-core call topology corresponding to each critical section.

3. The method according to claim 1, characterized in that, The process of parsing the resource access information of each critical section to determine the resource dependencies of each critical section includes: Analyze the resource access instructions of each critical section to identify the critical resources accessed by each critical section; Based on the critical resources accessed by each critical section, a mapping relationship between shared resources and critical sections in the multi-core processor is established, and shared resources accessed by at least two critical sections are identified to obtain the resource dependencies of each critical section.

4. The method according to any one of claims 1-3, characterized in that, The identification of cross-core shared resources and single-core exclusive resources based on the inter-core call topology and resource dependencies corresponding to each critical section includes: Based on critical sections, the inter-core call topology and resource dependencies are correlated and matched to identify cross-core shared resources accessed by at least two processor cores, as well as single-core exclusive resources accessed by only one processor core.

5. The method according to claim 4, characterized in that, The step of associating and matching the inter-core call topology and the resource dependencies based on critical sections includes: For any critical section, the target processor core that calls the critical section is determined according to the inter-core call topology, and the target shared resource accessed by the critical section is determined according to the resource dependency relationship. Establish a mapping relationship between the target processor cores and the target shared resources corresponding to the same critical section.

6. The method according to any one of claims 1-3, characterized in that, The method further includes: For single-core exclusive resources accessed more frequently than a preset frequency, a preset threshold for enabling interrupt masking is configured. The preset threshold is used to enable interrupt masking when the local cache resources of the processor core are lower than the preset threshold.

7. The method according to claim 6, characterized in that, The step of configuring and invoking the critical resource according to the locking policy of the critical resource when running multi-core services includes: When running the multi-core service in a multi-core processor, if the critical resource accessed by the current processor core is a single-core exclusive resource, determine whether the local cache resource of the current processor core is lower than the preset threshold. If the local cache resources of the current processor core are higher than or equal to the preset threshold, local cache resources are allocated to the multi-core services running on the current processor core; If the local cache resources of the current processor core are lower than the preset threshold, the critical section corresponding to the single-core exclusive resource is invoked, and interrupt masking is enabled when entering the critical section corresponding to the single-core exclusive resource. When exiting the critical section corresponding to the single-core exclusive resource, the interrupt status of the current processor core is restored.

8. The method according to claim 1, characterized in that, The step of configuring and invoking the critical resource according to the locking policy of the critical resource when running multi-core services includes: When running the multi-core service within a multi-core processor, if the critical resource accessed by the current processor core is a cross-core shared resource, then after acquiring the spinlock corresponding to the cross-core shared resource, the cross-core shared resource is accessed, and the spinlock is released when the cross-core shared resource is released.

9. An electronic device, characterized in that, It includes at least one multi-core processor and memory connected to the multi-core processor, wherein: The memory is used to store computer programs; The multi-core processor is used to execute the computer program to enable the electronic device to implement the method as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The storage medium carries one or more computer programs that, when executed by an electronic device, enable the electronic device to perform the method as described in any one of claims 1 to 8.

Images