A safe and efficient mixed-granularity real-time synchronization method

Abstract

The application discloses a safe and efficient mixed-granularity real-time synchronization method, and belongs to the technical field of shared resource synchronization of multi-core real-time systems. The method is applied to a multi-core real-time system and comprises the following steps: creating a resource lock for each shared resource, allocating resources that can be accessed simultaneously to the same resource group, merging two resource groups into one if the two resource groups have the same shared resource, creating an admission control layer for each resource group, and the admission control layer comprising a multi-resource token, a plurality of single-resource tokens and a global single-resource request counter; when a single-resource request is received, permitting a single-resource token holder to request a resource lock and permitting a resource lock holder to access a corresponding shared resource; and when a multi-resource request is received, permitting a multi-resource token holder to access shared resources in a resource group. The application is used to solve the problems of deadlock and concurrent efficiency of synchronous access of multiple shared resources in a multi-core processor environment.

Description

Technical Field

[0001] This application belongs to the field of multi-real-time system shared resource synchronization technology, and in particular relates to a safe and efficient hybrid granularity real-time synchronization method. Background Technology

[0002] In multi-core synchronous systems, concurrent threads may need to access multiple shared resources during execution, such as shared data, memory, and I / O devices. Typically, locking mechanisms are used to ensure synchronized and mutually exclusive access to shared resources, thus avoiding race conditions caused by data access conflicts. Lock-based synchronization mechanisms can be further divided into coarse-grained locks and fine-grained locks. Coarse-grained locks do not allow nested access to multiple shared resources; if multiple shared resources need to be accessed simultaneously, a single lock must be used to protect the shared resources that may be accessed at the same time. Conversely, fine-grained locks allow nested access to multiple shared resources. Therefore, different shared resources can be protected using different locks.

[0003] Under coarse-grained locking, even if there are no conflicts in accessing different resources, all shared resources protected by the same lock must adhere to the principle of synchronization and mutual exclusion. Therefore, the system's concurrency and scalability are severely negatively impacted. In contrast, fine-grained locking requires incremental locking for nested access to multiple shared resources. Inconsistencies in the locking order of different threads can lead to deadlocks, and each locking operation carries the risk of being blocked. This causes significant delays for threads needing nested access to shared resources, thus affecting real-time performance. Summary of the Invention

[0004] The purpose of this application is to overcome the shortcomings of the prior art and provide a safe and efficient hybrid granularity real-time synchronization method. While using coarse-grained locks to avoid nested access to multiple resources, it supports the use of fine-grained locks to access a single shared resource, thereby improving the concurrency performance of the system accessing shared resources while eliminating the risk of deadlock.

[0005] The objective of this application is achieved through the following technical solution: A safe and efficient hybrid-granularity real-time synchronization method, applied to a multi-core real-time system, the method comprising: Create a resource lock for each shared resource, assign resources that can be accessed simultaneously to the same resource group, and merge the two resource groups into one if any two resource groups have the same shared resource. An admission control layer is created for each resource group, which includes a multi-resource token, multiple single-resource tokens, and a global single-resource request counter. When a single resource request is received, the holder of the single resource token is allowed to request the resource lock, and the holder of the resource lock is allowed to access the corresponding shared resource. When a multi-resource request is received, the holder of the multi-resource token is allowed to access the shared resources within the resource group.

[0006] Furthermore, the admission control layer also includes a waiting and queuing mechanism: All multi-resource requests are queued in a first-in-first-out (FIFO) multi-resource token waiting queue. The objects of multi-resource requests in the waiting queue are multi-resource request nodes. Each multi-resource request node is responsible for maintaining a FIFO single-resource token waiting queue for single-resource requests for different shared resources within the resource group, and also maintains a local single-resource request counter mounted on the multi-resource request node.

[0007] Furthermore, the method also includes: A multi-resource request can obtain a multi-resource token if and only if a multi-resource request is at the head of the multi-resource token waiting queue and the current global single-resource request counter is zero.

[0008] Furthermore, the method also includes: When a multi-resource request completes the execution of the critical section, the multi-resource request first sets the value of the global single-resource request counter to the value of the local single-resource request counter, then releases the multi-resource token, and dequeues from the multi-resource token waiting queue.

[0009] Furthermore, the method also includes: If there are no multi-resource requests currently being executed or waiting, the single resource request directly obtains a single resource token, increments the global single resource request counter by one, and requests the corresponding resource lock. Otherwise, the single resource request needs to be attached to the single resource token waiting queue of the last multi-resource request node in the current multi-resource token waiting queue, and the local single resource request counter of the attached multi-resource request node is incremented by one.

[0010] Furthermore, the method also includes: A single resource request can acquire a single resource token and request the corresponding resource lock if and only if a single resource request in a single resource token waiting queue is at the head of the queue, and the multi-resource request to which the queue belongs has released its multi-resource token.

[0011] Furthermore, the method also includes: Once a single resource request completes and releases the corresponding resource lock, the global single resource request counter is decremented by one, the corresponding single resource token is released, and the token is dequeued from the single resource token waiting queue.

[0012] Furthermore, the resource lock also includes a waiting and queuing mechanism: All requests for a resource lock are queued in a first-in-first-out resource waiting queue. A resource lock can be acquired if and only if a resource request is at the head of the resource waiting queue.

[0013] Furthermore, the method also includes: Once a single resource request completes the execution of the critical section, the single resource request immediately releases the corresponding resource lock and is dequeued from the single resource waiting queue.

[0014] The beneficial effects of this application are as follows: (1) The hybrid granularity real-time synchronization method proposed in this application distinguishes between single resource access and multi-resource access by means of an admission control layer and avoids nested locking of multi-resource access. Therefore, it can effectively avoid deadlock caused by inconsistent locking order when nested accessing multiple shared resources, and has security guarantee.

[0015] (2) The hybrid granularity real-time synchronization method proposed in this application allows requests for a single different shared resource to be executed in parallel when there are no earlier and uncompleted multi-resource requests, thus having higher concurrency.

[0016] (3) This application uses a hierarchical and phased queuing system with three queues: a multi-resource token waiting queue, a single-resource token waiting queue, and a fine-grained lock resource waiting queue. This ensures that when multi-resource requests and single-resource requests are waiting to enter the critical section, they can only be blocked by earlier, incomplete requests for resources within the same resource group. Therefore, both multi-resource requests and single-resource requests can be guaranteed to complete within a finite time, thus providing a real-time guarantee. Attached Figure Description

[0017] Figure 1 This is a flowchart of a safe and efficient real-time synchronization method for mixed granularity according to the present invention. Figure 2 This is a schematic diagram of the architecture of the layered parallel lock protocol of this invention. Detailed Implementation

[0018] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, unless otherwise specified, the following embodiments and features in the embodiments can be combined with each other.

[0019] Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0020] In traditional methods, under coarse-grained locking, even if there are no conflicts in accessing different resources, all shared resources protected by the same lock must adhere to the principle of synchronization and mutual exclusion. Therefore, the system's concurrency and scalability are severely negatively impacted. Under fine-grained locking, nested access to multiple shared resources requires incremental locking. Inconsistencies in the locking order of different threads can lead to deadlocks, and each locking operation has the potential to be blocked. This causes threads needing nested access to shared resources to experience significant delays, thus affecting real-time performance.

[0021] To address the aforementioned technical problems, the following embodiments of a safe and efficient real-time synchronization method for mixed granularity are proposed in this application.

[0022] Reference Figure 1 ,like Figure 1 The diagram shown is a flowchart of a secure and efficient real-time synchronization method with mixed granularity according to this application. The method specifically includes the following steps: A1 Resource Grouping: The system first creates a resource lock for each shared resource. If any two resources in the system may be accessed simultaneously, these two resources are assigned to a resource group. If any two resource groups contain the same shared resource, these two resource groups are merged into one. The system creates an admission control layer for each resource group.

[0023] The A2 admission control layer is used to implement admission control for resource access requests within a resource group. It consists of a multi-resource token, multiple single-resource tokens, and a global single-resource request counter. The multi-resource token must be held exclusively with other tokens (including multi-resource and single-resource tokens), while a single-resource token may be held simultaneously with other single-resource tokens. Requests for shared resources are categorized into single-resource requests and multi-resource requests based on the number of resources accessed within the resource group. A single-resource request can only access one shared resource within the resource group, while a multi-resource request can access any number of shared resources within the resource group.

[0024] B1: A single resource request must obtain a single resource token before it can further request a fine-grained resource lock. Only after the single resource request obtains the resource lock can it access the corresponding shared resource. After the shared resource access is completed, the resource request immediately releases the resource lock and single resource token it holds.

[0025] B2: Multi-resource requests require acquiring a multi-resource token before accessing shared resources within a resource group. Unlike single-resource requests, multi-resource requests do not require acquiring a resource lock for the shared resource to be accessed. After accessing the shared resource is complete, the resource request immediately releases its multi-resource token.

[0026] A3 Admission Control Layer Waiting and Queuing Mechanism: All multi-resource requests must be queued in a first-in-first-out (FIFO) multi-resource token waiting queue. An object in the multi-resource token waiting queue for a multi-resource request is called a multi-resource request node. Each multi-resource request node is responsible for maintaining a first-in-first-out (FIFO) single-resource token waiting queue for single-resource requests for different shared resources within the resource group, and maintaining a local single-resource request counter attached to that multi-resource request node.

[0027] B1: A multi-resource request can acquire a multi-resource token if and only if it is at the head of the multi-resource token waiting queue and the current global single-resource request counter is zero. After a multi-resource request completes the execution of its critical section, it first sets the value of its global single-resource request counter to the value of its local single-resource request counter, and then releases the multi-resource token.

[0028] B2: A single resource request can acquire a single resource token if and only if it is at the head of the single resource token waiting queue and the multi-resource request to which the single resource token waiting queue belongs has released its multi-resource token. If there are no multi-resource requests currently executing or waiting, the single resource request can directly acquire the single resource token, increment the global single resource request counter, and request the corresponding resource lock. Otherwise, the single resource request needs to be attached to the single resource token waiting queue of the last multi-resource request node in the current multi-resource token waiting queue, and the local single resource request counter of the attached multi-resource request node is incremented by one. When a single resource request completes its resource request and releases the corresponding resource lock, it first decrements the value of the global single resource request counter and releases its single resource token. Requests waiting in the token waiting queue need to continuously check whether they can acquire a token, which is the same as the waiting mechanism of a spin lock.

[0029] A4 Fine-grained Resource Lock Waiting and Queuing Mechanism: All requests for fine-grained resource locks must also queue in a first-in-first-out (FIFO) resource waiting queue. A resource request can acquire a resource lock if and only if it is at the head of the resource waiting queue. Requests waiting in the queue need to continuously check whether they can acquire the resource lock, which is the same as the waiting mechanism of spin locks. When a resource request completes the execution of the critical section, it immediately releases the corresponding resource lock.

[0030] This embodiment provides an admission control method that supports both coarse-grained locking (for multiple resource requests) and fine-grained locking (for single resource requests). This method mainly ensures that multiple resource requests can access all shared resources within a resource group without acquiring locks on multiple shared resources. Therefore, it effectively avoids deadlock problems caused by inconsistent nested locking order and improves the concurrency of the system.

[0031] This embodiment improves upon the hierarchical queuing mechanism based on FIFO multi-resource token waiting queues, single-resource token waiting queues, and fine-grained locks for resource waiting queues. This hierarchical queuing mechanism queues single-resource requests arriving after a multi-resource request in the single-resource token waiting queue of the multi-resource request node, prioritizing the resource and restricting the order in which they acquire their single-resource tokens. This prevents single-resource requests that were initially waiting for tokens from moving to the front of the queue after a multi-resource request completes and releases its token. Therefore, this hierarchical queuing mechanism ensures that single-resource requests and multi-resource requests can only be blocked by earlier, incomplete requests for resources within the same resource group, effectively guaranteeing system real-time performance while improving system concurrency.

[0032] Reference Figure 2 ,like Figure 2 The diagram shows the architecture of the hierarchical parallel lock protocol of this invention. Two shared resources in the system are included in a resource group. g j In, that is g j ={l 1 ,l 2 } Suppose there are 2 multi-resource requests and 6 single-resource requests in the system, and the arrival sequence of the resource requests is shown in the figure. Assuming that all resource requests in the figure have arrived before the critical section of the first resource request completes execution, the queuing order of the resource requests in different queues and the order of token acquisition are shown in the figure.

[0033] (1) When t=t 0 At that time, l 1 The first single resource request arrives. Since there are no ongoing or waiting multi-resource requests, this single resource request can directly acquire the single resource token and request a fine-grained resource lock, while simultaneously setting the global single resource request counter to 1. Since no other resource requests are accessing the resource at this time... l 1 The resource request is at the head of the resource request queue and has been received. l 1The resource lock allows entry into the critical section for execution.

[0034] (2) When t=t 1 At that time, l 1 The second single resource request arrives. Since there are no multi-resource requests currently executing or waiting, this single resource request can directly acquire the single resource token and request a fine-grained resource lock, while simultaneously setting the global single resource request counter to 2. However, other resource requests are already accessing the resource at this time. l 1 The resource request is second in the resource request queue and must wait for the request at the head of the queue to complete and release the resource lock before it can be acquired. l 1 The resource lock is acquired, and execution is carried out in the critical section.

[0035] (3) When t=t 2 At this point, the first multi-resource request arrives. Since there are already single-resource requests being executed or waiting, meaning the global single-resource request counter is 2, this multi-resource request needs to queue in the multi-resource token waiting queue, waiting for the global single-resource request counter to become 0.

[0036] (4) When t=t 3 At that time, l 1 The third single resource request arrives. Since there are already waiting multi-resource requests, this single resource request needs to be processed before the first multi-resource request arrives. l 1 The single resource token is queued in the waiting queue, waiting for the multi-resource request to be completed.

[0037] (5) When t=t 4 At that time, l 2 The first single resource request arrives. Since there are already waiting multi-resource requests, this single resource request needs to wait for the first multi-resource request to arrive. l 2 The single resource token is queued in the waiting queue, waiting for the multi-resource request to be completed.

[0038] (6) When t=t 5 At that time, l 1 The fourth single resource request arrives. Since there are already waiting multi-resource requests, this single resource request needs to be processed before the first multi-resource request arrives. l 1The single resource token is queued in the waiting queue, waiting for the previous single resource request in the queue to be completed.

[0039] (7) When t=t 6 At this point, the second multi-resource request arrives. Since there are already multi-resource requests being executed or waiting, this multi-resource request needs to be queued in the multi-resource token waiting queue, waiting for the previous multi-resource request to complete and for the global single-resource request counter to become 0.

[0040] (8) When t=t 7 At that time, l 2 The second single-resource request arrives. Since there are already multiple waiting multi-resource requests, this single-resource request needs to be processed before the second multi-resource request arrives. l 2 The single resource token is queued in the waiting queue, waiting for the multi-resource request to be completed.

[0041] Based on the examples above, the first and second pairs... l 1 A single resource request can simultaneously acquire a single resource token. After these two single resource requests are completed, the global single resource request counter becomes 0. The first multi-resource request can then acquire a multi-resource token and enter the critical section for execution, accessing all shared resources within the resource group without needing to request fine-grained resource locks. After the first multi-resource request completes, it first sets the global single resource request counter to its local single resource request counter. Since three single resource requests are attached to this single resource request node, its counter value is 3. Then, it releases the multi-resource token. At this point, the multi-resource requests attached to the first multi-resource node... l 1 The third one is related to l 2 The first single resource request is at the head of its respective single resource token waiting queue and can obtain a single resource token simultaneously, while... l 1 The fourth single resource request needs to wait for the response. l 1 The third single-resource request can only obtain a single-resource token after releasing its single-resource token. The second multi-resource request can only obtain a multi-resource token after all the single-resource requests attached to the first multi-resource request have been executed and the global single-resource request counter has been decremented to 0. The last one... l 2A single-resource request must wait for the second multi-resource request to complete and release its multi-resource token before it can obtain the single-resource token. In summary, multi-resource requests can access multiple shared resources without nested locking, thus avoiding the deadlock problem that nested locking can cause. At the same time, single-resource requests can execute in parallel when there are no resource conflicts, thereby improving the system's concurrency performance.

[0042] The layered parallel lock protocol proposed in this embodiment distinguishes between single-resource access and multi-resource access by using an admission control layer and avoids nested locking of multi-resource access. Therefore, it can effectively avoid deadlock caused by inconsistent locking order when nesting access to multiple shared resources, thus ensuring security.

[0043] The hierarchical parallel lock protocol proposed in this embodiment has the following capabilities: in the absence of multiple resource requests that arrive earlier and have not yet been completed, it allows requests for a single different shared resource to be executed in parallel, thus achieving higher concurrency.

[0044] This embodiment employs a layered and phased queuing system using three queues: a multi-resource token waiting queue, a single-resource token waiting queue, and a fine-grained lock resource waiting queue. This ensures that when multi-resource requests and single-resource requests are waiting for tokens, they can only be blocked by earlier, incomplete requests for resources within the same resource group. Therefore, both multi-resource requests and single-resource requests can be guaranteed to complete within a finite time, ensuring real-time performance.

[0045] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A safe and efficient method for real-time synchronization of mixed particle sizes, characterized in that, The method is applied to a multi-verification real-time system, and the method includes: Create a resource lock for each shared resource, assign resources that can be accessed simultaneously to the same resource group, and merge the two resource groups into one if any two resource groups have the same shared resource. An admission control layer is created for each resource group, which includes a multi-resource token, multiple single-resource tokens, and a global single-resource request counter. When a single resource request is received, the holder of the single resource token is allowed to request the resource lock, and the holder of the resource lock is allowed to access the corresponding shared resource. When a multi-resource request is received, the holder of the multi-resource token is allowed to access the shared resources within the resource group.

2. The safe and efficient real-time synchronization method for mixed particle size as described in claim 1, characterized in that, The access control layer also includes a waiting and queuing mechanism: All multi-resource requests are queued in a first-in-first-out (FIFO) multi-resource token waiting queue. The objects of multi-resource requests in the waiting queue are multi-resource request nodes. Each multi-resource request node is responsible for maintaining a FIFO single-resource token waiting queue for single-resource requests for different shared resources within the resource group, and also maintains a local single-resource request counter mounted on the multi-resource request node.

3. The safe and efficient real-time synchronization method for mixed particle size as described in claim 1, characterized in that, The method further includes: A multi-resource request can obtain a multi-resource token if and only if a multi-resource request is at the head of the multi-resource token waiting queue and the current global single-resource request counter is zero.

4. The safe and efficient real-time synchronization method for mixed particle size as described in claim 3, characterized in that, The method further includes: When a multi-resource request completes the execution of the critical section, the multi-resource request first sets the value of the global single-resource request counter to the value of the local single-resource request counter, then releases the multi-resource token, and dequeues from the multi-resource token waiting queue.

5. The safe and efficient real-time synchronization method for mixed particle size as described in claim 1, characterized in that, The method further includes: If there are no multi-resource requests currently being executed or waiting, the single resource request directly obtains a single resource token, increments the global single resource request counter by one, and requests the corresponding resource lock. Otherwise, the single resource request needs to be attached to the single resource token waiting queue of the last multi-resource request node in the current multi-resource token waiting queue, and the local single resource request counter of the attached multi-resource request node is incremented by one.

6. The safe and efficient real-time synchronization method for mixed particle size as described in claim 5, characterized in that, The method further includes: A single resource request can acquire a single resource token and request the corresponding resource lock if and only if a single resource request in a single resource token waiting queue is at the head of the queue, and the multi-resource request to which the queue belongs has released its multi-resource token.

7. The safe and efficient real-time synchronization method for mixed particle size as described in claim 5, characterized in that, The method further includes: Once a single resource request completes and releases the corresponding resource lock, the global single resource request counter is decremented by one, the corresponding single resource token is released, and the token is dequeued from the single resource token waiting queue.

8. The safe and efficient real-time synchronization method for mixed particle size as described in claim 6, characterized in that, The resource lock also includes a waiting and queuing mechanism: All requests for a resource lock are queued in a first-in-first-out resource waiting queue. A resource lock can be acquired if and only if a resource request is at the head of the resource waiting queue.

9. The safe and efficient real-time synchronization method for mixed particle size as described in claim 5, characterized in that, The method further includes: Once a single resource request completes the execution of the critical section, the single resource request immediately releases the corresponding resource lock and is dequeued from the single resource waiting queue.

Images