A method, device, electronic device and storage medium for processing consistent transactions
By comparing the new entrant transaction with the previous entrant transaction when a conflict occurs, and adjusting the sleep-wake mechanism, the problem of low cache consistency conflict processing efficiency in a multi-core processor environment is solved, and the effect of reducing waiting time and improving processing efficiency is achieved.
Patent Information
- Application Number
- CN202410742955.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-06-07
- Publication Date
- 2025-04-29
- Estimated Expiration
- 2044-06-07
AI Technical Summary
When handling cache consistency in the multi-core processor environment, the conflict processing mechanism causes subsequent transactions to be delayed due to waiting, and the overall processing efficiency is affected.
When a conflict occurs, the newly enqueued transaction is compared with the previous enqueued transaction. If the new enqueued transaction and the previous enqueued transaction are both read-only transactions, the enqueued state of the new enqueued transaction is used to mark the enqueued state of the new enqueued transaction, and the transaction index value of the newly enqueued transaction is recorded in the previous enqueued transaction.
On the premise of ensuring consistency, the waiting time between transactions is reduced, the turnover speed of transaction processing is accelerated, thereby improving the overall processing capability and response efficiency of the system.
Smart Images

Figure CN118535290B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of semiconductor technology, and in particular to a consistency transaction processing method, a consistency transaction processing device, an electronic device and a storage medium. Background Art
[0002] With the development of semiconductor technology, the number of components such as processor cores, memory controllers, accelerators, and peripherals integrated in System-on-Chip (SoC) has increased dramatically. The traditional bus architecture can hardly meet the requirements of high performance, low latency, and high bandwidth. Network-on-Chip (NoC) came into being in this context to solve the problem of efficient communication between numerous Internet Protocol (IP) modules in modern complex systems. NoC draws on the design concept of computer networks and designs the communication mechanism inside the chip as a micro network.
[0003] The Coherent Hub Interface (CHI) protocol is an on-chip interconnect technology designed for high-performance multi-core systems. It optimizes data consistency management through packet transmission mode, ensures data synchronization in multi-processor environments, and supports complex system architectures and flexible topology designs. The layered and modular design of the CHI protocol allows NoC to be configured according to demand, compatible with components such as multi-level caches, multi-processor cores and accelerators, and adapts to a wide range of application scenarios. Support for multiple network topologies enhances the scalability and adaptability of the system, balancing performance, latency and energy consumption.
[0004] Point of Coherence (PoC) means that at a certain moment, all components that can access memory will see the same copy of a memory location. In a typical CHI protocol-based system, this consistency point is usually a fully coherent home node (HNF) in the interconnect structure. In other words, no matter which part of the system requests access to memory, the information they receive is consistent and up-to-date, which is an important basis for maintaining data consistency and correctness in multi-core processors and highly parallel computing environments.
[0005] As a key module in the CHI protocol, HNF plays a core role in maintaining cache consistency and ensuring the consistency of data access by all components in the system. In order to improve the response speed and efficiency of the cache system, the Miss Status Holoding Register (MSHR) is introduced to manage the queue of unfinished transactions. The design aims to reduce blocking by processing multiple transactions in parallel. Each entry of MSHR records transaction details, such as source identifier, transaction type, address, and control bits, to guide cache operations, such as read or write back, to ensure data consistency and process optimization, especially in a multi-core processor environment to ensure efficient and orderly concurrent access. One of the main challenges it faces is to effectively manage concurrent operation requests for the same cache block, namely conflicts (hazards), and it is necessary to find a balance between maintaining efficiency and consistency.
[0006] In order to maintain this delicate balance and promote efficient execution, the non-blocking MSHR design principle is currently adopted, allowing parallel processing to reach an unprecedented level. However, this also brings additional complexity, that is, a conflict resolution mechanism needs to be carefully designed to adhere to the consistency commitment. This conflict handling mechanism mainly includes two functions, the first is the address comparison operation, and the second is the sleep and wake-up operation. Specifically, the newly arrived transaction first undergoes a strict pre-check to detect whether there are outstanding transactions pointing to the same cache block waiting in line. If a predecessor is found, the transaction will not immediately intervene in the competition, but will enter a dormant state and wait for the completion of the previous transaction before being awakened and continuing its execution.
[0007] Although waiting ensures that consistency is not destroyed, it also brings side effects - subsequent transactions are forced to pause, processing delays are increased, and overall processing efficiency is affected. Summary of the invention
[0008] In view of the defects in the prior art, embodiments of the present invention provide a consistent transaction processing method, a consistent transaction processing device, an electronic device and a storage medium.
[0009] In a first aspect, an embodiment of the present invention provides a consistent transaction processing method, including:
[0010] When a conflict occurs, the newly enqueued transaction is compared with the last enqueued transaction;
[0011] If the transaction type of the newly enqueued transaction and the last enqueued transaction are both read-only transactions, the enqueued state of the newly enqueued transaction is marked with the enqueued state of the last enqueued transaction, wherein the enqueued state includes a dormant state or a wake-up state;
[0012] The newly enqueued transaction is associated with the last enqueued transaction, and the transaction index value of the newly enqueued transaction is recorded in the last enqueued transaction as the associated index value.
[0013] As the above method, optionally, it also includes:
[0014] When the enqueue state of the last enqueued transaction changes, the associated enqueued transaction is determined according to the associated index value, and the enqueue state of the associated enqueued transaction is synchronized.
[0015] As the above method, optionally, it also includes:
[0016] If the transaction type of the newly enqueued transaction and the last enqueued transaction are both write transactions, the enqueued status of the last enqueued write transaction is used to mark the enqueued status of the newly enqueued write transaction;
[0017] Determining a byte enable bit for the newly enqueued write transaction;
[0018] The newly enqueued write transaction is associated with the last enqueued write transaction, and the transaction index value of the newly enqueued write transaction is recorded in the last enqueued write transaction as the associated index value.
[0019] As the above method, optionally, it also includes:
[0020] When a new enqueued write transaction and an associated last enqueued write transaction are awakened, the byte enable bit of the new enqueued write transaction and the byte enable bit of the last enqueued write transaction are merged according to the processing result.
[0021] As the above method, optionally, it also includes:
[0022] If the transaction type of the newly enqueued transaction is not a read-only transaction or a write transaction as the last enqueued transaction, the enqueuing state of the newly enqueued transaction is marked as a dormant state;
[0023] The last enqueued transaction is recorded as the dormant, the newly enqueued transaction is recorded as the dormant, and the transaction index value of the newly enqueued transaction is recorded in the last enqueued transaction as the dormant index value.
[0024] As the above method, optionally, it also includes:
[0025] When the sleeper queued transaction is dequeued, the sleeper queued transaction is determined according to the recorded sleeper index value, and the queued state of the sleeper queued transaction is changed.
[0026] As in the above method, optionally, when a conflict occurs, before comparing the newly queued transaction with the last queued transaction, the method further includes:
[0027] Receiving a pending transaction and determining an address of the pending transaction;
[0028] Determining, according to the address of the transaction to be processed, whether there is a queue to be processed corresponding to the address;
[0029] If so, it is determined that an address conflict occurs, and the pending transaction is taken as a new transaction to be queued in the pending queue.
[0030] In a second aspect, an embodiment of the present invention provides a consistent transaction processing device, including:
[0031] The comparison module is used to compare the newly enqueued transaction with the last enqueued transaction when a conflict occurs;
[0032] a marking module, configured to mark the enqueue state of the newly enqueued transaction with the enqueue state of the last enqueued transaction if the transaction type of the newly enqueued transaction and the last enqueued transaction are both read-only transactions, wherein the enqueue state includes a dormant state or a wake-up state;
[0033] The association module is used to associate the new enqueued transaction with the last enqueued transaction, and record the transaction index value of the new enqueued transaction in the last enqueued transaction as the association index value.
[0034] In a third aspect, an embodiment of the present invention provides an electronic device, including:
[0035] A memory and a processor, wherein the processor and the memory communicate with each other via a bus; the memory stores program instructions that can be executed by the processor, and the processor calls the program instructions to execute the consistency transaction processing method as described in any one of the first aspects above.
[0036] In a fourth aspect, an embodiment of the present invention provides a storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the consistency transaction processing method as described in any one of the above-mentioned first aspects is implemented.
[0037] The consistent transaction processing method provided by the embodiment of the present invention, when a conflict occurs, compares the newly enqueued transaction with the last enqueued transaction; if the transaction type of the newly enqueued transaction and the last enqueued transaction are both read-only transactions, the enqueued state of the newly enqueued transaction is marked with the enqueued state of the last enqueued transaction, wherein the enqueued state includes a dormant state or a wake-up state; associates the newly enqueued transaction with the last enqueued transaction, and records the transaction index value of the newly enqueued transaction in the last enqueued transaction as the associated index value. The consistent transaction processing method provided by the embodiment of the present invention, for read-only type transactions, adjusts the dormant-wake-up mechanism when a conflict occurs, and by relaxing PoC, greatly reduces the waiting time between transactions while ensuring consistency, speeds up the turnover speed of transaction processing, and thus significantly improves the overall processing capability and response efficiency of the system. BRIEF DESCRIPTION OF THE DRAWINGS
[0038] Figure 1 is a flowchart of a consistent transaction processing method embodiment of the present invention;
[0039] Figure 2 is a structural block diagram of an embodiment of a consistent transaction processing device of the present invention;
[0040] Figure 3 It is a structural block diagram of an electronic device embodiment of the present invention. DETAILED DESCRIPTION
[0041] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, the present invention is further described in detail below with reference to the accompanying drawings and specific embodiments.
[0042] Reference Figure 1 , shows a flowchart of a consistent transaction processing method embodiment of the present invention, which may specifically include the following steps:
[0043] Step S110: When a conflict occurs, compare the newly queued transaction with the last queued transaction;
[0044] Specifically, HNF is a node located inside the NoC interconnect structure. Its main responsibility is to receive protocol transactions from request nodes, perform necessary cache consistency actions, and return responses to these request nodes. Among them, transactions perform a single operation, usually either reading from memory or writing to memory. In short, HNF is responsible for handling all operations related to memory data consistency, playing a role in centrally managing data status and coordinating data access between various processors or cores to ensure that the data seen by all participants is consistent.
[0045] Missing Status Holoding Register (MSHR) is the control center of HNF. The internal storage structure of MSHR is a register stack with multiple entries (MSHR entries), one of which corresponds to each transaction. Each entry includes all the control bits required by the transaction, as well as some information of the transaction itself, such as source IP (SrcID), transaction type (opcode) and address, so that MSHR can handle multiple transactions at the same time.
[0046] In the implementation of non-blocking design of on-chip network, managing pending transactions through MSHR is crucial to maintain cache consistency. In the existing scheme, when there are multiple operations on the same cache block in MSHR, the conflict resolution strategy adopted is to suspend (sleep) the subsequent transaction until the preceding transaction is completed, which is to ensure the correct order of operations. In HNF, the address comparison and sleep-wake functions are completed by the address buffer (Addr Buffer) submodule, and the Addr Buffer submodule records each enqueued transaction. The sleep-wake status of the transaction after enqueuing is recorded by the sleep status bit of the enqueued Entry item.
[0047] In order to further improve system efficiency and reduce unnecessary waiting time, in an embodiment of the present invention, when address comparison is performed in the AddrBuffer submodule and a conflict hazard is determined, pending transactions requesting the same cache block address are placed in the same queue, unprocessed transactions are queued in the order in which the requests are received, and the newly queued transaction is compared with the last queued transaction. For example, the queue entry of the newly queued transaction is Entry b, and the queue entry of the queued transaction that was queued before Entry b (the last queued transaction) is Entry a. In this embodiment of the present invention, only the newly queued transaction is compared with the last queued transaction in the queue, and is no longer compared with other transactions in the queue.
[0048] Step S120: If the transaction type of the newly enqueued transaction and the last enqueued transaction are both read-only transactions, the enqueuing state of the newly enqueued transaction is marked with the enqueuing state of the last enqueued transaction, wherein the enqueuing state includes a dormant state or a wake-up state;
[0049] Specifically, the Addr Buffer submodule first checks the transaction types of the two enqueued transactions (the new enqueued transaction and the previous enqueued transaction) to determine whether the transaction types are both read-only transactions, for example, ReadOnce or ReadNoSnp, where ReadOnce is a read request for a snoopable address area to obtain a consistent data snapshot. The data size is a cache line, and the received data will not be cached by the requester. ReadNoSnp is a read request for a non-snoopable address area, the data is included in the completion response, and the data size depends on the data size attribute value in the request, with a maximum of a cache line size; the received data will not be cached by the requester.
[0050] If the transaction type of the newly enqueued transaction and the transaction type of the last enqueued transaction are both ReadOnce or ReadNoSnp, the two transactions maintain the same enqueued state, that is, they are either in the dormant state or in the awakened state at the same time. The enqueued state of the last enqueued transaction is obtained from the queue, and the state of the newly enqueued transaction is directly marked as the same enqueued state as the enqueued state of the last enqueued transaction, and the two transactions maintain the same dormant-awake state. In practical applications, the enqueued state of the enqueued transaction is represented by the dormant state bit. When the dormant state bit of the enqueued transaction is set, it indicates that the enqueued transaction is in the dormant state. When the dormant state bit of the enqueued transaction is reset, it indicates that the enqueued transaction is in the awakened state and the enqueued transaction can be processed. When the dormant state bit of the last enqueued transaction is set, the dormant state bit of the newly enqueued transaction is also set.
[0051] In some special cases, such as those containing only ReadOnce and ReadNoSnp transactions, the consistency requirements can be appropriately relaxed without compromising data consistency. Due to their read-only properties, these two transactions theoretically do not interfere with the data state, and concurrent execution with each other does not cause consistency issues. Therefore, an optimization strategy is proposed: allowing such transactions to proceed directly without following the conventional sleep rules when detecting pending transactions with the same address in MSHR.
[0052] For example, if the newly enqueued transaction (Entry b) and the previous enqueued transaction (Entry a) are both ReadOnce or ReadNoSnp, if Entry a is in the awake state, Entry b will also remain in the awake state. If Entry a is in the dormant state, the dormant state bit of Entry b will also be set.
[0053] Step S130: Associating the new enqueued transaction with the last enqueued transaction, and recording the transaction index value of the new enqueued transaction in the last enqueued transaction as an associated index value.
[0054] Specifically, the newly enqueued transaction is always associated with the last enqueued transaction, and the last enqueued transaction records the associated index value as the transaction index value of the newly enqueued transaction. For example, Entry b is always associated with Entry a, and Entry a records the associated item index value Entry b.
[0055] In traditional designs, a more conservative strategy is adopted for transaction processing mechanisms, especially when it comes to cache consistency maintenance. Specifically, when two transactions request access to the same cache block (Cache Block) and both are read-only (ReadOnce or ReadNoSnp), even if these read operations do not essentially modify the data, the traditional processing method still requires that the later arriving transaction must wait for the previous transaction to be completely processed and exit the queue before it can start its own execution process. This approach is mainly due to the consideration of strict control of data consistency, ensuring that at any time, all transactions accessing the same data see the same and consistent version of the data. However, this strictly sequential processing strategy sacrifices the overall efficiency of the system to a certain extent, especially in high-concurrency read scenarios, where transactions with no modification intentions incur unnecessary delays due to waiting.
[0056] To address this efficiency bottleneck, the embodiment of the present invention proposes an innovative processing strategy, that is, to flexibly adjust the transaction processing flow of a specific type while ensuring that data consistency is not affected. Specifically, for read-only transactions such as ReadOnce and ReadNoSnp mentioned above, even if the target of their requests is the same cache block, the later-arriving transaction is allowed to execute directly without waiting for the previous transaction to complete. This is because these transactions do not essentially change the data state, so the execution order between them has no effect on the final result and will not destroy the consistency of the data.
[0057] The consistent transaction processing method provided by the embodiment of the present invention, when a conflict occurs, compares the newly enqueued transaction with the last enqueued transaction; if the transaction type of the newly enqueued transaction and the last enqueued transaction are both read-only transactions, the enqueued state of the newly enqueued transaction is marked with the enqueued state of the last enqueued transaction, wherein the enqueued state includes a dormant state or a wake-up state; associates the newly enqueued transaction with the last enqueued transaction, and records the transaction index value of the newly enqueued transaction in the last enqueued transaction as the associated index value. The consistent transaction processing method provided by the embodiment of the present invention, for read-only type transactions, adjusts the dormant-wake-up mechanism when a conflict occurs, and by relaxing PoC, greatly reduces the waiting time between transactions while ensuring consistency, speeds up the turnover speed of transaction processing, and thus significantly improves the overall processing capability and response efficiency of the system.
[0058] On the basis of the above embodiment, further comprising:
[0059] When the enqueue state of the last enqueued transaction changes, the associated enqueued transaction is determined according to the associated index value, and the enqueue state of the associated enqueued transaction is synchronized.
[0060] Specifically, when the enqueuing state of a certain enqueuing transaction changes, for example, from a dormant state to an awake state, the MSHR module checks whether the enqueuing transaction with the changed state has any related matters. If so, the associated enqueuing transaction is determined based on the associated index value, and the enqueuing state of the associated enqueuing transaction is synchronized, for example, the enqueuing state of the associated enqueuing transaction is changed to an awake state. At this time, the enqueuing transaction and the associated enqueuing transaction can be processed in parallel.
[0061] For example, if both Entry a and Entry b are ReadOnce transactions, the two transactions maintain the same sleep-wake state. If Entry a is in the wake state, Entry b will also remain in the wake state. If Entry a is in the sleep state, the sleep state bit of Entry b will also be set. Entry b will always remain associated with Entry a, and Entry a will record the associated item index value. When Entry a is awakened, Entry b will also be awakened synchronously, and the sleep state bit will be reset.
[0062] When Entry a is dequeued, Entry b is dequeued, and the transactions are processed in parallel. Since read-only transactions do not essentially change the data state, the order in which they are executed has no effect on the final result and does not destroy the consistency of the data.
[0063] On the basis of the above embodiments, further comprising:
[0064] If the transaction type of the newly enqueued transaction and the last enqueued transaction are both write transactions, the enqueued status of the last enqueued write transaction is used to mark the enqueued status of the newly enqueued write transaction;
[0065] Determining a byte enable bit for the newly enqueued write transaction;
[0066] The newly enqueued write transaction is associated with the last enqueued write transaction, and the transaction index value of the newly enqueued write transaction is recorded in the last enqueued write transaction as the associated index value.
[0067] Specifically, there is room for further optimization of write transaction concurrency, such as CopyBackWrite and Non-CopyBack Write. The difference in processing methods between the two types of transactions provides the possibility for optimization.
[0068] The possible scenarios for concurrent CopyBack Write and Non-CopyBack Write include:
[0069] (1) CopyBack Write arrives first, followed by Non-CopyBack Write: In this case, the Non-CopyBack Write may overwrite part of the CopyBack Write data, and the requirements for the consistency point (PoC) can be relaxed, which means that the Non-CopyBack Write is allowed to execute directly even if it only overwrites part of the data, because in this case, the consistency of the data is still maintained, although some old data may be sacrificed.
[0070] (2) Non-CopyBack Write comes first, followed by CopyBack Write: In theory, the subsequent CopyBackWrite will completely overwrite the previous Non-CopyBack Write, but this usually means a software design error, that is, multiple entities try to update different parts of the same address at the same time. In this case, even if the strict write operation order is not strictly followed, it will not further aggravate the error condition because the root cause of the problem lies in improper software design.
[0071] (3) Two consecutive Non-CopyBack Writes: In this case, no matter what the order is, reasonable software design should ensure that the address ranges of the two write operations do not overlap.
[0072] Therefore, at the hardware level, the Byte Enable (BE) bit can be used to accurately control the valid data part of the write operation, so that even if two write operations involve the same cache line, the valid data can be merged through the BE bit, theoretically avoiding conflicts and further improving efficiency.
[0073] Therefore, when the transaction type of the newly enqueued transaction is the same as that of the previous enqueued transaction, for example, the previous enqueued write transaction is CopyBack Write and the newly enqueued write transaction is Non-CopyBack Write, the enqueued status of the previous enqueued write transaction is used to mark the enqueued status of the newly enqueued write transaction, so that the enqueued status of the new enqueued write transaction and the previous enqueued write transaction are synchronized. At the same time, in order to avoid conflicts, the byte enable bit of the newly enqueued write transaction is set, that is, the area in the cache block that the newly enqueued write transaction can operate on, the newly enqueued write transaction is associated with the previous enqueued write transaction, and the transaction index value of the newly enqueued write transaction is recorded in the previous enqueued write transaction as the associated index value.
[0074] In the embodiment of the present invention, a new perspective is proposed by deeply analyzing the characteristics and potential interactions of write transactions, which shows that under certain conditions, moderate relaxation of the consistency requirements (PoC) between write transactions is not only feasible, but also can significantly improve the system processing efficiency. Of course, such an optimization strategy needs to be combined with strict software design specifications to ensure that data consistency and system correctness are not affected. Through this refined management and optimization, the growing complexity and performance challenges in modern SoC design can be better addressed.
[0075] On the basis of the above embodiments, further comprising:
[0076] When a new enqueued write transaction and an associated last enqueued write transaction are awakened, the byte enable bit of the new enqueued write transaction and the byte enable bit of the last enqueued write transaction are merged according to the processing result.
[0077] Specifically, when the previous enqueued write transaction is awakened, the write transaction starts to execute, and its associated new enqueued write transaction is awakened synchronously, and write operations are performed in parallel. Write processing is performed in the areas corresponding to their respective byte enable bits. After processing, the write processing results of the previous enqueued write transaction and the new enqueued write transaction are merged according to the byte enable bit to avoid write conflicts.
[0078] In an embodiment of the present invention, the validity of write data is finely controlled by intelligently utilizing the byte enable bits in transactions, allowing write transactions to overwrite existing data in a more flexible manner while ensuring the correctness and consistency of the data. For concurrent write transactions, potential conflicts can be effectively avoided through the logical merging of byte enable bits, reducing unnecessary waiting and resource usage, thereby improving overall system efficiency.
[0079] On the basis of the above embodiments, further comprising:
[0080] If the transaction type of the newly enqueued transaction is not a read-only transaction or a write transaction as the last enqueued transaction, then the enqueuing state of the newly enqueued transaction is marked as a dormant state;
[0081] The last enqueued transaction is recorded as the dormant, the newly enqueued transaction is recorded as the dormant, and the transaction index value of the newly enqueued transaction is recorded in the last enqueued transaction as the dormant index value.
[0082] Specifically, the address comparison operation is completed in the Addr Buffer submodule. When a hazard occurs, the queued item (assuming Entry b) will only be compared with the item that was queued one step before Entry b (assuming Entry a). First, check the types of the two transactions. If both transactions are not read-only transactions, or both transactions are not write transactions, the queued item (Entry b) will only be dormant by the item that was queued one step before Entry b (Entry a). Since the previous queued transaction Entry a is already in the queue, the newly queued transaction Entry b will be dormant by Entry a, and the sleep status bit of Entry b is set. Entry a is recorded as the sleeper, and Entry b is recorded as the sleeper. The transaction index of Entry b is recorded in Entry a as the index value of the sleeper.
[0083] When the sleep state bit operation occurs, the Addr Buffer submodule notifies the MSHR module of the Entry item that causes the sleep state (the sleeper) and the Entry item that needs to sleep (the sleeper), and the sleeper item records the index value of the sleeper item through the register.
[0084] For example, when Entry a is queued, Entry c, which is queued before Entry a, has a different transaction type from Entry a. Then, the sleep state bit of Entry a is set, Entry c is used as the sleeper, and Entry a is used as the sleeper. The sleeper index value of Entry c is recorded as the transaction index of Entry a.
[0085] When Entry b is enqueued, Entry a, which was enqueued before Entry b, has the same transaction type as Entry b, both are read-only transactions or both are write transactions. Then the enqueuing status of Entry a and Entry b is synchronized, the sleep status bit of Entry b is set, Entry a and Entry b are associated, and the associated index value of Entry a is recorded as the transaction index of Entry b.
[0086] On the basis of the above embodiments, further comprising:
[0087] When the sleeper queued transaction is dequeued, the sleeper queued transaction is determined according to the recorded sleeper index value, and the queued state of the sleeper queued transaction is changed.
[0088] Specifically, after the sleeper transaction is awakened, it starts to execute the corresponding operation and is dequeued after the execution is completed. When the sleeper enqueued transaction is dequeued, it needs to check whether there is a dormant item recorded in its own register. According to the recorded dormant index value, the dormant enqueued transaction is determined and the enqueued status of the dormant enqueued transaction is changed.
[0089] For example, when Entry c is dequeued, it is necessary to check whether there is a dormant entry recorded in its own register. If there is (i.e., Entry a), the dormant entry Entry a is awakened, and Entry a resets the dormant state bit, so that Entry a starts running and the wake-up operation is completed.
[0090] Since Entry a has an associated transaction Entry b, the associated transaction Entry b is awakened synchronously, and Entry b resets the sleep state bit, so that Entry b starts running and the awakening operation is completed. Entry a and Entry b are executed in parallel without affecting data consistency, reducing the waiting time of Entry b.
[0091] The embodiment of the present invention optimizes the transaction processing flow in a specific scenario without destroying data consistency by carefully distinguishing transaction types, thereby reducing unnecessary waiting time and improving the overall response speed of the system.
[0092] On the basis of the above embodiments, further comprising:
[0093] When a conflict occurs, before comparing the newly enqueued transaction with the last enqueued transaction, the following steps are also included:
[0094] Receiving a pending transaction and determining an address of the pending transaction;
[0095] Determining, according to the address of the transaction to be processed, whether there is a queue to be processed corresponding to the address;
[0096] If so, it is determined that an address conflict occurs, and the pending transaction is taken as a new transaction to be queued in the pending queue.
[0097] Specifically, the MSHR module receives the pending transaction and determines the address of the pending transaction. The Addr Buffer submodule compares the address and determines whether there is a pending queue corresponding to the address according to the address of the pending transaction, that is, whether there is an unprocessed transaction with the same address. If so, the Addr Buffer submodule determines that an address conflict occurs and enqueues the pending transaction as a new enqueued transaction of the corresponding pending queue.
[0098] When enqueuing, determine whether the newly enqueued transaction and the last enqueued transaction in the queue are both read-only transactions or both write transactions. If so, synchronize the enqueued status of the newly enqueued transaction with the last enqueued transaction, and associate the transaction index value of the newly enqueued transaction with the last enqueued transaction. When the enqueued status of the last enqueued transaction changes, synchronize the enqueued status of the associated enqueued transaction according to the associated index value, so that the two can be executed in parallel.
[0099] Determine whether the newly enqueued transaction and the last enqueued transaction in the queue are both read-only transactions or both write transactions. If neither of the above is the case, mark the enqueued state of the newly enqueued transaction as dormant and make it the dormant of the last enqueued transaction. When the last enqueued transaction is dequeued, wake up the corresponding dormant transaction.
[0100] The consistent transaction processing method provided in the embodiment of the present invention adjusts the sleep-wake-up mechanism when a conflict occurs for read-only transactions or write transactions, and by relaxing the consistency nodes, greatly reduces the waiting time between transactions while ensuring consistency, speeds up the transaction processing turnover speed, and effectively improves the transaction processing efficiency and system response speed without significantly increasing the system burden, taking into account the practicality and economy of the technology.
[0101] It should be noted that, for the sake of simplicity, the method embodiments are described as a series of action combinations, but those skilled in the art should be aware that the embodiments of the present invention are not limited by the order of the actions described, because according to the embodiments of the present invention, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of the present invention.
[0102] Reference Figure 2 , shows a structural block diagram of an embodiment of a consistency transaction processing device of the present invention, which may specifically include the following modules:
[0103] A comparison module 210, for comparing a newly queued transaction with a previously queued transaction when a conflict occurs;
[0104] A marking module 220, configured to mark the enqueue state of the new enqueue transaction with the enqueue state of the last enqueue transaction if the transaction type of the new enqueue transaction and the last enqueue transaction are both read-only transactions, wherein the enqueue state includes a dormant state or a wake-up state;
[0105] The association module 230 is used to associate the new enqueued transaction with the last enqueued transaction, and record the transaction index value of the new enqueued transaction in the last enqueued transaction as the association index value.
[0106] As the above device, optionally, further comprises:
[0107] The synchronization module is used to determine the associated enqueuing transaction according to the associated index value and synchronize the enqueuing status of the associated enqueuing transaction when the enqueuing status of the previous enqueuing transaction changes.
[0108] As in the above device, optionally, the marking module 220 is further used for:
[0109] If the transaction type of the newly enqueued transaction and the last enqueued transaction are both write transactions, the enqueued status of the last enqueued write transaction is used to mark the enqueued status of the newly enqueued write transaction;
[0110] Determining a byte enable bit for the newly enqueued write transaction;
[0111] The association module 230 is also used for:
[0112] The newly enqueued write transaction is associated with the last enqueued write transaction, and the transaction index value of the newly enqueued write transaction is recorded in the last enqueued write transaction as the associated index value.
[0113] As the above device, optionally, further comprises:
[0114] A merging module is used to merge the byte enable bit of a new enqueued write transaction and the byte enable bit of the last enqueued write transaction according to a processing result when the new enqueued write transaction and the associated last enqueued write transaction are awakened.
[0115] As the above device, optionally, further comprises:
[0116] A dormancy module, used for marking the enqueuing state of the newly enqueued transaction as a dormant state if the transaction type of the newly enqueued transaction and the last enqueued transaction are not both read-only transactions or not both write transactions;
[0117] The association module 230 is also used for:
[0118] The last enqueued transaction is recorded as the dormant, the newly enqueued transaction is recorded as the dormant, and the transaction index value of the newly enqueued transaction is recorded in the last enqueued transaction as the dormant index value.
[0119] As the above device, optionally, further comprises:
[0120] The changing module is used to determine the dormant enqueued transaction according to the recorded dormant index value when the dormant enqueued transaction is dequeued, and change the enqueued state of the dormant enqueued transaction.
[0121] As the above device, optionally, further comprises: an entry module, the entry module is used to:
[0122] Receiving a pending transaction and determining an address of the pending transaction;
[0123] Determining, according to the address of the transaction to be processed, whether there is a queue to be processed corresponding to the address;
[0124] If so, it is determined that an address conflict occurs, and the pending transaction is taken as a new transaction to be queued in the pending queue.
[0125] As for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment, which will not be repeated here.
[0126] Reference Figure 3 , shows a structural block diagram of an electronic device embodiment of the present invention, the device includes: a processor (processor) 310, a memory (memory) 320 and a bus 330;
[0127] The processor 310 and the memory 320 communicate with each other via the bus 330;
[0128] The processor 310 is used to call the program instructions in the memory 320 to execute the methods provided by the above-mentioned method embodiments, for example, including: when a conflict occurs, comparing the newly enqueued transaction with the last enqueued transaction; if the transaction type of the newly enqueued transaction is the same as the transaction type of the last enqueued transaction, and both are read-only transactions, then using the enqueued status of the last enqueued transaction to mark the enqueued status of the newly enqueued transaction, wherein the enqueued status includes a dormant state or a wake-up state; associating the newly enqueued transaction with the last enqueued transaction, and recording the transaction index value of the newly enqueued transaction in the last enqueued transaction as the associated index value.
[0129] An embodiment of the present invention discloses a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium, and the computer program includes program instructions. When the program instructions are executed by a computer, the computer can execute the methods provided by the above-mentioned method embodiments, for example, including: when a conflict occurs, comparing a newly enqueued transaction with a last enqueued transaction; if the transaction type of the newly enqueued transaction is the same as the transaction type of the last enqueued transaction, and both are read-only transactions, marking the enqueuing state of the newly enqueued transaction with the enqueuing state of the last enqueued transaction, wherein the enqueuing state includes a dormant state or a wake-up state; associating the newly enqueued transaction with the last enqueued transaction, and recording the transaction index value of the newly enqueued transaction in the last enqueued transaction as an associated index value.
[0130] An embodiment of the present invention provides a non-transitory computer-readable storage medium, which stores computer instructions, and the computer instructions enable the computer to execute the methods provided by the above-mentioned method embodiments, for example, including: when a conflict occurs, comparing a newly enqueued transaction with a last enqueued transaction; if the transaction type of the newly enqueued transaction is the same as the transaction type of the last enqueued transaction, and both are read-only transactions, using the enqueued status of the last enqueued transaction to mark the enqueued status of the newly enqueued transaction, wherein the enqueued status includes a dormant state or a wake-up state; associating the newly enqueued transaction with the last enqueued transaction, and recording the transaction index value of the newly enqueued transaction in the last enqueued transaction as an associated index value.
[0131] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.
[0132] It should be understood by those skilled in the art that the embodiments of the present invention may be provided as methods, devices or computer program products. Therefore, the embodiments of the present invention may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, the embodiments of the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.
[0133] The embodiments of the present invention are described with reference to the flowcharts and / or block diagrams of the methods, terminal devices (systems) and computer program products according to the embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of the processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing terminal device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.
[0134] These computer program instructions may also be stored in a computer readable memory capable of directing a computer or other programmable data processing terminal device to operate in a specific manner, so that the instructions stored in the computer readable memory produce a manufactured product including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.
[0135] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device so that a series of operating steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable terminal device to implement the process. Figure 1 A process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.
[0136] Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present invention.
[0137] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or terminal device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or terminal device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or terminal device including the elements.
[0138] The above is a detailed introduction to a consistency transaction processing method, a consistency transaction processing device, an electronic device and a storage medium provided by the present invention. Specific examples are used in this article to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea; at the same time, for general technical personnel in this field, according to the idea of the present invention, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present invention.
Claims
1. A consistent transaction processing method, characterized in that: include: When a conflict occurs, the newly enqueued transaction is compared with the last enqueued transaction; If the transaction type of the newly enqueued transaction and the last enqueued transaction are both read-only transactions, the enqueued state of the newly enqueued transaction is marked with the enqueued state of the last enqueued transaction, wherein the enqueued state includes a dormant state or a wake-up state; Associating the newly enqueued transaction with the last enqueued transaction, and recording the transaction index value of the newly enqueued transaction in the last enqueued transaction as the associated index value; When the enqueue state of the last enqueued transaction changes, the associated enqueued transaction is determined according to the associated index value, and the enqueue state of the associated enqueued transaction is synchronized.
2. The method according to claim 1, characterized in that Also includes: If the transaction type of the newly enqueued transaction is a write transaction as is the transaction type of the last enqueued transaction, the enqueued status of the last enqueued write transaction is used to mark the enqueued status of the newly enqueued write transaction; Determining a byte enable bit for the newly enqueued write transaction; The newly enqueued write transaction is associated with the last enqueued write transaction, and the transaction index value of the newly enqueued write transaction is recorded in the last enqueued write transaction as the associated index value.
3. The method according to claim 2, characterized in that Also includes: When a new enqueued write transaction and an associated last enqueued write transaction are awakened, the byte enable bit of the new enqueued write transaction and the byte enable bit of the last enqueued write transaction are merged according to the processing result.
4. The method according to claim 2, characterized in that: Also includes: If the transaction type of the newly enqueued transaction is not a read-only transaction or a write transaction as the last enqueued transaction, then the enqueuing state of the newly enqueued transaction is marked as a dormant state; The last enqueued transaction is recorded as the dormant, the newly enqueued transaction is recorded as the dormant, and the transaction index value of the newly enqueued transaction is recorded in the last enqueued transaction as the dormant index value.
5. The method according to claim 4, characterized in that Also includes: When the sleeper queued transaction is dequeued, the sleeper queued transaction is determined according to the recorded sleeper index value, and the queued state of the sleeper queued transaction is changed.
6. The method according to any one of claims 1 to 5, characterized in that: When a conflict occurs, before comparing the newly enqueued transaction with the last enqueued transaction, the following steps are also included: Receiving a pending transaction and determining an address of the pending transaction; Determining, according to the address of the transaction to be processed, whether there is a queue to be processed corresponding to the address; If so, it is determined that an address conflict occurs, and the pending transaction is taken as a new transaction to be queued in the pending queue.
7. A consistent transaction processing device, characterized in that: include: The comparison module is used to compare the newly enqueued transaction with the last enqueued transaction when a conflict occurs; a marking module, configured to mark the enqueue state of the newly enqueued transaction with the enqueue state of the last enqueued transaction if the transaction type of the newly enqueued transaction and the last enqueued transaction are both read-only transactions, wherein the enqueue state includes a dormant state or a wake-up state; An associating module, used for associating the newly enqueued transaction with the last enqueued transaction, and recording the transaction index value of the newly enqueued transaction in the last enqueued transaction as an associating index value; The synchronization module is used to determine the associated enqueuing transaction according to the associated index value and synchronize the enqueuing status of the associated enqueuing transaction when the enqueuing status of the previous enqueuing transaction changes.
8. An electronic device, characterized in that: include: A memory and a processor, wherein the processor and the memory communicate with each other via a bus; The memory stores program instructions executable by the processor, and the processor can execute the method according to any one of claims 1 to 6 by calling the program instructions.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.
Citation Information
Patent Citations
High performance transactions in database management systems
CN107077495A
Filtering coherency protocol transactions
CN108154054A