Access method, device and equipment and computer readable storage medium

Abstract

The invention discloses an access method, device and equipment and a computer readable storage medium, which are applied to the technical field of computers, and comprise the following steps: loading a consistency label list corresponding to an authorized access consistency domain; when an access request is initiated to a target consistency domain in the shared memory, performing permission verification on the access request through the consistency label list and the target consistency domain; when the permission verification is passed, determining whether an access conflict exists or not through a local access state cache and the type of the access request; if the access conflict exists, a controller arbitration engine is triggered, and the access request is executed according to an arbitration result; and if the access conflict does not exist, executing the access request. According to the method, the consistency label list and the access state cache are formulated for each device, the consistency problem existing when multiple devices access the shared memory in an existing system is solved, and efficient, low-conflict and flexible consistency guarantee can be achieved under the scene that multiple devices concurrently access the shared memory.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to an access method, apparatus, device, and computer-readable storage medium. Background Technology

[0002] In the CXL (Compute Express Link, a high-speed interconnect protocol between central processing units and devices) architecture, especially in memory pooling scenarios based on the CXL.mem protocol (one of the core sub-protocols in the CXL protocol suite, focusing on memory expansion and direct access scenarios), multiple devices can access the same shared memory resource simultaneously, thereby realizing a memory-as-a-service system architecture. However, as the number of accessing devices increases, the consistency problem of shared memory becomes increasingly significant.

[0003] Therefore, how to provide a consistent access method that simultaneously possesses high performance, low conflict, and high flexibility in scenarios involving high concurrency, multiple devices, and shared memory is a technical problem that urgently needs to be solved. Summary of the Invention

[0004] In view of this, the purpose of the present invention is to provide an access method, apparatus, device and computer-readable storage medium that solves the problems of low performance, high conflict and poor flexibility of the existing consistent access method in high concurrency, multi-device and shared memory scenarios.

[0005] To address the aforementioned technical problems, the present invention provides an access method applied to a device connected to a controller, comprising: Load the consistency tag list corresponding to the authorized access consistency domain; the consistency tag list includes the device's read permission, write permission, or read-write permission for the authorized access consistency domain; When an access request is initiated to the target consistency domain in shared memory, the access request is verified using the consistency tag list and the target consistency domain. When the permission verification is successful, the local access state cache and the type of the access request are used to determine whether there is an access conflict; the access state cache stores the current access state information of the authorized access consistency domain. If an access conflict exists, the controller arbitration engine is triggered, and the access request is executed according to the arbitration result; If there is no access conflict, the access request is executed.

[0006] On the one hand, load the list of consistency tags corresponding to the authorized access consistency domains, including: When the controller completes the steps of consistency domain partitioning, tag identifier allocation, and access permission determination, it loads the consistency tag list; the consistency tag list is composed of the tag identifiers corresponding to the authorized access consistency domains. The controller completes the steps of consistency domain partitioning, label assignment, and access permission determination, including: The controller divides the shared memory into consistency domains, assigns corresponding labels to each consistency domain, and determines the label corresponding to the authorized access consistency domain based on the device's access permissions.

[0007] On the one hand, when an access request is initiated to the target consistency domain in shared memory, the access request is authenticated using the consistency tag list and the target consistency domain, including: When the access request is initiated to the target consistency domain in the shared memory, the consistency tag list is queried; If the target consistency domain exists in the consistency label list and has a valid label identifier of the corresponding operation type, then the permission verification is successful. Otherwise, the access request is rejected and an exception is reported.

[0008] On the one hand, when permission verification passes, the system determines whether an access conflict exists by checking the local access state cache and the type of the access request, including: When the current access state of the target consistency domain is determined to be idle through the access state cache, there is no access conflict. When the current access state of the target consistency domain is determined to be a shared read state through the access state cache, and the type of the access request is a read request type, then there is no access conflict. When the current access state of the target consistency domain is determined to be a shared read state through the access state cache, and the type of the access request is a write request type, then a first access conflict exists. When the current access state of the target consistency domain is determined to be write exclusive through the access state cache, a second access conflict exists. When the current access state of the target consistency domain is determined to be in a conflict state through the access state cache, a third access conflict exists; the conflict state is either a waiting state where the arbitration request has not been completed or a transitional state where the protocol interaction has not been closed.

[0009] On the one hand, if an access conflict exists, the controller arbitration engine is triggered, and the access request is executed according to the arbitration result, including: If the first access conflict exists, the controller arbitration engine is triggered so that the controller arbitration engine can determine whether to trigger the access request escalation mechanism; If the upgrade mechanism of the access request is triggered, the read operation of the target consistency domain is stopped, the access request is executed, and the current access state of the consistency domain is updated to write exclusive state. If the escalation mechanism of the access request is not triggered, the process proceeds to the arbitration stage to determine the arbitration result, and the access request is executed according to the arbitration result.

[0010] On the one hand, if an access conflict exists, the controller arbitration engine is triggered, and the access request is executed according to the arbitration result, including: If the second access conflict exists, the controller arbitration engine is triggered so that the controller arbitration engine obtains the first device information that exclusively occupies the target consistency domain, the relevant parameters of the access request, and the second device information in the waiting queue. Based on the first device information, the second device information, and the relevant parameters, the access request is arbitrated according to the first preset rule, the arbitration result is output, and the access request is executed according to the arbitration result.

[0011] On the one hand, if an access conflict exists, the controller arbitration engine is triggered, and the access request is executed according to the arbitration result, including: If the third access conflict exists, the controller arbitration engine is triggered so that the controller arbitration engine can obtain the specific type and associated information of the state in the conflict; If, based on the specific type and associated information, the target consistency domain is determined to be in a waiting state where the arbitration request is incomplete, then the access request is added to the current request queue, and all requests in the current request queue are reordered according to the second preset rule to determine the arbitration order. If the target consistency domain is determined to be a transitional state where the protocol interaction is not closed based on the specific type and associated information, then the incomplete protocol interaction is monitored. After the interaction is closed, the access request is added to the current request queue, and all requests in the current request queue are reordered according to the second preset rule to determine the arbitration order. The arbitration result is determined according to the arbitration order, and the access request is executed according to the arbitration result.

[0012] On the one hand, when the current access state of the target consistency domain is determined to be idle through the access state cache, there is no access conflict, including: When the current access state of the target consistency domain is determined to be idle through the access state cache, and the type of the access request is a write request, it is determined whether there are other write requests initiated by other devices to the target consistency domain at the same time. If no other write requests are made, then there is no access conflict; If any other write request exists, then a fourth access conflict exists.

[0013] On the one hand, if an access conflict exists, the controller arbitration engine is triggered, and the access request is executed according to the arbitration result, including: If the fourth access conflict exists, the controller arbitration engine is triggered to obtain the other devices and their device information; the other write requests and the access requests are sorted according to the device information and priority policy to determine the access priority; and the access requests are executed according to the access priority.

[0014] On the one hand, if there is no access conflict, the access request is executed, including: If no access conflict exists, determine the type of the access request; If the access request is of type read request, then the access request is executed, and the current access state of the target consistency domain is updated to shared read state. If the access request is a write request, then the access request is executed, and the current access state of the target consistency domain is updated to write exclusive state.

[0015] On the one hand, if the access request is of type write request, then the access request is executed, including: If the access request is a write request, the access request is stored in a local write buffer. Based on the timing information and write address of the local write buffer, the data to be written is batched and written back to the target consistency domain in the shared memory.

[0016] On the one hand, after loading the list of consistency tags corresponding to the authorized access consistency domains, it also includes: During system operation, the consistency tag list is dynamically adjusted in response to device hot-plugging, permission changes, or task migration events.

[0017] The present invention also provides an access device for use in a device connected to a controller, comprising: The loading module is used to load a list of consistency tags corresponding to the authorized access consistency domain; the list of consistency tags includes the device's read permission, write permission, or read-write permission for the authorized access consistency domain; The permission verification module is used to verify the permission of the access request by using the consistency tag list and the target consistency domain when an access request is initiated to the target consistency domain in shared memory. The conflict detection module is used to determine whether there is an access conflict when the permission verification is successful by using the local access state cache and the type of the access request; the access state cache stores the current access state information of the authorized access consistency domain; The first request execution module is used to trigger the controller arbitration engine if an access conflict exists, and execute the access request according to the arbitration result; The second request execution module is used to execute the access request if there is no access conflict.

[0018] The present invention also provides an access device, comprising: Memory, used to store computer programs; A processor for implementing the access methods described above when executing the computer program.

[0019] The present invention also provides a computer-readable storage medium storing computer-executable instructions, which, when loaded and executed by a processor, implement the access method described above.

[0020] The present invention also provides a computer program product, including a computer program / instruction that, when executed by a processor, implements the steps of the access method described above.

[0021] As can be seen from the above technical solution, the present invention loads a consistency tag list corresponding to the authorized access consistency domain; the consistency tag list includes the device's read permission, write permission, or read-write permission for the authorized access consistency domain; when an access request is initiated to the target consistency domain in shared memory, the access request is verified by the consistency tag list and the target consistency domain; when the permission verification is successful, the existence of an access conflict is determined by the local access state cache and the type of the access request; the access state cache stores the current access state information of the authorized access consistency domain; if an access conflict exists, the controller arbitration engine is triggered, and the access request is executed according to the arbitration result; if no access conflict exists, the access request is executed.

[0022] The beneficial effects of this invention are as follows: It establishes a consistent label list for each device and loads it locally, realizing access control within the device and achieving fine-grained, consistent, regionalized access isolation; furthermore, the device's local access state cache enables access conflict detection within the device, providing rapid local response and unified reporting to the controller. It constrains the legality and consistency of access from the device side, effectively reducing the propagation scope of access conflicts and decreasing reliance on constant central coordination; it solves the consistency problem existing in existing systems when multiple devices access shared memory, enabling efficient, low-conflict, and flexible consistency assurance in scenarios where multiple devices concurrently access shared memory.

[0023] In addition, the present invention also provides an access device, apparatus, and computer-readable storage medium that have the same beneficial effects as described above. Attached Figure Description

[0024] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0025] Figure 1 A flowchart of an access method provided in an embodiment of the present invention; Figure 2 A CXL architecture diagram provided for an embodiment of the present invention; Figure 3 An example diagram of a CXL controller provided in an embodiment of the present invention; Figure 4 A flowchart illustrating an access method provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of an access device provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of an access device provided in an embodiment of the present invention. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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.

[0027] With the rapid development of heterogeneous computing, various computing devices, including CPUs (Central Processing Units), GPUs (Graphics Processing Units), FPGAs (Field-Programmable Gate Arrays), and AI (Artificial Intelligence) accelerators, are widely deployed in data centers and edge computing devices. To improve the efficiency of data interaction between these devices, the CXL protocol was developed. It supports multiple devices accessing shared memory through a unified interconnect interface, enabling more efficient data exchange. Under the CXL architecture, especially in memory pooling scenarios based on the CXL.mem protocol, multiple devices can simultaneously access the same shared memory resource, thus realizing a memory-as-a-service system. However, as the number of accessing devices increases, the consistency problem of shared memory becomes increasingly significant.

[0028] Currently, solutions to the shared memory consistency problem in CXL mainly fall into two categories: (1) Access control mechanism based on global locks: Before a device accesses shared memory, it uniformly requests a global lock and releases it after the access is completed. This method requires requesting and releasing the lock for each access, resulting in high communication costs. Furthermore, it cannot achieve fine-grained access control, leading to lock conflicts and lock queuing. Moreover, it has low concurrency, which severely impacts system throughput, especially in high IO (input / output) scenarios such as AI and networking. (2) Cache consistency simulation mechanism based on software transactions: Each device maintains a local cache and controls access consistency through software transactions. This method is complex to implement and requires the introduction of a large amount of transaction judgment logic. Furthermore, consistency checks are usually implemented in software, resulting in high overhead and high latency. In addition, transaction rollback costs are high, and system performance drops sharply when frequent conflict rollbacks are triggered. In addition, some solutions attempt to use a Coherence Directory to coordinate the consistency state between devices, but when the number of devices is large, the directory query cost is high. The system scalability is limited, making it difficult to adapt to future CXL architecture scenarios that require shared access from dozens of devices. It is evident that existing technologies have not yet provided a consistent access mechanism that simultaneously possesses high performance, low conflict, and high flexibility in high-concurrency, multi-device, and shared-memory usage scenarios. This leads to the following problems: (1) frequent access conflicts between devices, resulting in performance degradation; (2) write-overwriting, dirty reads, write-back latency, and other phenomena cause data inconsistency; (3) difficulty in managing consistency at the device granularity; and (4) serious system bottlenecks and latency. Therefore, there is an urgent need for a mechanism that can efficiently achieve shared-memory consistency control in multi-device concurrent scenarios, and should possess characteristics such as adjustable granularity, conflict awareness, and low intervention to adapt to the high-performance system architecture under the CXL protocol.

[0029] Please refer to the details. Figure 1 , Figure 1 A flowchart illustrating an access method provided in an embodiment of the present invention. The method may include: S101: Load the list of consistency tags corresponding to the authorized access consistency domains.

[0030] The execution entity in this embodiment is a device connected to a controller, which can be a CXL controller. This method is applicable to CXL architecture environments and has good versatility, extending to memory consistency control scenarios in other multi-core / multi-device architectures such as Chiplet, NUMA (Non-Uniform Memory Access Architecture), and SoC (System on a Chip).

[0031] Furthermore, the loading of the consistency tag list corresponding to the authorized access consistency domain can specifically include the following steps: when the controller completes the consistency domain partitioning, tag identifier allocation, and access permission determination steps, the consistency tag list is loaded; the consistency tag list consists of the tag identifiers corresponding to the authorized access consistency domain.

[0032] Specifically, during system initialization, the controller divides shared memory into multiple Coherence Regions (CRs) according to a set granularity and assigns a unique consistency tag ID to each CR, thereby supporting controllable and traceable cross-device shared access. Each CR-Tag Unit within a device loads a list of Tag IDs (i.e., consistency tag lists) corresponding to the CRs (coherence regions) it is authorized to access into a local tag mapping table. This table meticulously records the read, write, or read-write permissions that the device has for each related CR. The device uses the tag mapping table to determine the set of CRs it can access, avoiding conflicts caused by out-of-order access. Of course, the controller also has the ability to merge, migrate, and release CRs.

[0033] Furthermore, this embodiment provides a specific partitioning method, which may include the following steps: analyzing the access characteristics of data in shared memory, determining the set of devices accessing each piece of data and the logical relationships between the data; aggregating data accessed by the same set of devices and whose logical relationships meet preset conditions, dividing them into a consistency domain, and assigning a unique label to each consistency domain; recording the device access set and label of each consistency domain, and storing them in the system's consistency domain configuration table. In this way, data within the same consistency domain is accessed by the same set of devices, avoiding invalid access to the domain by unrelated devices, reducing the probability of cross-domain access conflicts between different device groups, and reducing cross-domain access conflicts; data with strong logical relationships are in the same domain, allowing for unified maintenance of access status (such as shared read, exclusive write), reducing the overhead of cross-domain synchronization, and improving consistency maintenance efficiency; by binding the label to the device access set, the access permissions of a device to a certain domain can be quickly verified (matching the consistency label list and the label), eliminating the need to verify the permissions of individual data entries one by one, thus improving verification efficiency.

[0034] Furthermore, after loading the consistency tag list corresponding to the authorized access consistency domain, the system can also include the following steps: During system runtime, in response to device hot-plugging, permission changes, or task migration events, the consistency tag list is dynamically adjusted. This way, when situations such as a device being suddenly plugged in / out, a device's access permissions changing, or a task being transferred from device A to device B occur, the system will update the device's consistency tag list in real time, ensuring that the consistency tag list always matches the current device state, permissions, and task requirements. This allows the system to adapt to dynamic hardware changes without reconfiguration, reducing task interruptions and providing high flexibility and adaptability, thus improving security. Moreover, the granularity of the tags can be flexibly configured (e.g., by page, by segment, by object) to adapt to different memory management strategies and application scenarios.

[0035] S102: When an access request is initiated to the target consistency domain in shared memory, the access request is verified using the consistency tag list and the target consistency domain.

[0036] When a device initiates an access request to a Consistency Domain (CR) in shared memory, the device's Consistency Tag Unit (CR-Tag Unit) forms the first line of defense for access control. This unit focuses on managing basic access permissions between the device and a specific Consistency Domain (CR). Specifically, it verifies access permissions for the request using a consistency tag list and the target consistency domain. If verification fails—that is, for an access request initiated by a device without access rights—the controller will notify it to perform a write rollback via a dedicated protocol and clear its write buffer. Simultaneously, the controller will issue a "state refresh command," forcing the relevant device to refresh its Access State Cache to ensure that all devices are aware of the latest consistency state.

[0037] Furthermore, when an access request is initiated to the target consistency domain in shared memory, the access request is validated using the consistency tag list and the target consistency domain. Specifically, this may include the following steps: when an access request is initiated to the target consistency domain in shared memory, the consistency tag list is queried; if the target consistency domain exists in the consistency tag list and has a valid tag identifier for the corresponding operation type, the permission verification passes; otherwise, the access request is rejected, and an exception is reported. Thus, when a device attempts to initiate access to a specific CR, the device's CR-Tag Unit performs a preliminary quick query: if the requested target CR exists in the consistency tag list and has a valid tag for the corresponding operation type, the permission verification passes; otherwise, the access request is immediately rejected and an exception is reported. This not only prevents any form of unauthorized device access to shared memory but also reduces the potential probability of write conflicts at the source by limiting the legitimate access range of each device.

[0038] S103: When the permission verification is successful, determine whether there is an access conflict by checking the local access state cache and the type of access request.

[0039] After passing the permission verification in step S102, the processing of the access request enters the second stage, which involves judging the current real-time state of the target CR. An Access State Cache is introduced, located locally on the device, storing the current access state information of several consistency domains of interest, such as, but not limited to: Idle (status code 00, indicating no device is accessing it exclusively or in a shared manner), Shared Read (status code 01, indicating one or more devices are reading), Write Exclusive (status code 10, indicating a device has obtained exclusive write rights), and Conflict (status code 11, indicating an unresolved read / write contention or state transition). The Conflict state is a waiting state where arbitration requests are incomplete or a transitional state where protocol interaction is not closed. In other words, during the transition from one stable state to another or the process of multiple devices requesting arbitration, a transitional state that is neither old nor new may occur due to the asynchronous nature of hardware interaction and the distributed coordination requirements of the protocol. This current access state information originates from the controller's Global Coherence State Table (GCST) or a similar central coordination mechanism, maintaining near-consistency with the global state through periodic synchronization or event-based updates (such as state change notifications). The GCST serves as a real-time snapshot center for all consistency domains in the system. It records the current consistency state of each CR, the consistency tag list of accessed devices, and historical state transition trajectories. This data structure is the core data source for conflict analysis, access authorization, and state broadcasting, ensuring the entire system maintains a consistent and orderly state even under instantaneous load changes.

[0040] In other words, when a device initiates an access request, after the permission check is passed, it will first query the local access state cache. If the status in the access state cache indicates that the current operation is not possible (for example, when initiating a write request, it is found that the target CR has been "exclusively written" by another device), the access will be quickly blocked locally, avoiding sending an invalid request to the bus. This caching mechanism greatly reduces the frequency of access to the globally consistent state table, significantly reduces access latency, and through state prediction, enables devices to avoid access conflict peaks, such as proactively postponing access to CRs in conflict states. It also helps to identify and avoid hot CRs, thereby improving the overall system's concurrent access efficiency.

[0041] Specifically, when permission verification passes, the determination of whether an access conflict exists based on the local access state cache and the type of the access request can include the following: If the access state cache determines that the current access state of the target consistency domain is idle, then there is no access conflict; if the access state cache determines that the current access state of the target consistency domain is shared read and the access request type is read request, then there is no access conflict; if the access state cache determines that the current access state of the target consistency domain is shared read and the access request type is write request, then there is a first access conflict; if the access state cache determines that the current access state of the target consistency domain is write exclusive, then there is a second access conflict; and if the access state cache determines that the current access state of the target consistency domain is in a conflict state, then there is a third access conflict. Specifically, when the current access state of the target consistency domain is determined to be idle through the access state cache, there is no access conflict. This can be further explained as follows: when the current access state of the target consistency domain is determined to be idle through the access state cache, and the type of the access request is a write request, it is determined whether there are other write requests initiated by other devices to the target consistency domain at the same time; if there are no other write requests, there is no access conflict; if there are other write requests, there is a fourth access conflict.

[0042] Thus, if no device is accessing the target consistency domain, initiating a read request will not result in any conflict because the read operation does not modify the data and can be executed directly. However, if a write request is initiated, an additional check is required to see if other devices are also initiating write requests to this domain at the same time: if no other devices are writing simultaneously, there will be no conflict; but if other devices are also writing simultaneously, and two devices are modifying the same data at the same time, the result will be incorrect, i.e., the fourth access conflict. If the target consistency domain is already being read by a device, and multiple devices are allowed to read together, then initiating a new read request is safe and can be added to the shared read queue to read with other devices without conflict; however, if the new request is a write request, because the write operation modifies the data, and a device is currently reading old data, once the write is completed, the reading device will receive incorrect data, i.e., the first access conflict. If a target consistency domain is already exclusively occupied by a single device performing a write operation, then any new request, whether read or write, will result in a conflict. This is because the core of write exclusivity is that only the current device can modify the data. Other devices, whether they want to read (which would result in them receiving incomplete, half-finished data) or write (which would compete with the current write operation for permissions), must wait for the current write operation to finish, resulting in a second access conflict. Another scenario is when the target consistency domain is currently in a conflict state (e.g., previous access requests are still in arbitration and conflicts haven't been resolved). In this case, any new request, whether read or write, will generate a third access conflict. This is because the domain itself is still in a chaotic, pending state; adding a new request will only complicate the conflict further, and the new request must wait for the previous conflicts to be resolved before it can be processed. This layered approach not only prevents data corruption caused by multiple devices simultaneously writing, reading, and interleaving writes, ensuring consistent and reliable shared memory data across all devices; it also avoids a blanket ban on all parallel access (for example, allowing new read requests to be executed concurrently during shared reads), thus preventing resource waste and improving access efficiency; and it distinguishes different conflict scenarios (such as multiple devices simultaneously writing to an idle domain, or a domain itself being in conflict), enabling precise handling of subsequent conflicts and reducing coordination costs.

[0043] S104: If an access conflict exists, the controller arbitration engine is triggered, and the access request is executed according to the arbitration result.

[0044] Conflict detection is performed in step 103. When a conflict exists, it is submitted to the controller's arbitration engine for global arbitration, so that the device can execute the access request based on the arbitration result provided by the controller. Alternatively, the controller can also perform conflict detection and arbitration upon detection. Specifically, based on the four types of access conflicts given in step S103, corresponding arbitration strategies are adaptively provided: First Access Conflict (Read-then-Write, write request initiated under shared read state): When a first access conflict occurs, the controller arbitration engine is triggered to determine whether to trigger the access request escalation mechanism. If the escalation mechanism is triggered, read operations on the target consistency domain are stopped, the access request is executed, and the current access state of the consistency domain is updated to write-exclusive state. If the escalation mechanism is not triggered, the arbitration phase is entered to determine the arbitration result, and the access request is executed according to the arbitration result. Specifically, write request escalation means pausing all current read operations, prioritizing the execution of this write request, and changing the state of the domain to write-exclusive state. If the write request is not escalated, the arbitration phase is entered, where rules such as priority and timing are used to determine whether the write request should wait for the read operation to complete or whether the read operation should be paused to make way for the write request, and then the arbitration result is used for execution.

[0045] Second access conflict (Write-then-Access): If a second access conflict exists, the controller arbitration engine is triggered. This engine obtains the first device information of the exclusive target consistency domain, the relevant parameters of the access request, and the second device information in the waiting queue. Based on the first device information, the second device information, and the relevant parameters, it arbitrates the access request according to a first preset rule, outputs the arbitration result, and executes the access request based on the arbitration result. The first device information may include device tag identifier, historical access frequency, and the criticality of the service to which the CR belongs. Relevant parameters may include request type, request timestamp, and device priority. The first preset rule may be: prioritize early-arriving requests; prioritize requests from devices that have not been processed for a long time to prevent some devices from being unable to access the service for extended periods; CRs for real-time control data have higher priority, and the device with the highest priority will be granted write permission, while other devices will receive a rejection message or be placed in a waiting queue for subsequent retries. If the arbitration result allows the access request, the operation of the currently exclusive device is terminated, the region permissions are released, and the permissions are then reassigned to the device. If the arbitration result requires waiting, the access request is added to the waiting queue, and re-arbitration is conducted after the current exclusive operation is completed. If the arbitration result is denial, the device is directly notified of the request failure. This access conflict can also include: Write-after-Write conflict: one device is writing while another device attempts to write; this can also be understood as multiple devices issuing write requests to the same CR almost simultaneously. Write-then-Read conflict: one device is writing while another device attempts to read.

[0046] Third Access Conflict (Conflicting-then-Access): If a third access conflict exists, the controller arbitration engine is triggered to obtain the specific type and associated information of the conflict state. If the target consistency domain is determined to be in a waiting state where arbitration is incomplete based on the specific type and associated information, the access request is added to the current request queue, and all requests in the current request queue are reordered according to the second preset rule to determine the arbitration order. If the target consistency domain is determined to be in a transitional state where protocol interaction is not closed based on the specific type and associated information, the incomplete protocol interaction is monitored. After the interaction is closed, the access request is added to the current request queue, and all requests in the current request queue are reordered according to the second preset rule to determine the arbitration order. The arbitration result is determined according to the arbitration order, and the access request is executed according to the arbitration result. The process involves determining the target consistency domain's status details based on specific types and associated information. This includes identifying whether it's a waiting state where arbitration is incomplete (synchronously acquiring a list of all currently queued access requests, including device identifiers and request types) or a transitional state where protocol interaction is not yet closed (synchronously acquiring the progress of incomplete protocol interactions, such as the number of sent Invalidate messages and the number of pending Ack responses). The second preset rule can be: write requests take precedence over read requests, high-priority device requests take precedence over low-priority devices, and requests of the same priority are sorted by submission time. For example, a closed-loop interaction could be the receipt of all Ack responses, transitioning the target consistency domain from a transitional state to a stable state. The first winning request is determined, and the waiting order of subsequent requests is marked. The controller first releases conflict-related resources for the target consistency domain, such as clearing transitional state identifiers and emptying the invalid request queue. Then, it assigns access permissions for the target consistency domain to the device corresponding to the winning request, executes the access request, and simultaneously notifies other waiting requests to enter the next round of arbitration. For example, the third type of access conflict could be a Stale Write conflict: the device's permissions have been revoked but the cache has not been cleared, resulting in the writing of old data.

[0047] Fourth access conflict (Idle-then-Writes): If a fourth access conflict exists, the controller arbitration engine is triggered to obtain information about other devices and their devices. Based on this information and priority policies, other write and access requests are sorted to determine access priorities. Access requests are then executed according to these priorities. To balance fairness and efficiency, a dynamic device priority queue (PriorityQueue) can be used to sort conflicting requests. Sorting criteria include: the current write level of the accessing device (e.g., system kernel priority over user processes); the request timestamp (early requests are processed first); historical access frequency (to prevent certain devices from being inaccessible for extended periods); and the criticality of the service to which the CR belongs (e.g., CRs handling real-time control data have higher priority). The device with the highest priority is granted write permission, while other devices receive a rejection message or are placed in a waiting queue for later retries. Specifically, a fourth access conflict can include a Write-after-Write conflict: although the target CR is idle, multiple devices initiate write requests to the same CR almost simultaneously.

[0048] S105: If there is no access conflict, execute the access request.

[0049] Specifically, if no access conflict exists, the type of the access request is determined. If the access request is a read request, the access request is executed, and the current access state of the target consistency domain is updated to a shared read state. If the access request is a write request, the access request is executed, and the current access state of the target consistency domain is updated to a write exclusive state. In this way, while executing the access request, the current access state of the corresponding target consistency domain is updated, and the relevant data in the global consistency state table and consistency label list is also updated.

[0050] Furthermore, when the type of the above access request is a write request, the access request is executed. Specifically, this may include: if the type of the access request is a write request, storing the access request in the local write buffer, and based on the timing information and write address of the local write buffer, batching the data to be written and writing it back to the target consistency domain in the shared memory.

[0051] To optimize write operations and further reduce conflicts, an asynchronous write scheduler (WBScheduler) is integrated on the device side. This asynchronous write scheduler manages the device's local write buffer, asynchronously processing, merging, and controlling write requests to shared memory. Its core function is to determine when and how to initiate write operations to minimize conflicts with write operations from other devices. Internally, the asynchronous write scheduler may include a regular write buffer (for temporarily storing pending write requests), a bypass buffer (for temporarily holding write requests that require special handling due to failed conflict avoidance), and a write-back control unit (responsible for executing writes at appropriate times according to the scheduling policy). Its working strategy includes: merging multiple small write operations targeting the same or adjacent CR regions into larger batch write-back tasks to improve bus utilization and efficiency; initiating actual write operations only when the target CR is in a state suitable for writing; delaying the write and employing retry mechanisms (such as exponential backoff algorithms or priority-based scheduling switching) if the target CR is detected to be in a conflict state or unsuitable for writing; and sending write completion notifications to the local access state cache and possible global state management mechanisms (such as the Fabric Controller or GCST) to update the relevant states after a write operation is successfully completed. In this way, the WB Scheduler significantly reduces the instantaneous conflict rate caused by concurrent writes, achieves efficient control of write traffic (write flow control), reduces the time window for locking CRs during write operations, and makes write operations more like planned execution events, thereby improving the predictability and controllability of the entire system behavior.

[0052] The access method provided in this embodiment of the invention proceeds as follows: S101: Load the consistency tag list corresponding to the authorized access consistency domain. S102: When an access request is initiated to the target consistency domain in shared memory, the access request is verified using the consistency tag list and the target consistency domain. S103: If the permission verification passes, determine whether an access conflict exists using the local access state cache and the type of the access request. S104: If an access conflict exists, trigger the controller arbitration engine and execute the access request according to the arbitration result. S105: If no access conflict exists, execute the access request. This method establishes a consistent label list for each device and loads it locally, enabling access control within the device and achieving fine-grained, consistent, regionalized access isolation. Furthermore, the device's local access state cache enables access conflict detection within the device, providing rapid local response and unified reporting to the controller. By constraining the legality and consistency of access from the device side, it effectively reduces the propagation scope of access conflicts and decreases reliance on constant central coordination. This method solves the consistency problem existing in current systems when multiple devices access shared memory, achieving efficient, low-conflict, and flexible consistency assurance in scenarios with concurrent access to shared memory by multiple devices.

[0053] For a clearer understanding of this invention, please refer to the following details. Figure 2 For details, please refer to Figure 2 , Figure 2 This invention provides a CXL architecture diagram. Specifically, it may include shared memory, a CXL controller, and multiple devices. The CXL controller, as the core coordination unit for system consistency maintenance, embodies a high degree of functional division and modular expansion capabilities in its structural design. It not only undertakes real-time monitoring and arbitration of shared memory consistency but also integrates close interaction with the operating system and device-side modules, serving as a key support for ensuring high performance and high reliability of cross-device shared access. The controller (CXLController) maintains the real-time status of each consistency region in the system through the Global Consistency State Table (GCST), supporting comprehensive judgment of arbitration requests based on multiple factors such as access timing, device priority, and business sensitivity, achieving unified management of consistent access. Its internal structure mainly consists of the following seven functional modules, which can be referred to in detail. Figure 3 , Figure 3 An example diagram of a CXL controller provided for an embodiment of the present invention: (1) Consistency Domain Management Unit: Responsible for managing all consistent regions in the entire system. It provides the ability to partition, merge, migrate and release CRs, and can assign a unique tag ID to each CR, thereby supporting the controllability and traceability of cross-device shared access. In addition, it also supports the dynamic expansion and hot-swappable device CR access through the interface with the operating system, improving the system's scalability and flexibility. (2) Global Consistency State Table: It is the "real-time snapshot center" of all consistent regions in the system. The GCST records the current consistency state of each CR (such as Idle, Shared, Exclusive, Conflict, etc.), the list of accessed devices, and the historical state change trajectory. This data structure is the core data source for conflict analysis, access authorization, and status broadcasting, ensuring that the entire system maintains a consistent and orderly state under instantaneous load changes. (3) Controller Arbitration Engine: It is the brain that implements consistency policy scheduling. This module listens for conflict requests reported by all devices in real time. For example: Write-after-Write, Write-then-Read or old cache write conflicts. Once a conflict is identified, the arbitration engine will make an arbitration decision based on priority strategies (e.g., first-come-first-served timestamps, device level, access history, CR importance, etc.) and coordinate subsequent write rollback, permission reassignment and other processes. (4) Tag Access Authority: Responsible for distributing and maintaining CR access permissions to each device. Generates and issues corresponding Tag IDs to each device, and also supports dynamic tag migration. When permission changes, hot migrations or conflict recovery occur, this module can quickly notify the device to update its local CR-Tag Unit, thereby preventing unauthorized access. (5) Access Synchronizer: Undertakes the task of synchronizing data consistency between device access behavior and global state. This module summarizes the state information from the device's internal Access State Cache, Edge Coherence Detection Module (ECD), and WB Scheduler, buffers, filters and finally submits it to GCST to achieve data state consistency between hardware and software. (6) Broadcast & Notification Bus: This is the core path for the propagation of consistent events across the entire system. When the arbitration engine completes a state switch or permission change, this module can broadcast state change information to all relevant devices, including write permission release notifications, tag expiration instructions, cache refresh requests, etc.Its communication mechanism supports both interrupt-triggered and polling-based modes, and has QoS (Quality of Service) support capabilities to ensure that high-priority consistency operations are scheduled first. (7) System Software Interface Layer: Provides access points for the consistency mechanism to the operating system, drivers and virtualization layer. It not only provides system call interfaces such as CR creation, status query and permission change, but also supports consistency isolation in multi-tenant environments (such as SR-IOV), and supports advanced features such as hot-plugging of devices and dynamic migration of virtual machines, providing strong support for upper-layer system integration.

[0054] Each device intending to access the shared memory space managed by this system is equipped with a set of cooperating modules that locally enforce consistency and manage access, thereby reducing reliance on constant central coordination. Figure 2It can be seen that the device specifically includes the following four parts: (1) Consistency Tag Unit (CR-Tag Unit): It constitutes the first line of defense for access control and focuses on managing the basic access permissions between the device and specific consistency domains (CR). Its core responsibility is to maintain a tag-based permission system. (2) Access State Cache: A local snapshot of the current state of the CR. After the permission verification is passed, the processing of the access request enters the second stage, which involves judging the current real-time state of the target CR. The Access State Cache is located locally on the device and stores the current access state information of several consistency domains that it cares about. (3) Edge Consistency Detection Module: Deployed locally on each device, it is used to monitor whether the access behavior of the device is unauthorized in real time. It has the function of fast local response and unified reporting to the controller. It constrains the legality of access from the device end and effectively reduces the propagation range of access conflicts. This module is physically or logically located at the key node of the device access request sending path. It is responsible for intercepting all access requests sent to shared memory and judging whether there are edge conflicts at a very fine time granularity (which can reach the sub-clock cycle level). Edge collisions specifically refer to the risk of data inconsistency when a target CR's state is transitioning or multiple device requests arrive almost simultaneously at a critical moment. This can occur when a write operation reads an old value, or two write operations overwrite each other. The ECD module receives detailed information about the access request, including the target CR address, operation type (read / write), and permission tags carried in the request. It interacts with the local access state cache in real time to obtain the latest known state of the target CR and performs precise boundary-based collision assessment based on the request type. For example, if a device initiates a write request, and the ECD finds through cache queries that the target CR is in a shared read state, the ECD will proactively block the write and report it to the controller for arbitration to prevent data inconsistency in the shared read state. In cases of concurrent write request collisions, the controller's arbitration engine handles the situation. To mitigate collisions, the ECD can implement a rollback mechanism, requiring the initiator to withdraw the request or placing it in a delay queue. Each time a collision is detected, the ECD records detailed logs and feeds back the collision information to the write scheduler or other relevant units for further processing. The ECD module is the core of achieving high-precision conflict identification and fast response, effectively reducing the risk of write overwriting and reading dirty data. Through linkage with the asynchronous write scheduler, it supports the implementation of a hybrid consistency control model that combines soft interception (early warning by ECD) and hard scheduling (execution decision by the asynchronous write scheduler). (4) Asynchronous write scheduler (WB Scheduler): the intelligent commander of write operations.It supports suspending write requests and uses a scheduling queue and rollback mechanism, along with the controller arbitration engine, to make write permission judgments, thereby improving data security and throughput in write conflict scenarios.

[0055] When a device in the system initiates an access request (which may be for reading or writing) to a consistent region (CR) in shared memory, the request will undergo a series of multi-dimensional and hierarchical review and processing procedures to ensure that the system maintains strict consistency even in a high-concurrency environment. Figure 4 This is a flowchart illustrating an access method provided by an embodiment of the present invention. Specifically, it may include: First, the access request enters the consistency tag unit, where preliminary access permission verification is performed. Each device can only access its authorized CRs. The system determines whether it has legitimate access rights based on its held Tag ID to prevent unauthorized or illegal access. Subsequently, the access request obtains a snapshot of the current access state of the target CR through the access state cache, including whether the area is in a shared, exclusive, or conflict state, and queries the device's access history to provide contextual information for subsequent judgment. Next, it enters the edge consistency detection module for dynamic conflict detection. This module precisely monitors potential consistency threats at the memory access edge, such as typical scenarios like read-after-write, expired writes, and concurrent dual writes. Once a conflict risk is detected, the system immediately interrupts the request and triggers the controller's arbitration or rescheduling process. If no conflict is found and the access permission is legitimate, the system adopts different strategies based on the access type: for read requests, the controller directly allows access and updates the state; for write requests, the request enters the asynchronous write scheduler. The asynchronous write scheduler combines parameters such as permission status, conflict judgment result, and device priority to decide whether to execute the write immediately or delay its scheduling. Ultimately, regardless of whether the access is successful or a conflict is resolved, the CXL controller will synchronously update the globally consistent state table to ensure that other devices in the system can detect the state change. Simultaneously, if a suspended request exists, the controller will also wake up the waiting queue and resume processing when conditions permit.

[0056] As can be seen, an access request first needs to pass the permission review of the CR-Tag Unit; then, the access state cache provides a real-time state context; next, the ECD module performs precise conflict detection and immediate response at the access edge; finally, for write operations, the WB Scheduler performs intelligent asynchronous scheduling and execution based on permissions, state, and conflict detection results. This multi-layered, multi-dimensional control mechanism, compared to traditional methods, can more effectively prevent illegal access, predict and avoid state conflicts, accurately handle edge contention, and optimize write performance, thereby significantly improving the overall performance, stability, and flexibility of the shared memory system while ensuring strong consistency. This invention is applicable to various scenarios requiring high-concurrency, low-latency shared memory access, such as high-performance computing, data centers, and embedded multi-core systems.

[0057] To better understand this solution, consider the following example: Assume there are two devices, Device A and Device B, located on different CXL ports. The system has defined a consistency zone CR2, which has been authorized for write operations by Device A. At this time, Device B initiates a read request to CR2, while Device A has not yet completed its write operation (it is in the write-back cache phase). Meanwhile, Device C originally had access to CR2, but its Tag ID has been revoked by the system. However, this device has not yet refreshed its local cache and attempts to perform an expired write operation to CR2. The processing flow is as follows: Step 1: Access State Cache Records Write Requests: When Device A performs a write operation to CR2, its write request is first placed in the local write buffer, and simultaneously reported to GCST and the local Access State Cache. The Access State Cache records the device's access state to CR in real time, including: the current access mode (read / write), the status commit timestamp, whether the actual write has been completed, and the controller updating the status of CR2 to Exclusive-Write[A] in GCST.

[0058] Step 2: Device B initiates a read request, which is detected as a conflict: Device B attempts to read CR2 data. Device B updates its local Access State Cache via GCST and finds that the write to CR2 is not yet complete. The Edge Consistency Detection (ECD) module is activated, confirming the existence of Write-then-Read consistency risk. The controller suspends Device B's read operation and suspends it in the CR2 read wait queue. At the same time, a "write completion acceleration" prompt is sent to Device A, triggering Device A's asynchronous write scheduling process.

[0059] Step 3: The asynchronous write scheduler accelerates the completion of writes for Device A: The asynchronous write scheduler receives scheduling instructions from the controller, increases the write priority of Device A, and prompts it to write data from the local write buffer to the shared memory area as quickly as possible. The asynchronous write scheduler also supports the following mechanisms: prefetching write path resources (such as memory controller channels) to avoid competition with low-priority tasks; and reserving bandwidth for critical consistency writes if QoS is enabled in the system.

[0060] Step 4: Device A reports completion, and state synchronization resumes read operation: After writing is completed, Device A reports a "write complete" event through the controller interface. The controller updates: the CR2 state in GCST changes to Shared-Read, the Access StateCache clears the write mark of A, the controller wakes up Device B, grants read permission, and allows it to read data.

[0061] Step 5: Device C's Stale Write is Intercepted: Simultaneously, Device C attempts to write old data to CR2. Device C's CR-Tag Unit detects that the device is using a revoked Tag ID (no longer possessing CR2 permissions); the ECD module reports the illegal write behavior; the controller further verifies the device's local Access State Cache and GCST, confirming it as invalid access. The controller performs the following security response measures: intercepts the write request, logs the access, and issues a "Flush+ResetTag" command to Device C to clear its local cache; if it is a repeatedly violating device, the controller can permanently revoke its tag through the software interface layer.

[0062] The following are examples illustrating the conflict resolution process: Example 1: Write-after-Write conflict handling. For example, in the system, device A and device B almost simultaneously initiate write requests to the consistency region CR1. After receiving the write command, the CXL controller performs the following operations in sequence: (1) Status confirmation: Check the current status of CR1 in GCST to determine whether there is a write permission holder. (2) Trigger arbitration: If CR1 is currently in the "Shared" or "Idle" state, the controller starts the arbitration process. The scheduling arbitration engine sorts the two devices A and B according to the set priority strategy (such as timestamp priority, task urgency, etc.). (3) Authorization processing: Authorize the device with the highest priority (assuming device A) as the current write holder of CR1; update the status of CR1 in GCST to Exclusive-Write[A]; send an authorization message and corresponding tag information to device A; at the same time, suspend the request of device B, return the status code CR_WRITE_CONFLICT, and attach information suggesting polling or delaying retry. (4) Write-after release: After device A completes the write operation, it reports "write complete" to the controller. The controller releases the write permission of CR1, restores the state to Idle or Shared, and wakes up the suspended device. This process achieves accurate identification and safe separation of concurrent write conflicts, effectively avoiding write failures caused by data competition.

[0063] Example 2: Write-then-Read conflict handling. For example, when device A is writing to CR2, device B initiates a read operation on CR2. (1) Conflict identification: Device B is found to be requesting access to CR2, which is being exclusively written to by device A, triggering conflict judgment. (2) Status confirmation: GCST shows that the current status of CR2 is Exclusive-Write[A]. (3) Access suspension: The controller suspends the read request of device B; registers it in the "read wait queue" of CR2. (4) Resumption after write completion: Device A reports the status after writing is completed; the controller updates GCST, changes the CR2 status to Shared-Read; wakes up device B in the wait queue, and grants read permission and corresponding Tag ID. This scheme ensures the atomicity of writing while guaranteeing the latest read data, preventing the reading of half-written data or dirty data.

[0064] Example 3: Stale Write Conflict Handling. For example, after its access permissions are revoked, device C initiates a write operation to CR3 without refreshing its local write cache. (1) Anomaly Detection: The controller captures the abnormal write event through the Edge Consistency Detection (ECD) module; verification shows that device C currently does not have a valid Tag ID to access CR3. (2) Permission Verification: Checking the CR-Tag Unit and GCST confirms that device C's permissions have been revoked; this behavior is judged as "Stale Write". (3) Conflict Handling Mechanism: If the system supports write rollback (such as Copy-on-Write), the controller rolls back the data written this time to the historical version; otherwise, an error report is triggered, notifying the system software to intervene. (4) Status Refresh: The controller issues Cache Flush and Tag Reset commands to device C; forcibly clears the local cache and blocks subsequent illegal access. (5) Behavior Recording: This event is recorded in the access log; as a reference for subsequent system scheduling optimization and device health management. This process effectively curbs data consistency corruption caused by unsynchronized cache.

[0065] Example 4: Handling of unauthorized access. For example, device D initiates read / write access to the unauthorized consistency region CR4. (1) Conflict detection: The ECD detects that the request to access CR4 comes from device D, which does not hold a valid tag; it determines that the access is an unauthorized act and generates a security event report. (2) Permission isolation: The controller suspends the interaction between device D and CR4; if the behavior is repeated or serious, the controller can disable all CR tag permissions of the device. (3) System synchronization: The controller sends a synchronization notice to other devices through the broadcast module to refresh the status; to avoid the chain reaction caused by the unauthorized behavior. (4) Security handling: The system software interface is called to trigger further measures, such as device isolation, dynamic hot-swapping, etc.; if it is a misoperation, its permissions can be restored through the administrator command; if it is confirmed to be malicious, all its tags are revoked and the access interface is locked. Through the above process, the system achieves security protection of access behavior while ensuring performance.

[0066] The access device provided in the embodiments of the present invention will be described below. The access device described below can be referred to in correspondence with the access method described above.

[0067] Please refer to the details. Figure 5 , Figure 5 A schematic diagram of an access device provided in an embodiment of the present invention may include: The loading module 100 is used to load a list of consistency tags corresponding to the authorized access consistency domain; the list of consistency tags includes the device's read permission, write permission, or read-write permission for the authorized access consistency domain; The permission verification module 200 is used to verify the permission of the access request by means of the consistency tag list and the target consistency domain when an access request is initiated to the target consistency domain in the shared memory. The conflict detection module 300 is used to determine whether there is an access conflict when the permission verification is successful by using the local access state cache and the type of the access request; the access state cache stores the current access state information of the authorized access consistency domain; The first request execution module 400 is used to trigger the controller arbitration engine if an access conflict exists, and execute the access request according to the arbitration result; The second request execution module 500 is used to execute the access request if there is no access conflict.

[0068] Based on the above embodiments, the loading module 100 may include: The loading unit is used to load the consistency tag list when the controller completes the consistency domain partitioning, tag identifier allocation, and access permission determination steps; the consistency tag list is composed of tag identifiers corresponding to the authorized access consistency domains; wherein, the controller completing the consistency domain partitioning, tag identifier allocation, and access permission determination steps includes: the controller partitioning the shared memory into consistency domains, assigning corresponding tag identifiers to each partitioned consistency domain, and determining the tag identifiers corresponding to the authorized access consistency domains based on the access permissions of the device.

[0069] Based on the above embodiments, the permission verification module 200 may include: The query unit is used to query the consistency tag list when an access request is initiated to the target consistency domain in the shared memory; The first verification result unit is used to verify the permission if the target consistency domain exists in the consistency label list and has a valid label identifier of the corresponding operation type. The second verification result unit is used to reject the access request otherwise and trigger an exception report.

[0070] Based on the above embodiments, the collision detection module 300 may include: The first conflict detection result unit is used to determine that there is no access conflict when the current access state of the target consistency domain is determined to be idle through the access state cache. The second conflict detection result unit is used to determine that there is no access conflict when the current access state of the target consistency domain is a shared read state and the type of the access request is a read request type, based on the access state cache. The third conflict detection result unit is used to determine that the current access state of the target consistency domain is a shared read state and the type of the access request is a write request when the access state cache determines that a first access conflict exists. The fourth conflict detection result unit is used to determine that a second access conflict exists when the current access state of the target consistency domain is determined to be a write exclusive state through the access state cache. The fifth conflict detection result unit is used to determine that a third access conflict exists when the current access state of the target consistency domain is in a conflict state as determined by the access state cache; the conflict state is either a waiting state where the arbitration request has not been completed or a transitional state where the protocol interaction has not been closed.

[0071] Based on the above embodiments, the first request execution module 400 may include: The first judgment unit is used to trigger the controller arbitration engine when the first access conflict exists, so that the controller arbitration engine determines whether to trigger the access request escalation mechanism. The first judgment result unit is used to stop the read operation of the target consistency domain, execute the access request, and update the current access state of the consistency domain to write exclusive state if the upgrade mechanism of the access request is triggered. The second determination result unit is used to enter the arbitration stage to determine the arbitration result if the escalation mechanism of the access request is not triggered, and to execute the access request according to the arbitration result.

[0072] Based on the above embodiments, the first request execution module 400 may include: The first arbitration unit is configured to, if the second access conflict exists, trigger the controller arbitration engine so that the controller arbitration engine obtains the first device information that exclusively occupies the target consistency domain, the relevant parameters of the access request, and the second device information in the waiting queue, and arbitrates the access request according to the first device information, the second device information, and the relevant parameters, according to the first preset rule, outputs the arbitration result, and executes the access request according to the arbitration result.

[0073] Based on the above embodiments, the first request execution module 400 may include: The acquisition unit is used to trigger the controller arbitration engine if the third access conflict exists, so that the controller arbitration engine can acquire the specific type and associated information of the state in the conflict. The first arbitration result unit is used to add the access request to the current request queue if the target consistency domain is determined to be in a waiting state where the arbitration request is not completed based on the specific type and associated information, and to reorder all requests in the current request queue according to the second preset rule to determine the arbitration order. The second arbitration result unit is used to monitor the incomplete protocol interaction if the target consistency domain is determined to be a transitional state where the protocol interaction is not closed according to the specific type and associated information. After the interaction is closed, the access request is added to the current request queue, and all requests in the current request queue are reordered according to the second preset rule to determine the arbitration order. An arbitration enforcement unit is configured to determine the arbitration result according to the arbitration order and execute the access request according to the arbitration result.

[0074] Based on the above embodiments, the first conflict detection result unit may include: The first judgment subunit is used to determine whether there are other write requests initiated by other devices to the target consistency domain at the same time when the current access state of the target consistency domain is determined to be idle state through the access state cache and the type of the access request is a write request. The first judgment result subunit is used to determine that if there are no other write requests, then there is no access conflict. The second judgment result subunit is used to determine if a fourth access conflict exists if other write requests exist.

[0075] Based on the above embodiments, the first request execution module 400 may include: The execution priority determination unit is used to trigger the controller arbitration engine if the fourth access conflict exists, so that the controller arbitration engine can obtain the other devices and the device information of the devices; sort the other write requests and the access requests according to the device information and the priority policy to determine the access priority; and execute the access request according to the access priority.

[0076] Based on the above embodiments, the second request execution module 500 may include: A type determination unit is used to determine the type of the access request if there is no access conflict. The first execution unit is configured to execute the access request if the type of the access request is a read request type, and at the same time update the current access state of the target consistency domain to a shared read state. The second execution unit is configured to execute the access request if the type of the access request is a write request, and simultaneously update the current access state of the target consistency domain to a write exclusive state.

[0077] Based on the above embodiments, the second execution unit may include: The write subunit is used to store the access request into a local write buffer when the type of the access request is a write request type, and to batch merge the data to be written back to the target consistency domain in the shared memory based on the timing information and write address of the local write buffer.

[0078] Based on the above embodiments, the access device may further include: The tag list adjustment module is used to dynamically adjust the consistency tag list in response to device hot-plugging, permission change or task migration events during system runtime after loading the consistency tag list corresponding to the authorized access consistency domain.

[0079] It should be noted that the order of the modules and units in the aforementioned access device can be changed without affecting the logic.

[0080] The access device provided in this embodiment of the invention includes a loading module 100 for loading a consistency tag list corresponding to an authorized access consistency domain; the consistency tag list includes the device's read permission, write permission, or read-write permission for the authorized access consistency domain; a permission verification module 200 for verifying the access request's permissions using the consistency tag list and the target consistency domain when an access request is initiated to the target consistency domain in shared memory; a conflict detection module 300 for determining whether an access conflict exists using a local access state cache and the type of the access request when the permission verification passes; the access state cache stores the current access state information of the authorized access consistency domain; a first request execution module 400 for triggering the controller arbitration engine and executing the access request according to the arbitration result if an access conflict exists; and a second request execution module 500 for executing the access request if no access conflict exists. This device establishes a consistent label list for each device and loads it locally, enabling access control within the device and achieving fine-grained, consistent, regionalized access isolation. Furthermore, the device's local access state cache enables access conflict detection within the device, providing rapid local response and unified reporting to the controller. By constraining the legality and consistency of access from the device end, it effectively reduces the propagation scope of access conflicts and decreases reliance on constant central coordination. It solves the consistency problem existing in current systems when multiple devices access shared memory, achieving efficient, low-conflict, and flexible consistency assurance in scenarios with concurrent access to shared memory by multiple devices.

[0081] Figure 6 This is a schematic diagram of the structure of an access device provided in an embodiment of the present invention, such as... Figure 6 As shown, the access device may include: a memory 60 for storing a computer program; and a processor 61 for executing the computer program to implement the steps of the access method as described in the above embodiment. The access device provided in this embodiment may include, but is not limited to, smartphones, tablets, laptops, or desktop computers.

[0082] The processor 61 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 61 may be implemented using at least one hardware form selected from Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The processor 61 may also include a main processor and a coprocessor. The main processor, also known as the Central Processing Unit (CPU), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 61 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 61 may also include an Artificial Intelligence (AI) processor, which handles computational operations related to machine learning.

[0083] The memory 60 may include one or more computer-readable storage media, which may be non-transitory. The memory 60 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 60 is used to store at least the following computer program 601, which, after being loaded and executed by the processor 61, is capable of implementing the relevant steps of the access method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 60 may also include an operating system 602 and data 603, and the storage method may be temporary or permanent storage. The operating system 602 may include Windows, Unix, Linux, etc. The data 603 may include, but is not limited to, data related to the access method.

[0084] In some embodiments, the access device may further include a display screen 62, an input / output interface 63, a communication interface 64, a power supply 65, and a communication bus 66.

[0085] Those skilled in the art will understand that Figure 6 The structure shown does not constitute a limitation on the access device and may include more or fewer components than illustrated.

[0086] It is understood that if the access methods in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the current technology, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods in the various embodiments of the present invention. The aforementioned storage medium includes: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs, magnetic disks, or optical disks, and other media capable of storing program code.

[0087] Based on this, embodiments of the present invention also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the access method described above.

[0088] The following describes a computer program product provided by an embodiment of this application. The computer program product described below can be referred to in conjunction with other embodiments described herein.

[0089] A computer program product includes a computer program / instructions that, when executed by a processor, implement the steps of the aforementioned disclosed access method.

[0090] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0091] Those skilled in the art will further 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, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. 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 implementations should not be considered beyond the scope of this invention.

[0092] Finally, it should be noted that in this document, relationships such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0093] The foregoing has provided a detailed description of an access method, apparatus, device, and computer-readable storage medium provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. An access method, characterized in that, Devices used in connection with a controller include: Load the consistency tag list corresponding to the authorized access consistency domain; the consistency tag list includes the device's read permission, write permission, or read-write permission for the authorized access consistency domain; When an access request is initiated to the target consistency domain in shared memory, the access request is verified using the consistency tag list and the target consistency domain. When the permission verification is successful, the local access state cache and the type of the access request are used to determine whether there is an access conflict; the access state cache stores the current access state information of the authorized access consistency domain. If an access conflict exists, the controller arbitration engine is triggered, and the access request is executed according to the arbitration result; If there is no access conflict, the access request is executed.

2. The access method according to claim 1, characterized in that, Load the list of consistency tags corresponding to the authorized access consistency domains, including: When the controller completes the steps of consistency domain partitioning, tag identifier allocation, and access permission determination, it loads the consistency tag list; the consistency tag list is composed of the tag identifiers corresponding to the authorized access consistency domains. The controller completes the steps of consistency domain partitioning, label assignment, and access permission determination, including: The controller divides the shared memory into consistency domains, assigns corresponding labels to each consistency domain, and determines the label corresponding to the authorized access consistency domain based on the device's access permissions.

3. The access method according to claim 1, characterized in that, When an access request is initiated to a target consistency domain in shared memory, the access request is validated using the consistency tag list and the target consistency domain, including: When the access request is initiated to the target consistency domain in the shared memory, the consistency tag list is queried; If the target consistency domain exists in the consistency label list and has a valid label identifier of the corresponding operation type, then the permission verification is successful. Otherwise, the access request is rejected and an exception is reported.

4. The access method according to any one of claims 1 to 3, characterized in that, When permission verification passes, the system determines whether an access conflict exists based on the local access state cache and the type of the access request, including: When the current access state of the target consistency domain is determined to be idle through the access state cache, there is no access conflict. When the current access state of the target consistency domain is determined to be a shared read state through the access state cache, and the type of the access request is a read request type, then there is no access conflict. When the current access state of the target consistency domain is determined to be a shared read state through the access state cache, and the type of the access request is a write request type, then a first access conflict exists. When the current access state of the target consistency domain is determined to be write exclusive through the access state cache, a second access conflict exists. When the current access state of the target consistency domain is determined to be in a conflict state through the access state cache, a third access conflict exists; the conflict state is either a waiting state where the arbitration request has not been completed or a transitional state where the protocol interaction has not been closed.

5. The access method according to claim 4, characterized in that, If an access conflict exists, the controller arbitration engine is triggered, and the access request is executed according to the arbitration result, including: If the first access conflict exists, the controller arbitration engine is triggered so that the controller arbitration engine can determine whether to trigger the access request escalation mechanism; If the upgrade mechanism of the access request is triggered, the read operation of the target consistency domain is stopped, the access request is executed, and the current access state of the consistency domain is updated to write exclusive state. If the escalation mechanism of the access request is not triggered, the process proceeds to the arbitration stage to determine the arbitration result, and the access request is executed according to the arbitration result.

6. The access method according to claim 4, characterized in that, If an access conflict exists, the controller arbitration engine is triggered, and the access request is executed according to the arbitration result, including: If the second access conflict exists, the controller arbitration engine is triggered so that the controller arbitration engine obtains the first device information that exclusively occupies the target consistency domain, the relevant parameters of the access request, and the second device information in the waiting queue. Based on the first device information, the second device information, and the relevant parameters, the access request is arbitrated according to the first preset rule, the arbitration result is output, and the access request is executed according to the arbitration result.

7. The access method according to claim 4, characterized in that, If an access conflict exists, the controller arbitration engine is triggered, and the access request is executed according to the arbitration result, including: If the third access conflict exists, the controller arbitration engine is triggered so that the controller arbitration engine can obtain the specific type and associated information of the state in the conflict; If, based on the specific type and associated information, the target consistency domain is determined to be in a waiting state where the arbitration request is incomplete, then the access request is added to the current request queue, and all requests in the current request queue are reordered according to the second preset rule to determine the arbitration order. If the target consistency domain is determined to be a transitional state where the protocol interaction is not closed based on the specific type and associated information, then the incomplete protocol interaction is monitored. After the interaction is closed, the access request is added to the current request queue, and all requests in the current request queue are reordered according to the second preset rule to determine the arbitration order. The arbitration result is determined according to the arbitration order, and the access request is executed according to the arbitration result.

8. The access method according to claim 4, characterized in that, When the current access state of the target consistency domain is determined to be idle through the access state cache, there is no access conflict, including: When the current access state of the target consistency domain is determined to be idle through the access state cache, and the type of the access request is a write request, it is determined whether there are other write requests initiated by other devices to the target consistency domain at the same time. If no other write requests are made, then there is no access conflict; If any other write request exists, then a fourth access conflict exists.

9. The access method according to claim 8, characterized in that, If an access conflict exists, the controller arbitration engine is triggered, and the access request is executed according to the arbitration result, including: If the fourth access conflict exists, the controller arbitration engine is triggered to obtain the other devices and their device information; the other write requests and the access requests are sorted according to the device information and priority policy to determine the access priority; and the access requests are executed according to the access priority.

10. The access method according to claim 1, characterized in that, If no access conflict exists, the access request is executed, including: If no access conflict exists, determine the type of the access request; If the access request is of type read request, then the access request is executed, and the current access state of the target consistency domain is updated to shared read state. If the access request is a write request, then the access request is executed, and the current access state of the target consistency domain is updated to write exclusive state.

11. The access method according to claim 10, characterized in that, If the access request is of type write request, then the access request is executed, including: If the access request is a write request, the access request is stored in a local write buffer. Based on the timing information and write address of the local write buffer, the data to be written is batched and written back to the target consistency domain in the shared memory.

12. The access method according to claim 1, characterized in that, After loading the list of consistency tags corresponding to the authorized access consistency domains, it also includes: During system operation, the consistency tag list is dynamically adjusted in response to device hot-plugging, permission changes, or task migration events.

13. An access device, characterized in that, Devices used in connection with a controller include: The loading module is used to load a list of consistency tags corresponding to the authorized access consistency domain; the list of consistency tags includes the device's read permission, write permission, or read-write permission for the authorized access consistency domain; The permission verification module is used to verify the permission of the access request by using the consistency tag list and the target consistency domain when an access request is initiated to the target consistency domain in shared memory. The conflict detection module is used to determine whether there is an access conflict when the permission verification is successful by using the local access state cache and the type of the access request; the access state cache stores the current access state information of the authorized access consistency domain; The first request execution module is used to trigger the controller arbitration engine if an access conflict exists, and execute the access request according to the arbitration result; The second request execution module is used to execute the access request if there is no access conflict.

14. An access device, characterized in that, include: Memory, used to store computer programs; A processor for implementing the access method as described in any one of claims 1 to 12 when executing the computer program.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when loaded and executed by a processor, implement the access method as described in any one of claims 1 to 12.

Images