Inter-core real-time synchronization method and device based on multi-core architecture and storage medium
By employing non-preemptive spinlocks, queuing mechanisms, and priority inheritance protocols in embedded real-time systems, the schedulability and real-time performance issues of multi-core systems are resolved, enabling predictability of task blocking time and improving system efficiency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHANDONG INSPUR SCI RES INST CO LTD
- Filing Date
- 2025-11-28
- Publication Date
- 2026-04-10
Smart Images
Figure CN121833296A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of multi-core processor design, for example to an inter-core real-time synchronization method based on a multi-core architecture, a device and a storage medium. BACKGROUND
[0002] With the rapid development of information technology, embedded systems have been widely penetrated into key fields such as industrial control, intelligent vehicles, aerospace, medical devices, etc., and their functional complexity and computing demand are growing exponentially. To meet the requirements of real-time, reliability and high performance, embedded systems are evolving from traditional single-core processor architecture to multi-core processor architecture - multi-core platforms significantly improve data processing efficiency through parallel computing capabilities and become the core solution to complex task loads. However, the problem of resource sharing and task collaboration brought by multi-core also poses a severe challenge to the underlying support technology of embedded real-time systems.
[0003] In embedded real-time systems, concurrent access of tasks to shared resources (such as memory, peripheral interfaces, global variables, etc.) is a key bottleneck affecting system performance. In traditional single-core systems, task scheduling and synchronization mechanisms have formed mature solutions: priority preemption scheduling ensures that high-priority tasks are executed first, and synchronization primitives such as semaphores and mutexes are used to avoid conflicts caused by resource contention. However, in a multi-core environment, tasks can be distributed across different cores and executed in parallel, and the scenario of resource contention is more complex, making it difficult for the original single-core mechanism to be directly adapted - when tasks on multiple cores simultaneously request shared resources, if the synchronization mechanism is not properly designed, it may cause deadlocks, priority inversion, uncontrollable blocking time, etc., directly undermining the real-time performance of the system.
[0004] Current mainstream embedded real-time operating systems (such as FreeRTOS, VxWorks traditional version, etc.) still mainly support single-processor platforms, and there are significant shortcomings in adapting to multi-core platforms. On the one hand, there is a lack of multi-core architecture-oriented task scheduling algorithms: the scheduling strategy of single-core systems (such as fixed priority scheduling) cannot fully utilize multi-core parallelism, while in multi-core scheduling, global scheduling algorithms (tasks can be migrated to any core) can theoretically balance the load and improve resource utilization, but in practical applications, there are problems such as large task migration overhead, complex cache consistency maintenance, etc.; partitioned scheduling (tasks are bound to specific cores) reduces migration overhead, but can lead to uneven core load and waste parallel computing resources.
[0005] On the other hand, the lack of real-time synchronization mechanism is more prominent. In a multi-core environment, the synchronization between tasks needs to be coordinated across cores. The traditional blocking synchronization based on interrupts (such as the sleep-wakeup mechanism) will introduce additional delay, which is difficult to meet the high real-time requirement. The non-preemptive spinlock protocol, as a lightweight synchronization scheme, can reduce the context switching overhead by making the task requesting resources wait in place (rather than releasing the processor), which is theoretically more suitable for multi-core real-time scenarios. However, the combination of this protocol with the global scheduling algorithm has obvious obstacles: task migration under global scheduling may cause uncontrollable spinlock holding time, which in turn causes long blocking of other tasks; at the same time, the existing synchronization mechanism lacks compatibility support for different queuing and waiting strategies (such as FIFO, priority sorting), which limits its application in complex scenarios.
[0006] In addition, the schedulability analysis method of parallel tasks is not mature. The core requirement of real-time systems is to ensure that all tasks are completed within the deadline. In a multi-core environment, the dependence between tasks and the blocking time caused by resource competition make the schedulability determination more difficult. Existing analysis methods are mostly based on conservative blocking time estimation (such as assuming the maximum possible blocking), resulting in low analysis accuracy —— a large number of actually schedulable systems are misjudged as unschedulable, which seriously restricts the effective use of multi-core resources. At the same time, the blocking time modeling in the combination scenario of global scheduling and spinlock protocol has not formed a unified framework, further hindering the guidance of theoretical analysis to engineering practice.
[0007] In summary, in the process of multi-core and parallel development of embedded real-time systems, there are problems of poor schedulability and real-time performance of multi-core systems.
[0008] It should be noted that the information disclosed in the above background section is only used to strengthen the understanding of the background of the present application. SUMMARY
[0009] To have a basic understanding of some aspects of the disclosed embodiments, a brief overview is given below. The overview is not a comprehensive review of all aspects nor is it intended to determine key / important elements or delineate the scope of these embodiments, but to serve as an introduction to the detailed description below.
[0010] The inter-core real-time synchronization method, device and storage medium based on a multi-core architecture provided by the embodiments of the present disclosure can solve the problems of poor schedulability and real-time performance of multi-core systems in the process of multi-core and parallel development of embedded real-time systems.
[0011] The embodiments of the present disclosure provide an inter-core real-time synchronization method based on a multi-core architecture. The method is applied to a multi-core real-time operating system using a global task scheduling strategy. The method can include: A non-preemptive spinlock is used as the basic synchronization mutual exclusion mechanism to avoid the overhead of task context switching when resources are competed for. Configure a queuing mechanism for the spinlock, which is configured as a first-in-first-out queue or a priority queue to ensure the predictability of task blocking time; When priority reversal is detected due to resource contention, a critical section advancement mechanism is activated, using a priority inheritance protocol to elevate the execution privileges of low-priority tasks.
[0012] This disclosure provides an electronic device that includes at least one processor; and memory that is communicatively connected to at least one processor; The memory stores instructions that can be executed by at least one processor, which enables the at least one processor to perform the aforementioned inter-core real-time synchronization method based on a multi-core architecture.
[0013] This disclosure provides a non-transitory computer-readable storage medium storing computer instructions for causing a computer to execute the above-described inter-core real-time synchronization method based on a multi-core architecture.
[0014] The inter-core real-time synchronization method, device, and storage medium based on a multi-core architecture provided in this disclosure can achieve the following technical effects: This disclosure proposes a real-time synchronization and inter-core task scheduling method for multi-core processors and parallel tasks. It employs a combination of global scheduling and a non-preemptive spinlock protocol to improve the real-time performance and schedulability of multi-core interactions. The implemented multi-core synchronization mechanism operates normally under different queuing mechanisms. Based on linear programming and task blocking relationships, a blocking time and schedulability analysis method for non-preemptive spinlock protocols under parallel tasks and global scheduling is proposed, which can significantly improve the system's schedulability. Furthermore, when applied to multi-core architecture products and components, it can effectively improve system efficiency, maximize hardware performance, fill the gap in multi-core platform support, and adapt to the multi-core and parallel development needs of embedded systems, demonstrating significant practical value.
[0015] The above general description and the description below are exemplary and illustrative only and are not intended to limit this application. Attached Figure Description
[0016] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations and drawings do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are shown as similar elements. The drawings are not to be scaled. And wherein: Figure 1 This is a flowchart illustrating a real-time inter-core synchronization method based on a multi-core architecture provided in this embodiment of the disclosure; Figure 2 This is a schematic diagram of the locking and unlocking process of a spinlock provided in an embodiment of this disclosure; Figure 3 This is a schematic diagram of a coarse-grained resource access and fine-grained resource access process provided in an embodiment of this disclosure; Figure 4 This is a schematic diagram of the structure of a real-time inter-core synchronization device based on a multi-core architecture provided in an embodiment of this disclosure. Detailed Implementation
[0017] To provide a more detailed understanding of the features and technical content of the embodiments of this disclosure, the implementation of the embodiments of this disclosure will be described in detail below with reference to the accompanying drawings. The accompanying drawings are for illustrative purposes only and are not intended to limit the embodiments of this disclosure. In the following technical description, for ease of explanation, several details are used to provide a full understanding of the disclosed embodiments. However, one or more embodiments may still be implemented without these details. In other cases, well-known structures and devices may be simplified in their depiction to simplify the drawings.
[0018] The terms "first," "second," etc., used in the embodiments of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this disclosure described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.
[0019] Unless otherwise stated, the term "multiple" means two or more.
[0020] In this embodiment of the disclosure, the character " / " indicates that the objects before and after it are in an "or" relationship. For example, A / B means: A or B.
[0021] The term "and / or" describes an association between objects, indicating that three relationships can exist. For example, A and / or B means: A or B, or A and B.
[0022] The term "correspondence" can refer to an association or binding relationship. The correspondence between A and B means that there is an association or binding relationship between A and B.
[0023] To address the aforementioned issues, this disclosure provides a method, device, and storage medium for real-time inter-core synchronization based on a multi-core architecture.
[0024] The following description, in conjunction with the accompanying drawings, illustrates the real-time inter-core synchronization method, device, and storage medium based on a multi-core architecture provided in this disclosure.
[0025] Figure 1This is a flowchart illustrating a real-time inter-core synchronization method based on a multi-core architecture provided in this embodiment of the disclosure.
[0026] Combination Figure 1 As shown, the inter-core real-time synchronization method based on a multi-core architecture can be applied to multi-core real-time operating systems that employ a global task scheduling strategy. Specifically, this method may include: S101 uses a non-preemptive spinlock as the basic synchronization mutual exclusion mechanism to avoid the overhead of task context switching when resources are competed for. S102, Configure a queuing mechanism for the spinlock. The queuing mechanism is configured as a first-in-first-out queue or a priority queue to ensure the predictability of task blocking time. S103, when priority reversal is detected due to resource contention, the critical section advancement mechanism is activated, and the priority inheritance protocol is used to elevate the execution authority of low-priority tasks.
[0027] In some embodiments, the non-preemptive spinlock described above is implemented based on atomic operations, including Test-and-Set or Compare-and-Swap.
[0028] In some embodiments, the above-mentioned first-in-first-out queue is implemented using a linked list structure, where each node in the linked list structure includes a pointer to the task control block and a pointer to the next node.
[0029] In some embodiments, the structure of the spinlock described above includes a lock state variable and a pointer to a first-in-first-out queue.
[0030] In some embodiments, the priority inheritance protocol described above is implemented by maintaining two priority variables for each task; Among them, the base priority is defined when the task is created; the actual priority is used when the task is promoted in priority due to holding resources. When a high-priority task is waiting for resources held by a low-priority task, the actual priority of the low-priority task is raised to the same level as that of the high-priority task.
[0031] In some embodiments, the above method supports multiple resource access granularities; When using coarse-grained access, all critical section resources are protected by defining global task locks and interrupt service routine locks; When fine-grained access is required, a dedicated spinlock is assigned to each individual shared resource.
[0032] In some embodiments, the above method further includes: In coarse-grained access mode, when a task accesses a critical section, it acquires both the task lock and the interrupt service routine lock, and disables interrupts. When an interrupt service routine accesses a critical section, it only needs to acquire the interrupt service routine lock; When a task is protected by suspending the scheduler, it only acquires the task lock.
[0033] In some embodiments, the global task scheduling policy described above allows tasks to migrate between multiple processor cores.
[0034] Figure 2 This is a schematic diagram illustrating the locking and unlocking process of a spinlock according to an embodiment of this disclosure. Figure 3 This is a schematic diagram of a coarse-grained resource access and fine-grained resource access process provided in an embodiment of this disclosure, combined with... Figure 2 and Figure 3 ,right Figure 1 The inter-core real-time synchronization method based on multi-core architecture will be further described.
[0035] Multicore real-time operating systems serve as the platform for designing and implementing parallel task synchronization mechanisms. Based on a single-core real-time operating system, this paper modifies the kernel's boot process, task scheduling module, and adds an inter-core communication module. The operating system is then ported to a multicore hardware architecture, resulting in a multicore real-time operating system that supports symmetric multiprocessing architecture and global priority scheduling algorithms. By modifying its resource management module, a parallel task synchronization mechanism based on a non-preemptive spinlock protocol is implemented, supporting different resource access granularities and various cross-core queuing mechanisms.
[0036] The specific details and related steps are as follows: Parallel kernel synchronization mechanisms can be divided into three parts based on their functional purpose: synchronization mutual exclusion mechanism, queuing mechanism, and critical section advancement mechanism. The synchronization mutual exclusion mechanism uses spinlocks to avoid race conditions caused by concurrent resource access; the queuing mechanism uses a priority queue, where core tasks that enter the scheduling queue first are executed first, ensuring predictable resource access conflicts; and the critical section advancement mechanism uses priority inheritance to prevent uncontrollable priority inversion.
[0037] In a specific implementation, the synchronization and mutual exclusion mechanism is the most fundamental part of a real-time lock protocol, often implemented in single-core systems using mutexes and semaphores. However, mutexes and semaphores typically use a blocking scheduling method, where when a thread requests a lock, if the lock is already held by another thread, the thread is blocked, waiting for the lock to be released. During the blocking period, the operating system removes the task from the run queue and schedules other executable tasks, thus achieving concurrent execution. In multi-core operating systems, access to shared resources can be quite frequent, and blocking-based scheduling incurs significant context switching overhead. Therefore, in such cases, spinlocks are a more efficient synchronization method.
[0038] Spin locks can be implemented in several ways, including Test-and-Set, Compare-and-Swap, and Fetch-and-Add. Test-and-Set is an atomic operation used to uninterruptibly read the value of a boolean variable and set it to a new value. In this implementation, the task first uses the Test-and-Set operation to read the state of the specified lock and returns its old value. If the lock is not locked (return value 0), subsequent operations can proceed. If the lock is locked (return value 1), the current task enters busy-waiting mode, repeating this process until the lock is released. If the lock is not locked, the current task locks it to achieve exclusive access.
[0039] Compare-and-Swap (CAS) is another common implementation of spinlocks. It atomically compares the current value of a shared variable with its expected value. If they are equal, the new value is written to the specified variable. In the spinlock acquisition operation, the task attempts to use a CAS operation to change the lock's state from unlocked to locked. If the CAS operation succeeds, the lock acquisition is successful; otherwise, the task continues spinning and waiting. In the spinlock release operation, the task uses a CAS operation to change the lock's state from locked to unlocked, allowing other tasks to acquire the lock.
[0040] Spin locks in synchronization and mutual exclusion mechanisms are the most basic version, belonging to the category of queueless spin locks. Under intense contention for access to shared resources, queueless spin locks can cause severe starvation effects for some tasks and significantly reduce the availability of real-time systems. Therefore, predictable blocking time has become a necessary requirement for real-time lock protocols.
[0041] Using blocking queues for sorting is the primary method to ensure predictable blocking times. Commonly used queue mechanisms include first-in-first-out (FIFO) queues and priority queues. FIFO queues arrange tasks attempting to acquire spinlocks in a first-come, first-served order, while priority queues arrange tasks according to their priority. Each method has its advantages and disadvantages. Priority queues are favorable for high-priority tasks, satisfying their urgency, but can easily cause starvation for low-priority tasks. FIFO queues avoid starvation, but the urgency differences between real-time tasks based on priority are not reflected in this case. Therefore, this paper implements both methods, and the appropriate queuing method should be chosen based on the actual situation. Spinlocks based on FIFO queues can be improved from queueless spinlocks. This invention uses a linked list to implement the FIFO queue. First, a fifoTaskNode structure is defined to represent a task node in the FIFO queue. This structure contains two members: pxTCB, representing the task's TCB pointer, and next, a pointer to the next task node. The `fifoQueue` structure represents the first-in-first-out (FIFO) queue for this spinlock, containing a `head` member pointing to the head of the queue and a `tail` member pointing to the tail of the queue. Finally, the `fifoLock` structure represents a spinlock based on a FIFO queue, also having two members: one is the spinlock itself, `ulFLock`, and the other is a pointer to the FIFO queue of this spinlock, `pxFQueue`. Figure 2 The diagram shows the locking and unlocking process of a spinlock based on a first-in-first-out queue.
[0042] The introduction of a queuing mechanism means that the function ulSpinFifoLock, used to lock the spinlock, must not only lock the spinlock but also perform queue operations.
[0043] Because spinlocks are a non-preemptive locking protocol, priority inversion is difficult to avoid when multiple tasks with different priorities access the same shared resource simultaneously. Therefore, the operating system needs a method to effectively mitigate the priority inversion problem, namely, a critical section advancement mechanism. FreeRTOS GFP-Spin uses priority inheritance as its critical section advancement mechanism. This method raises the priority of a lower-priority task to the same level as the highest-priority task waiting for that resource when the lower-priority task accesses it. This allows the lower-priority task to execute as quickly as possible, thus avoiding prolonged blocking of the high-priority task due to priority inversion. In its implementation, each task in FreeRTOS GFP-Spin has two priority variables: a base priority and an actual priority. When a higher-priority task B is waiting to access the shared resource held by task A, task A raises its actual priority to the same level as task B. After releasing the shared resource, the actual priority falls back to task A's base priority. In implementation, each task's TCB has variables uxPriority and uxBasePriority, which represent the task's original priority and current priority, respectively. The former is defined when the task is created, while the latter is related to the priority increase obtained by the task through the priority inheritance mechanism when it last accessed the shared resource.
[0044] Resource access granularity Having completed the construction of the synchronization mechanism between the multi-core real-time system and its parallel tasks, the next step is to consider how tasks should access shared resources through this synchronization mechanism. The primary issue is determining the granularity of resource access. Shared resource access can be categorized into fine-grained and coarse-grained based on the granularity of resource division and acquisition. Traditional serial real-time tasks typically use coarse-grained locks to prevent deadlocks. In coarse-grained resource access, resources are divided into larger units, each of which is acquired and released by the task as a whole. For example, the big kernel lock (BKL) used in early versions of Linux, essentially a global kernel lock, is a global spin lock. Only the task that acquires the lock can access critical section resources; other tasks must wait for the lock to be released. In extreme cases, if all tasks in the system access different critical sections protected by the same coarse-grained lock, the tasks must also execute sequentially. In this situation, parallel tasks will degenerate into serial tasks, resulting in a significant waste of multiprocessor resources. Clearly, coarse-grained locks cannot meet the needs of parallel tasks. Fine-grained locks, in extreme cases, can allocate independent locks to every shared resource in the operating system, greatly avoiding conflicts between parallel tasks and maximizing system parallelism. Starting with Linux version 2.6.39, large kernel locks have been completely replaced by fine-grained locking mechanisms. For example... Figure 3The diagram illustrates coarse-grained and fine-grained resource access. Tasks A and C access shared resource R1, task B accesses shared resource R2, and task C accesses shared resource R3. Tasks A and C both need to access shared resource R3, resulting in resource contention. Only task B needs to access shared resource R2, avoiding resource conflicts with tasks A and C. However, with coarse-grained locking, all tasks require mutual exclusion access through a single lock, leading to conflicts between task B and tasks A and C. This increases resource contention, restricts system flexibility, reduces concurrency efficiency, and in extreme cases, can even cause parallel tasks to execute serially. In the fine-grained locking model, resources R1, R2, and R3 are protected by different locks. Tasks C and A experience contention due to accessing the same resource, but there are no conflicts with task B. Therefore, the system achieves higher concurrency efficiency. However, finer-grained resource access can also lead to more frequent deadlocks. This requires application developers to carefully design lock acquisition and release strategies, placing higher demands on application system design capabilities. Developers should carefully choose the granularity of resource access according to actual needs and make corresponding modifications during application implementation.
[0045] The parallel task synchronization mechanism designed and implemented in this paper supports resource access at various granularities, ranging from global kernel locks to allocating a lock for each shared resource. Nested fine-grained locks are even more complex, and research in this area has always been one of the most challenging and cutting-edge aspects of real-time systems; therefore, nested resource access is outside the scope of this paper.
[0046] For coarser-grained resource access, this paper designs two global kernel locks: a task lock and an interrupt service routine lock, hereinafter referred to as the task lock and ISR lock, respectively. In this case, when a task accesses a critical section, interrupts need to be disabled and both locks need to be acquired simultaneously. When an interrupt service routine accesses a critical section, only the ISR lock needs to be acquired. When a task suspends the scheduler, only the task lock needs to be acquired, and the scheduler counter is incremented. This ensures that when a task is in a critical section, no other task or interrupt service routine can enter the critical section. Similarly, when a task is in a segment protected by the suspended scheduler, other tasks cannot enter, but the interrupt service routine can still continue to run. When an interrupt service routine is in a critical section, no other task or interrupt service routine can enter the critical section. However, consider the following scenario: when an interrupt service routine on one core is accessing a critical section, another core will be unable to perform mutual exclusion access to the resource through the suspended scheduler. This is because the suspended scheduler needs to increment the suspended counter, and accessing this counter requires acquiring both the ISR lock and the task lock simultaneously. Therefore, FreeRTOS GFP-Spin provides a separate set of functions for entering and leaving critical sections within interrupt service routines. These functions ensure that interrupt service routines complete access to critical sections as quickly as possible to reduce the probability of the above-mentioned situations occurring. All shared resources in the kernel are protected by this set of functions.
[0047] For finer-grained resource access, taking an extreme example of resource access granularity, i.e., each shared resource is assigned a lock, without considering resource nesting, assuming the shared resource is a read-write peripheral, a dedicated spinlock is defined in the peripheral's driver to protect this resource. The function ulSpinFifoLock(), which attempts to access the peripheral, is used to encapsulate the function to acquire the corresponding spinlock. The function ulSpinFifoUnLock(), which releases the corresponding spinlock, is used to encapsulate the function to release the spinlock, which is used in the interface function exitPeripheral(), which ends access to the peripheral.
[0048] The inter-core real-time synchronization method based on multi-core architecture disclosed in this disclosure aims to solve the problems of insufficient support for multi-core platforms in mainstream embedded real-time systems, lack of real-time synchronization and scheduling mechanisms, and low accuracy of schedulability analysis.
[0049] The core improvements of this method include: proposing a real-time synchronization and inter-core task scheduling method for multi-core processors and parallel tasks, and adopting a combination of global scheduling and non-preemptive spinlock protocol to improve the real-time performance and schedulability of multi-core interaction; the implemented multi-core synchronization mechanism can run normally under different queuing mechanisms; based on linear programming and task blocking relationships, proposing a blocking time and schedulability analysis method for non-preemptive spinlock protocol under parallel tasks and global scheduling, which significantly improves the system schedulability.
[0050] This disclosure can be applied to multi-core architecture products and components, effectively improving system efficiency, leveraging hardware performance, filling the gap in multi-core platform support, and adapting to the multi-core and parallel development needs of embedded systems, thus having significant practical value.
[0051] This disclosure employs a combination of global scheduling and a non-preemptive spinlock protocol to improve the real-time performance and schedulability of multi-core system interactions. Furthermore, the multi-core synchronization mechanism implemented in this system can operate normally when using different queuing mechanisms. Moreover, this disclosure also proposes a non-preemptive spinlock protocol for parallel tasks and global scheduling based on linear programming and task blocking relationships. Using the multi-core synchronization method proposed in this patent can significantly improve the schedulability of the system and the schedulability of real-time systems.
[0052] Combination Figure 4 As shown in the illustration, this disclosure also provides a real-time inter-core synchronization device 400 based on a multi-core architecture, including a processor 404 and a memory 401. Optionally, the system may further include a communication interface 402 and a bus 403. The processor 404, communication interface 402, and memory 401 can communicate with each other via the bus 403. The communication interface 402 can be used for information transmission. The processor 404 can call logical instructions in the memory 401 to execute the real-time inter-core synchronization method based on a multi-core architecture described in the above embodiments.
[0053] Furthermore, the logic instructions in the aforementioned memory 401 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium.
[0054] The memory 401, as a computer-readable storage medium, can be used to store software programs and computer-executable programs, such as program instructions / modules corresponding to the methods in the embodiments of this disclosure. The processor 404 executes functional applications and data processing by running the program instructions / modules stored in the memory 401, thereby realizing the real-time inter-core synchronization method based on a multi-core architecture in the above embodiments.
[0055] The memory 401 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the terminal device. Furthermore, the memory 401 may include high-speed random access memory and may also include non-volatile memory.
[0056] This disclosure provides a computer-readable storage medium storing computer-executable instructions, which are configured as a real-time inter-core synchronization method based on a multi-core architecture.
[0057] The aforementioned computer-readable storage medium may be a transient computer-readable storage medium or a non-transitory computer-readable storage medium.
[0058] The technical solutions of this disclosure can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes one or more instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of this disclosure. The aforementioned storage medium can be a non-transitory storage medium, including: a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and other media capable of storing program code; it can also be a transient storage medium.
[0059] The foregoing description and accompanying drawings fully illustrate embodiments of the present disclosure to enable those skilled in the art to practice them. Other embodiments may include structural, logical, electrical, procedural, and other changes. The embodiments represent only possible variations. Individual components and functions are optional unless explicitly required, and the order of operation may vary. Parts and features of some embodiments may be included in or replace parts and features of other embodiments. As used in the description of the embodiments, the singular forms “a,” “an,” and “the” are intended to equally include the plural forms unless the context clearly indicates otherwise. Similarly, the term “and / or” as used herein means including one or more of the associated listed items and all possible combinations thereof. Additionally, when used in this application, the terms “comprise” and its variations “comprises” and / or “comprising” refer to the presence of stated features, integrals, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof. Unless otherwise specified, an element defined by the phrase "comprising a..." does not exclude the presence of other identical elements in the process, method, or apparatus that includes the element. In this document, each embodiment may focus on describing the differences from other embodiments, and similar or identical parts between embodiments can be referred to mutually. For methods, products, etc., disclosed in the embodiments, if they correspond to the method section disclosed in the embodiments, then the relevant parts can be referred to the description of the method section.
[0060] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this disclosure. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.
[0061] The methods and products (including but not limited to devices and equipment) disclosed in the embodiments herein can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of units may be merely a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms. Units described as separate components may or may not be physically separate, and 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 units can be selected to implement this embodiment according to actual needs. In addition, the functional units in the embodiments of this disclosure may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
[0062] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than that shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. In the descriptions corresponding to the flowcharts and block diagrams in the accompanying drawings, the operations or steps corresponding to different blocks may also occur in a different order than disclosed in the description, and sometimes there is no specific order between different operations or steps. For example, two consecutive operations or steps may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. Each block in a block diagram and / or flowchart, and combinations of blocks in a block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.
[0063] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.
[0064] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.
[0065] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.
[0066] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).
[0067] The systems and technologies described herein can be implemented in computing systems that include back-end components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include front-end components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.
[0068] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.
[0069] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this disclosure can be achieved, and this is not limited herein.
[0070] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.
Claims
1. A real-time inter-core synchronization method based on a multi-core architecture, characterized in that, The method is applied to a multi-core real-time operating system employing a global task scheduling strategy. The method includes: A non-preemptive spinlock is used as the basic synchronization mutual exclusion mechanism to avoid the overhead of task context switching when resources are competed for. Configure a queuing mechanism for the spinlock, which is configured as a first-in-first-out queue or a priority queue to ensure the predictability of task blocking time; When priority reversal is detected due to resource contention, a critical section advancement mechanism is activated, using a priority inheritance protocol to elevate the execution privileges of low-priority tasks.
2. The method according to claim 1, characterized in that, The non-preemptive spinlock is implemented based on atomic operations, including Test-and-Set or Compare-and-Swap.
3. The method according to claim 1, characterized in that, The first-in-first-out queue is implemented using a linked list structure, where each node includes a pointer to the task control block and a pointer to the next node.
4. The method according to claim 1, characterized in that, The structure of the spinlock includes a lock state variable and a pointer to the first-in-first-out queue.
5. The method according to claim 1, characterized in that, The priority inheritance protocol is implemented by maintaining two priority variables for each task; Among them, the base priority is defined when the task is created; the actual priority is used when the task is promoted in priority due to holding resources. When a high-priority task is waiting for resources held by a low-priority task, the actual priority of the low-priority task is raised to the same level as that of the high-priority task.
6. The method according to claim 1, characterized in that, The method supports multiple resource access granularities; When using coarse-grained access, all critical section resources are protected by defining global task locks and interrupt service routine locks; When fine-grained access is required, a dedicated spinlock is assigned to each individual shared resource.
7. The method according to claim 6, characterized in that, The method further includes: In coarse-grained access mode, when a task accesses a critical section, it acquires both the task lock and the interrupt service routine lock, and disables interrupts. When an interrupt service routine accesses a critical section, it only needs to acquire the interrupt service routine lock; When a task is protected by suspending the scheduler, it only acquires the task lock.
8. The method according to claim 1, characterized in that, The global task scheduling policy allows tasks to migrate between multiple processor cores.
9. An electronic device, characterized in that, include: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-8.
10. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-8.