Priority scheduling based multi-core platform spinlock management system and control method thereof
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- NANJING ACOINFO TECH CO LTD
- Filing Date
- 2026-03-20
- Publication Date
- 2026-06-26
AI Technical Summary
In existing multi-core processor platforms, task priority is not considered, which may cause low-priority tasks to acquire spinlocks faster than high-priority tasks. This affects the real-time performance and deterministic nature of the operating system's scheduling, as well as the uncertainty of task acquisition and priority inversion issues after the spinlock is released.
A priority-based multi-core platform spinlock management system is adopted. Spinlocks are managed through a linked list and sorted according to task priority to ensure that high-priority tasks acquire spinlocks first. The priority adjustment module can temporarily adjust the priority of low-priority tasks when necessary to avoid priority reversal.
It improves the real-time performance and determinism of operating system scheduling, ensures that high-priority tasks use resources first, optimizes the execution order of tasks, avoids priority inversion, and improves scheduling efficiency.
Smart Images
Figure CN121880034B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the technical field of spinlock management technology, specifically to a multi-core platform spinlock management system and its control method based on priority scheduling. Background Technology
[0002] On a multi-core processor platform, multiple tasks execute simultaneously on different processor cores, and the execution order of these tasks is typically managed by the partitioned operating system. When encountering mutual exclusion access to resources, the operating system uses spinlocks to resolve the mutual exclusion problem between multiple tasks, thereby ensuring exclusive access for each task. When tasks running on multiple processor cores need to access the same resource, a spinlock is used to acquire the mutual exclusion right to that resource. Tasks on cores that have not acquired the spinlock cannot access the resource and can only infinitely loop through the spinlock variable until it becomes available. Once the spinlock becomes available, a task on one of the cores acquires the spinlock and gains the right to use the resource.
[0003] Therefore, this method of acquiring and releasing spinlocks has the following defects and shortcomings in practical use:
[0004] 1) The priorities of tasks running on different cores were not taken into account. When multiple tasks are waiting for a spinlock, the lower priority task may acquire the spinlock faster than the higher priority task, thus proceeding to execution faster and affecting the real-time performance of the operating system scheduling.
[0005] 2) After the spinlock is released, other cores waiting for the task on that spinlock will randomly acquire the spinlock, and the scheduling is uncertain.
[0006] 3) When a low-priority task holds a spinlock, a high-priority task must wait, which will cause priority inversion.
[0007] Therefore, there is an urgent need to provide a new solution to address the defects and shortcomings of the existing technologies. Summary of the Invention
[0008] To address the deficiencies and shortcomings of the existing technologies, this invention provides a multi-core platform spinlock management system and its control method based on priority scheduling.
[0009] The specific solution provided by this invention is as follows:
[0010] A priority-based multi-core platform spinlock management system, comprising:
[0011] The first core, in its initial state, possesses a spinlock corresponding to the resource;
[0012] The second core, there are multiple second cores, and multiple second cores need to use the resources to run corresponding tasks;
[0013] A spinlock, which corresponds to a resource, allows a second core to acquire the right to use a resource only after the first core releases the spinlock and any second core obtains the spinlock corresponding to that resource.
[0014] Its features are:
[0015] The spinlock is equipped with a linked list corresponding to itself. According to the priority of the second core's own running task that initiates the resource usage request, the corresponding task running by the spinlock is added to different positions in the linked list, and the current state of the task is set to the waiting state.
[0016] After the first core releases the spinlock, the second core, which is at the top of the list, is selected sequentially, and its current state of running task is adjusted to the wake-up state. At this time, it is confirmed that the current second core has the spinlock corresponding to the resource, and thus it is confirmed that the current second core has obtained the right to use the resource.
[0017] As a further preferred embodiment of the present invention, each resource is provided with only a unique spinlock corresponding to it, and the spinlock can only be owned by a single core at any given time.
[0018] As a further preferred embodiment of the present invention, the linked list is a singly linked list.
[0019] As a further preferred embodiment of the present invention, the system is further provided with a priority adjustment module, which can adjust the priority of the task currently holding the spinlock running on the core according to the relationship between the priority of the task currently holding the spinlock and the priority of the task currently holding the spinlock running on the core.
[0020] As a further preferred embodiment of the present invention
[0021] If the priority of the task running on the core currently holding the spinlock is lower than the priority of the task running on the core that initiated the use request, the priority adjustment module can temporarily increase the priority of the task running on the core currently holding the spinlock, and record the initial priority of the task running on the core currently holding the spinlock. After the core currently holding the spinlock releases the spinlock, the priority adjustment module restores the priority of the task running on that core to the initial priority.
[0022] If the priority of the task running on the core currently holding the spinlock is not lower than the priority of the task running on the core that initiated the use request, the priority adjustment module will not adjust the priority of the task running on the core currently holding the spinlock.
[0023] As a further preferred embodiment of the present invention, if the priority of the task currently running on the core holding the spinlock is lower than the priority of the task running on the core that initiated the use request, the priority adjustment module temporarily increases the priority of the task currently running on the core holding the spinlock, which must satisfy the requirement that the priority of the task currently running on the core holding the spinlock is temporarily increased to be no lower than the priority of the task running on the core that initiated the use request.
[0024] As a further preferred embodiment of the present invention, when the corresponding task of the second core running itself is added to different positions of the linked list according to the priority of the task that initiated the resource usage request:
[0025] Add the corresponding task running on the second highest priority core to the head of the linked list;
[0026] Add the corresponding task running on the second core with the lowest priority to the tail of the linked list;
[0027] Sort the remaining tasks in descending order of priority and add them between the head and tail of the linked list.
[0028] As a further preferred embodiment of the present invention
[0029] When the current state of a task is waiting, the current state value corresponding to that task is recorded as 1;
[0030] When a task is in a woken-up state, the current state value corresponding to that task is recorded as 0.
[0031] As a further preferred embodiment of the present invention, when the current state of the second core running task is a waiting state, the second core running task reads its current state in a cyclic and uninterrupted manner until its current state value changes from 1 to 0.
[0032] Furthermore, the present invention also provides a control method for a multi-core platform spinlock management system based on priority scheduling, characterized by comprising the following steps:
[0033] S100: Multiple secondary cores initiate resource usage requests to run their own tasks;
[0034] S200: Based on the priority of the second core's own running task that initiated the resource usage request, add the corresponding task running by the second core to different positions in the linked list, and set the current state of the task to the waiting state;
[0035] S300: After the first core releases the spinlock, the second core, which is at the top of the list, is selected sequentially, and its current state of running task is adjusted to the wake-up state. At this time, it is confirmed that the current second core has the spinlock corresponding to the resource, and thus it is confirmed that the current second core has obtained the right to use the resource.
[0036] Compared with existing technologies, the technical effects that this invention can achieve include:
[0037] 1) This invention provides a multi-core platform spinlock management system and control method based on priority scheduling. Regardless of the number of CPU processing cores managed in the operating system, cores with high-priority task execution needs can acquire spinlocks first, thereby enabling tasks running on them to use corresponding resources first, improving the real-time performance and determinism of the operating system scheduling.
[0038] 2) This invention provides a multi-core platform spinlock management system and its control method based on priority scheduling, which enables other CPU processing cores corresponding to tasks waiting to run to acquire spinlocks corresponding to resources according to their task priorities, thereby enabling tasks running on them to use corresponding resources according to their task priorities, and improving the scheduling efficiency of the operating system scheduling process.
[0039] 3) This invention provides a multi-core platform spinlock management system and its control method based on priority scheduling. By setting a priority adjustment module, the priority adjustment module can adjust the priority of the task running on the core currently holding the spinlock according to the relationship between the priority of the task running on the core currently holding the spinlock and the priority of the task running on the core initiating the use request. Thus, when the priority of the task running on the core currently holding the spinlock is lower than the priority of the task running on the core initiating the use request, the priority of the task running on the core currently holding the spinlock can be temporarily increased. At the same time, the initial priority of the task running on the core currently holding the spinlock is recorded. After the core currently holding the spinlock releases the spinlock, the priority of the task running on that core is restored to the initial priority, so as to ensure that the core currently holding the spinlock can execute and release the spinlock as soon as possible, while avoiding priority inversion caused by the waiting process. Attached Figure Description
[0040] Figure 1 The diagram shown is a logical structure diagram of the system provided by the present invention.
[0041] Figure 2 The diagram shown is a flowchart of the steps of the method provided by the present invention. Detailed Implementation
[0042] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0043] In the description of this invention, it should be noted that the terms "upper," "lower," "inner," "outer," "front end," "rear end," "both ends," "one end," and "the other end," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.
[0044] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installed," "equipped with," "connected," etc., should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium; it can be a connection within two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.
[0045] [First Embodiment]
[0046] like Figure 1 As shown, the first embodiment of the present invention provides a multi-core platform spinlock management system based on priority scheduling. The system includes:
[0047] The first core, in its initial state, possesses a spinlock corresponding to the resource, at which point the first core has the right to use the resource; the resource can be any type of resource required by the first core to run the task on it, such as an interface or serial port, etc. In this embodiment, the serial port is selected as the resource;
[0048] There are multiple second cores, and each second core needs to use resources to run its corresponding task. Since the resources are currently occupied by the first core, the multiple second cores are in a waiting state and need to wait for the spinlock corresponding to the resource to be released before they can acquire the spinlock corresponding to the resource.
[0049] Spin locks are associated with resources. It is worth noting that in this embodiment, each resource is only assigned a unique spin lock, and the spin lock can only be owned by a single core at any given time. Therefore, when any second core initiates a usage request for a resource, the second core can only acquire the right to use the resource after the first core releases its spin lock and the second core obtains the spin lock corresponding to that resource.
[0050] The improvement of this embodiment compared to the prior art is as follows:
[0051] The spinlock has a linked list corresponding to itself. Based on the priority of the second core's own running task that initiates the resource usage request, the corresponding task running by the spinlock is added to different positions in the linked list, and the current state of the task is set to the waiting state.
[0052] After the first core releases its spinlock, the second core, which is at the top of the list, is selected sequentially, and its current state is adjusted to the wake-up state. At this point, it is confirmed that the second core has the spinlock corresponding to the resource, and thus the second core has acquired the right to use the resource.
[0053] This configuration enables the following: regardless of the number of CPU cores managed by the operating system, cores with high-priority task execution needs can acquire spinlocks first, allowing tasks running on them to use corresponding resources preferentially, thus improving the real-time performance and determinism of the operating system's scheduling. Simultaneously, other CPU cores with waiting tasks can acquire spinlocks for resources according to their task priorities, allowing tasks running on them to use corresponding resources according to their priorities, thereby improving the scheduling efficiency of the operating system's scheduling process.
[0054] As a further preferred embodiment, the linked list used in this embodiment is a singly linked list, which can be named SL_slList, so that after the first core releases the spinlock, it can select the second core in the waiting state according to the order of the tasks added to the linked list.
[0055] In this embodiment, the priority of each second core's own running tasks is preset. Alternatively, a score can be calculated based on factors such as task urgency, difficulty, compatibility, and workload. The task priority is then determined according to this score to meet the priority processing requirements. This ensures that cores with high-priority task requirements can acquire spinlocks first, allowing their running tasks to use corresponding resources preferentially, thus improving the real-time performance and determinism of operating system scheduling. Furthermore, the priority of each second core's own running tasks can be adjusted as needed to meet the processing order requirements of tasks with different priorities.
[0056] In this embodiment, the system is also provided with a priority adjustment module, which can adjust the priority of the task running on the core that currently holds the spinlock according to the relationship between the priority of the task running on the core that currently holds the spinlock and the priority of the task running on the core that initiated the use request.
[0057] Its specific working process is as follows:
[0058] If the priority of the task running on the core currently holding the spinlock is lower than the priority of the task running on the core that initiated the use request, the priority adjustment module can temporarily increase the priority of the task running on the core currently holding the spinlock, and at the same time record the initial priority of the task running on the core currently holding the spinlock (which can be done by adding a corresponding field in the system). After the core currently holding the spinlock releases the spinlock, the priority adjustment module restores the priority of the task running on that core to the initial priority.
[0059] If the priority of the task running on the core currently holding the spinlock is not lower than the priority of the task running on the core that initiated the use request, the priority adjustment module will not adjust the priority of the task running on the core currently holding the spinlock.
[0060] Furthermore, the following conditions must be met: If the priority of the task running on the core currently holding the spinlock is lower than the priority of the task running on the core that initiated the use request, the priority adjustment module shall temporarily increase the priority of the task running on the core currently holding the spinlock, provided that the priority of the task running on the core currently holding the spinlock is temporarily increased to a level not lower than the priority of the task running on the core that initiated the use request.
[0061] The above settings ensure that the core currently holding the spinlock can execute and release the spinlock as soon as possible, while avoiding priority inversion caused by the waiting process.
[0062] For example, when task B is running on the second core 1 and its priority value is 20; task C is running on the second core 2 and its priority value is 30; and the higher the priority value, the lower the priority, that is, B's priority is higher than C's priority; but if the second core 2 (low priority) holds a spinlock at this time, and the second core 1 (high priority) initiates a usage request, priority inversion will occur during the waiting process.
[0063] Therefore, the priority adjustment module can record the initial priority of task C running on the second core 2 as 30, and temporarily increase its priority to a higher priority than B (for example, the priority value can be temporarily adjusted to 15, and the priority value is temporarily decreased due to the temporary increase in priority), until the second core 2 releases the spinlock, and then restores its initial priority value of 30.
[0064] In this embodiment, when the corresponding task of the second core that initiated the resource usage request is added to different positions in the linked list according to its own priority:
[0065] Add the corresponding task running on the second highest priority core to the head of the linked list;
[0066] Add the corresponding task running on the second core with the lowest priority to the tail of the linked list;
[0067] The remaining tasks are sorted in descending order of priority and added between the head and tail of the linked list; so that after the first core releases the spinlock, it can select the second core, whose tasks are in a waiting state, in a one-way sequential manner according to the order in which the tasks were added to the linked list.
[0068] In this embodiment, a current state SPINQ_atomicPend is set for each task;
[0069] When the current state of a task, SPINQ_atomicPend, is in a waiting state, the current state value corresponding to that task is recorded as 1.
[0070] When the current state of a task, SPINQ_atomicPend, is in the awakened state, the current state value corresponding to that task is recorded as 0.
[0071] When the current state SPINQ_atomicPend of the second core running task is in a waiting state, the second core running task continuously reads its current state SPINQ_atomicPend in a loop until its current state value changes from 1 to 0.
[0072] like Figure 1 As shown, taking a three-core processor scenario as an example, in this scenario, tasks on multiple cores need to use the same serial port resource to send data:
[0073] Task A runs on the first core;
[0074] Task B is running on the second core 1, and the priority value of B is 20;
[0075] Task C is running on the second core 2, and the priority value of C is 30;
[0076] Furthermore, the larger the priority value, the lower the priority; that is, B has a higher priority than C.
[0077] Task A running on the first core first acquires the spinlock of the serial port and uses the serial port to send data;
[0078] Task B running on the second core 1 also needs to use the serial port to send data. Since task A on the first core is using the serial port, the second core 1 waits for the spinlock to be released. At the same time, task C on the second core 2 also needs to use the serial port to send data, so the second core 2 also waits for the spinlock to be released.
[0079] After the first core finishes using the serial port, it releases the spinlock corresponding to the serial port. At this time, the second core 1 and the second core 2 have an equal probability of acquiring the spinlock. If the second core 2 acquires the spinlock, it will cause the data in the lower priority task C to be sent first, while the data in the higher priority task B will be sent later, which will lead to a decrease in the real-time performance of the system.
[0080] In this embodiment, based on the priority scheduling method, data from higher-priority tasks can be sent first.
[0081] When the first core has already acquired a spinlock for a certain resource, and the tasks running in the second core 1 and the second core 2 also need to use the resource, the two processor cores, the second core 1 and the second core 2, acquire the spinlock in parallel.
[0082] Configure a singly linked list SL_slList for the spinlock and configure a current state SPINQ_atomicPend for each second core;
[0083] The priority value of task B running on the second core 1 is 20, and the priority value of task C running on the second core 2 is 30. Since the priority of B is higher than the priority of C, the priority of the second core 1 is higher than the priority of the second core 2.
[0084] During the process of two cores acquiring the spinlock, task B is added to the head of the SL_slList linked list, and task C is added to the tail of the SL_slList linked list. If other cores also need to acquire the spinlock, they are inserted between the head and tail of the SL_slList linked list according to the priority of the tasks running on them.
[0085] When the spinlock is not acquired, the current state SPINQ_atomicPend of both the second core 1 and the second core 2 is in a waiting state, which is 1. Then, they continuously read their respective current states until the current state becomes 0, which is the wake-up state.
[0086] After the first core finishes using its resources, it retrieves the second core with the highest task execution priority from the head of the SL_slList singly linked list. At this point, it sets the current state SPINQ_atomicPend of the task running in that core to 0 and wakes up the task.
[0087] [Second Embodiment]
[0088] The second embodiment of the present invention also provides a control method for a multi-core platform spinlock management system based on priority scheduling, characterized by comprising the following steps:
[0089] S100: Multiple secondary cores initiate resource usage requests to run their own tasks;
[0090] S200: Based on the priority of the second core's own running task that initiates the resource usage request, add the corresponding task running by the second core to different positions in the linked list, and set the current state of the task to the waiting state.
[0091] S300: After the first core releases the spinlock, the second core, which is at the top of the list, is selected sequentially, and its current state of running task is adjusted to the wake-up state. At this time, it is confirmed that the current second core has the spinlock corresponding to the resource, and thus it is confirmed that the current second core has obtained the right to use the resource.
[0092] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.
Claims
1. A multi-core platform spinlock management system based on priority scheduling, the system comprising: The first core, in its initial state, possesses a spinlock corresponding to the resource; The second core, there are multiple second cores, and multiple second cores need to use the resources to run corresponding tasks; A spinlock, which corresponds to a resource, allows a second core to acquire the right to use a resource only after the first core releases the spinlock and any second core obtains the spinlock corresponding to that resource. Its features are: The spinlock is equipped with a linked list corresponding to itself. According to the priority of the second core's own running task that initiates the resource usage request, the corresponding task running by the spinlock is added to different positions in the linked list, and the current state of the task is set to the waiting state. After the first core releases the spinlock, the second core, which is at the top of the list, is selected sequentially from the list, and its current state of running task is adjusted to the wake-up state. At this time, it is confirmed that the current second core has the spinlock corresponding to the resource, and thus it is confirmed that the current second core has obtained the right to use the resource. The system is also equipped with a priority adjustment module, which can adjust the priority of the task running on the core currently holding the spinlock according to the relationship between the priority of the task running on the core currently holding the spinlock and the priority of the task running on the core that initiated the use request. If the priority of the task running on the core currently holding the spinlock is lower than the priority of the task running on the core that initiated the use request, the priority adjustment module can temporarily increase the priority of the task running on the core currently holding the spinlock, and record the initial priority of the task running on the core currently holding the spinlock. After the core currently holding the spinlock releases the spinlock, the priority adjustment module restores the priority of the task running on that core to the initial priority. If the priority of the task running on the core currently holding the spinlock is not lower than the priority of the task running on the core that initiated the use request, the priority adjustment module will not adjust the priority of the task running on the core currently holding the spinlock. If the priority of the task currently running on the core holding the spinlock is lower than the priority of the task running on the core that initiated the use request, the priority adjustment module temporarily increases the priority of the task currently running on the core holding the spinlock, provided that the priority of the task currently running on the core holding the spinlock is temporarily increased to a level not lower than the priority of the task running on the core that initiated the use request.
2. The multi-core platform spinlock management system based on priority scheduling according to claim 1, characterized in that: Each resource is assigned a unique spinlock, and this spinlock can only be held by a single core at any given time.
3. The multi-core platform spinlock management system based on priority scheduling according to claim 1, characterized in that: The linked list used is a singly linked list.
4. The multi-core platform spinlock management system based on priority scheduling according to claim 1, characterized in that: When adding the corresponding task of the second core running itself to different positions in the linked list according to the priority of the task that initiated the resource usage request: Add the corresponding task running on the second highest priority core to the head of the linked list; Add the corresponding task running on the second core with the lowest priority to the tail of the linked list; Sort the remaining tasks in descending order of priority and add them between the head and tail of the linked list.
5. The multi-core platform spinlock management system based on priority scheduling according to claim 1, characterized in that: When the current state of a task is waiting, the current state value corresponding to that task is recorded as 1; When a task is in a woken-up state, the current state value corresponding to that task is recorded as 0.
6. The multi-core platform spinlock management system based on priority scheduling according to claim 5, characterized in that: When the current state of the task running on the second core is in a waiting state, the task running on the second core continuously reads its current state in a loop until its current state value changes from 1 to 0.
7. The control method for a multi-core platform spinlock management system based on priority scheduling according to any one of claims 1-6, characterized in that: Includes the following steps: S100: Multiple secondary cores initiate resource usage requests to run their own tasks; S200: Based on the priority of the second core's own running task that initiated the resource usage request, add the corresponding task running by the second core to different positions in the linked list, and set the current state of the task to the waiting state; S300: After the first core releases the spinlock, the second core, which is at the top of the list, is selected sequentially, and its current state of running task is adjusted to the wake-up state. At this time, it is confirmed that the current second core has the spinlock corresponding to the resource, and thus it is confirmed that the current second core has obtained the right to use the resource.