Data access method, electronic equipment and storage medium

Abstract

The invention discloses a data access method, electronic equipment and a storage medium. The method comprises the following steps: in response to received access requests sent by a plurality of cores, obtaining current access states and expected access states of the plurality of cores; determining a first core of which the current access state is consistent with the expected access state from the plurality of cores; generating a monitoring request based on the access request sent by the second core; and sending a monitoring request to the first core to control the first core to send the accessed target data to a second core, the second core being other cores in the plurality of cores except the first core. The technical problem of relatively low data access efficiency in related technologies is solved.

Description

Technical Field

[0001] The present application relates to the field of processors, and in particular, to a data access method, an electronic device, and a storage medium. Background Art

[0002] Currently, in modern computer systems, communication and data consistency between multiple processors are crucial. To achieve this, many systems adopt a mechanism called cache coherence, in which processors use cache lines to store and share data. However, the implementation of cache coherence protocols introduces some performance bottlenecks and complexity. In current cache coherence protocols, communication between processors needs to maintain a certain order to ensure data consistency. However, this order-keeping mechanism may increase communication overhead and latency, resulting in lower efficiency in data access.

[0003] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0004] The embodiments of the present application provide a data access method, an electronic device, and a storage medium to at least solve the technical problem of low efficiency of data access in the related art.

[0005] According to one aspect of an embodiment of the present application, a data access method is provided, which is applied to a processor, and includes: in response to receiving access requests sent by multiple cores, obtaining current access states and expected access states of the multiple cores, wherein the access requests are used to access target data in a cache, and the expected access states are used to characterize the access states to be achieved by the multiple cores; determining a first core from the multiple cores whose current access state is consistent with the expected access state; generating a monitoring request based on the access request sent by the second core, wherein the second core is a core other than the first core among the multiple cores; and sending a monitoring request to the first core to control the first core to send the accessed target data to the second core, wherein the second core is a core other than the first core among the multiple cores.

[0006] According to another aspect of the embodiments of the present application, an electronic device is further provided, including: a memory storing an executable program; and a processor for running the program, wherein the method of each embodiment of the present application is executed when the program is running.

[0007] According to another aspect of an embodiment of the present application, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein when the executable program is running, the device where the computer-readable storage medium is located is controlled to execute the methods in each embodiment of the present application.

[0008] According to another aspect of the embodiments of the present application, a computer program product is also provided, including a computer program, and when the computer program is executed by a processor, the method in each embodiment of the present application is implemented.

[0009] According to another aspect of an embodiment of the present application, a computer program product is also provided, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method in each embodiment of the present application is implemented.

[0010] According to another aspect of the embodiments of the present application, a computer program is also provided, and when the computer program is executed by a processor, the methods in the various embodiments of the present application are implemented.

[0011] In an embodiment of the present application, in response to receiving access requests sent by multiple cores, current access states and expected access states of the multiple cores are obtained, wherein the access requests are used to access target data in a cache, and the expected access states are used to characterize the access states to be achieved by the multiple cores; a first core whose current access state is consistent with the expected access state is determined from the multiple cores; a monitoring request is generated based on the access request sent by the second core, wherein the second core is a core other than the first core among the multiple cores; a monitoring request is sent to the first core to control the first core to send the accessed target data to the second core, wherein the second core is a core other than the first core among the multiple cores, thereby improving the efficiency of data access. It is easy to notice that when multiple cores access the target data in the cache at the same time, they can first compare the current access status of the multiple cores with the expected access status to determine whether there is a first core among the multiple cores whose current access status is the same as the expected access status. The first core does not need to feedback confirmation information to the cache, reducing the communication process between the core and the cache. Monitoring information can be generated based on the access requests of other second cores that have not reached the expected access status, so as to send the monitoring information to the first core. The first core can directly send the accessed target data to the second core, reducing the step of returning the accessed target data, improving the transmission efficiency of the accessed target data, and improving the communication efficiency of the data between cores, thereby solving the technical problem of low efficiency of data access in related technologies.

[0012] It is easy to notice that the above general description and the following detailed description are only for the purpose of exemplifying and explaining the present application, and do not constitute a limitation of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0014] Figure 1 is a hardware structure block diagram of a RISC-V system for implementing a data access method according to an embodiment of the present application;

[0015] Figure 2 is a schematic diagram of a system on chip according to an embodiment of the present application;

[0016] Figure 3 is a flow chart of a data access method according to Embodiment 1 of the present application;

[0017] Figure 4 is a schematic diagram of creating a dependency according to an embodiment of the present application;

[0018] Figure 5 is a schematic diagram of a state transition according to an embodiment of the present application;

[0019] Figure 6 is a communication flow chart of a read process according to an embodiment of the present application;

[0020] Figure 7 is a communication flow chart of a writing process according to an embodiment of the present application;

[0021] Figure 8 is a schematic diagram of a processing path of a monitoring request according to an embodiment of the present application;

[0022] Fig. 9 is a flow chart of a data reading method according to an embodiment of the present application;

[0023] Fig.10 is a flow chart of a method for processing no data according to an embodiment of the present application;

[0024] Fig.11 is a flow chart of a data writing method according to an embodiment of the present application;

[0025] Fig.12 is a flow chart of a method for writing non-copy data according to an embodiment of the present application;

[0026] Fig.13 is a schematic diagram of a data access device according to an embodiment of the present application;

[0027] Fig.14 It is a structural block diagram of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0028] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0029] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0030] First, some nouns or terms that appear in the description of the embodiments of the present application are subject to the following explanations:

[0031] Cacheable Read: In a computer system, when data needs to be read, the system can obtain the data from the cache instead of reading it directly from the main memory. This can improve the reading speed and system performance.

[0032] Copyback Write: When data needs to be written, the data is first written to the cache instead of directly to the main memory. Only when the data in the cache is replaced or needs to be released, the data will be written back to the main memory.

[0033] Silent Drop: Silent Drop means that in network communication, when errors or violations occur during the transmission of data packets, the sender or receiver will not be notified, but the data packets will be directly discarded. This processing method can improve the efficiency of network transmission, but it may also cause data loss.

[0034] In the current cache coherence protocol, communication between processors needs to maintain a certain order. For example, when processing a read request for a cache line, processor A (CA1) may receive a shared cache line (SnpFO) from processor B (HA). In this case, CA1 needs to check whether there is a pending read request in the same cache line. If so, it needs to send a response conflict (RspCnf lt) signal to HA.

[0035] In order to maintain the order, after receiving the RspCnf ltO signal, HA needs to send a forwarding conflict (FwdCnf ltO) signal to CA1 to maintain the order. The "O" here means that the signal needs to maintain the order with the data synchronization completion (Data_S_CmpO) signal. Only after CA1 receives the FwdCnf ltO signal can it receive the Data_S_CmpO signal and then determine how to handle the monitoring request.

[0036] However, this order-keeping mechanism may lead to some disadvantages. First, it may increase the communication overhead between processors, especially under high load conditions. Second, it may introduce some delays because the processor needs to wait for the response signal to arrive before continuing to perform subsequent operations. In addition, this mechanism may also increase the complexity of hardware design because additional logic needs to be implemented to handle the order and conflict of response signals.

[0037] In order to overcome these shortcomings, the present application provides an improved cache consistency protocol, which can reduce the communication overhead and delay between processors while maintaining data consistency, and improve the overall performance of the system. By adopting a novel conflict handling mechanism and signal transmission strategy, the present invention can achieve higher efficiency and scalability.

[0038] According to an embodiment of the present application, a data access method is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0039] The method embodiment provided in Embodiment 1 of the present application can be executed in a RISC-V system, a RISC-V chip or a similar device. Figure 1 1 is a hardware structure block diagram of a RISC-V system for implementing a data access method according to an embodiment of the present application. Figure 1As shown, the RISC-V system 100 can be divided from the bottom layer to the upper layer into a reduced instruction set architecture 101 (including a basic instruction set 101-1 and an extended instruction set 101-2), a hardware layer 102 (including a processor 102-1, a peripheral hardware circuit 102-2, etc.), an interface layer 103, an operating system layer 104 (supporting multiple operating systems 104-1, 104-2, ..., 104-n, such as Linux, FreeSBD, RT-Tread, etc.), a middleware and library layer 105 (including a system library 105-1, an API 105-2 and a middleware service 105-3) and an application layer 106 (including multiple user programs and services 106-1, 106-2, ..., 106-n). The RISC-V system 100 also includes a tool chain 107 from the underlying hardware to the application layer. The tool chain may include a compiler and assembler 107-1, a linker 107-2, a debugger 107-3, a simulator and emulator 107-4, an integrated development environment 107-5, a hardware description language tool 107-6, a performance analysis tool 107-7, and a version control system 107-8, etc.

[0040] The instruction set architecture 101 defines the basic operations and instruction sets supported by the processor 102-1, including a basic instruction set and an extended instruction set, wherein the basic instruction set represents a basic integer instruction set, such as RV32I and RV64I, and the extended instruction set can be floating point, atomic operations, compressed instructions, etc.

[0041] The interface layer 103 includes the specific design of the processor, such as pipeline design, cache structure, execution unit, branch prediction, etc. This layer is the process of mapping abstract instructions to physical hardware.

[0042] The operating system layer 104 is located at the hardware level and provides a hardware abstraction layer and management mechanism, so that applications can interact with the hardware through system calls. The operating system is responsible for managing processor resources, memory, device drivers, task scheduling, etc.

[0043] The middleware and library layer 105 provides a rich set of services and interfaces to help applications run more efficiently. For example, the standard library provides functions such as file operations and mathematical calculations, while the middleware can provide complex services such as network communications and graphical user interfaces.

[0044] The application layer 106 uses the functions and services provided by the lower layer to implement specific application logic. These applications can be command line tools, graphical interface applications, server-side services, etc.

[0045] The tool chain 107 is a key component that connects the underlying hardware to the upper-level software. Various tools in the tool chain 107 function at different levels to support the entire process from hardware design to software development, ensuring the consistency and effectiveness of the entire system design.

[0046] It should be noted that the layered design of the RISC-V architecture allows decoupling between different layers, so that each layer can be developed and optimized independently.

[0047] In an optional embodiment, Figure 2 Shown using the above Figure 1 Schematic diagram of the RISC-V architecture system on chip (System On Chip, SOC). Figure 2 is a schematic diagram of a system on chip according to an embodiment of the present application, such as Figure 2 As shown, the SOC includes at least one RISC-V core 202 (only one is shown in the figure), and the RISC-V core 202 is connected to peripheral devices through a bus 204, including but not limited to ROM 206, RAM 208, timer 210, UART (Universal Asynchronous Receiver / Transmitter) 212, GPIO (General Purpose Input / Output) 214, SPI (Serial Peripheral Interface, Serial Peripheral Interface Bus) 216, etc.

[0048] Under the above operating environment, this application provides Figure 3 The data access method shown. Figure 3 1 is a flow chart of a data access method according to Embodiment 1 of the present application. Figure 3 As shown, the method includes:

[0049] Step S302 , in response to receiving access requests sent by multiple cores, obtaining current access states and expected access states of the multiple cores.

[0050] The access request is used to access the target data in the cache, and the expected access state is used to represent the access state to be achieved by multiple cores.

[0051] The access request may be a request from the core to access data in the cache. The cache may be an L3 / HN in the processor or an HN cache in the core. It may also be other types of cache, which are not limited here.

[0052] Among them, L3 cache is a high-level cache inside the processor, located above L1 and L2 cache. It is usually shared by multi-core processors and is used to store data and instructions shared by multiple cores. The role of L3 cache is to improve the efficiency of data sharing and communication between multi-core processors. HN cache is a high-speed cache network in the processor, which is used to connect different cache levels inside the processor. HN cache includes L1, L2, L3 cache, etc. HN cache can achieve high-speed and low-latency data transmission, ensuring data sharing and collaborative work between various caches inside the processor. L1 cache is the first-level cache in the processor, located inside the processor core, used to store the most commonly used data and instructions. L1 cache has a relatively fast access speed and is usually the fastest cache level in the processor. L2 cache is the second-level cache in the processor, located outside the processor core, and is usually exclusive to each core. The role of L2 cache is to store relatively seldom used but still frequently accessed data and instructions, improving the processor's data hit rate and overall performance.

[0053] The above-mentioned current access status can be the core's current access status to the target data, for example, whether the target data is exclusively used or shared by a core. The current access status can also be whether the target data is being read, whether the target data is being rewritten, whether the target data is read, or whether the target data is written back.

[0054] The above-mentioned expected access state can be the data access state that the core declares in the access request that it hopes to achieve. The expected access state can be whether the target data is successfully read, or whether the target data is successfully rewritten.

[0055] In a multi-core system, when multiple cores access the same data, a mechanism is needed to ensure data consistency and avoid conflicts. By obtaining the current access status and expected access status of all cores requesting access, the needs and potential access conflicts between cores can be better determined, so that subsequent request response methods can be planned in advance.

[0056] The processors in which the above-mentioned multiple cores are located can adopt the RV architecture. The RV architecture is a reduced instruction set computer architecture. The design goal of this structure is to simplify the instruction set and improve processor performance and power efficiency. If the processor in the computer adopts the RV architecture, it means that the computer can use the RV instruction set and can execute the specific instruction set of the RV architecture, thereby achieving higher performance and power efficiency.

[0057] Step S304 , determining a first core from among the multiple cores whose current access state is consistent with the expected access state.

[0058] The first core mentioned above may be a core whose current access state is consistent with the expected access state. By comparing the current access state with the expected access state, the core that has reached the expected access state can be identified. Since the first core has reached the expected access state, it is not necessary to send confirmation information back to the cache, thereby reducing the core communication process and improving data access efficiency.

[0059] Step S306: Generate a monitoring request based on the access request sent by the second core.

[0060] The second core is other cores among the multiple cores except the first core.

[0061] The second core may be a core whose current access state among the multiple cores does not reach the expected access state. The second core may face access conflict or need to coordinate access.

[0062] The above-mentioned snoop request is a mechanism for allowing a core to "listen" to another core's access to target data and obtain the data at an appropriate time.

[0063] Snoop requests are an advanced mechanism for maintaining data consistency and coordinating data access between cores in a multi-core system. By snooping the access status of other cores, the second core can detect potential access conflicts in a timely manner and synchronously update the data status when necessary to ensure system stability and performance. Snoop requests can improve system scalability, reduce unnecessary communication overhead, support advanced cache coherence protocols, and adapt to different workloads and access patterns.

[0064] In an optional embodiment, access between cores can be coordinated by generating a snoop request, ensuring data consistency and allowing the second core to synchronously update the status after the first core completes the access.

[0065] Step S308: Send a monitoring request to the first core to control the first core to send the accessed target data to the second core.

[0066] In an optional embodiment, after the first core completes accessing the data, the first core may send the accessed target data to the second core, to ensure that the cache states of the target data in the multiple cores are consistent.

[0067] The data consistency processing method of the present application can reduce the risk of data inconsistency and improve the overall performance and reliability of the system. By controlling the first core to send data to the second core, it can be ensured that multiple cores can access the latest target data after the data is updated. By coordinating the access of multiple cores to shared data, data consistency and efficient operation of the system are ensured. Through monitoring and status checking, the system can minimize conflicts and optimize the use of resources.

[0068] The present application can adopt an efficient cache status update mechanism in a multi-core processor, and transmit the expected cache access status to multiple cores that access the target data through a response channel or a data channel. When a core receives the expected cache access status, it will compare it with its own current access status. If the current access status of the core already meets the expected access status, there is no need to send a confirmation signal, thereby reducing unnecessary communication overhead. This mechanism is similar to a tacit understanding between cores. They avoid duplicate data transmission by supervising and coordinating each other's cache status updates, thereby improving the overall operating efficiency of the system.

[0069] The present application also includes avoiding unnecessary data transmission by monitoring and transmitting back the transmission process. When a core needs to update data, it can check whether other cores have already made the same update. If they have, there is no need to repeat the operation. This intelligent coordination mechanism not only avoids redundant data transmission, but also improves the data consistency and response speed of the system.

[0070] In an embodiment of the present application, in response to receiving access requests sent by multiple cores, current access states and expected access states of the multiple cores are obtained, wherein the access requests are used to access target data in a cache, and the expected access states are used to characterize the access states to be achieved by the multiple cores; a first core whose current access state is consistent with the expected access state is determined from the multiple cores; a monitoring request is generated based on the access request sent by the second core, wherein the second core is a core other than the first core among the multiple cores; a monitoring request is sent to the first core to control the first core to send the accessed target data to the second core, wherein the second core is a core other than the first core among the multiple cores, thereby improving the efficiency of data access. It is easy to notice that when multiple cores access the target data in the cache at the same time, they can first compare the current access status of the multiple cores with the expected access status to determine whether there is a first core among the multiple cores whose current access status is the same as the expected access status. The first core does not need to feedback confirmation information to the cache, reducing the communication process between the core and the cache. Monitoring information can be generated based on the access requests of other second cores that have not reached the expected access status, so as to send the monitoring information to the first core. The first core can directly send the accessed target data to the second core, reducing the step of returning the accessed target data, improving the transmission efficiency of the accessed target data, and improving the communication efficiency of the data between cores, thereby solving the technical problem of low efficiency of data access in related technologies.

[0071] In the above embodiment of the present application, a monitoring request is generated based on the access request sent by the second core, including: in response to the access request containing a single sub-access request, a monitoring request is allocated to the single sub-access request; in response to the access request containing multiple sub-access requests, a monitoring request is allocated to the multiple sub-access requests based on the request information of the multiple sub-access requests.

[0072] When the above access request includes a single sub-access request, the number of the second core may be one, and the single sub-access request may be an access request sent by the second core.

[0073] When the access request includes multiple sub-access requests, the number of the second cores may be multiple, and the multiple sub-access requests may be access requests sent by multiple sub-cores in the second core.

[0074] The access request mentioned above can be processed by a request queue, in which corresponding identification information can be allocated to different sub-access requests.

[0075] If a single sub-access request is included, a monitoring request can be assigned to the single sub-access request so that the monitoring request can monitor the access status of the target data for the single sub-access request. After the first core accesses the target data, the first core can send the accessed target data to the second core corresponding to the single sub-access request according to the monitoring request assigned to the single sub-access request.

[0076] If multiple sub-access requests are included, monitoring requests can be assigned to the multiple sub-access requests so that the monitoring request can monitor the access status of the target data for the multiple sub-access requests. It should be noted that the multiple sub-access requests can be merged and processed according to the request information of the multiple sub-access requests, thereby releasing the cache space in the request queue so that the request queue can accommodate new requests. The same monitoring request can be assigned to the merged sub-access requests, so that when the target data of the first core reaches the state of the request information corresponding to the multiple sub-access requests, the accessed target data can be uniformly sent to the sub-core corresponding to the merged sub-access request, so that the above-mentioned second core can receive the accessed target data.

[0077] In an optional embodiment, by allocating monitoring requests according to the number of sub-access requests in an access request, the sub-access requests can be better integrated, the allocation efficiency of the monitoring requests can be improved, and the communication efficiency can be further improved.

[0078] In the above embodiment of the present application, monitoring requests are assigned to multiple sub-access requests based on the request information of multiple sub-access requests, including: obtaining request information of multiple sub-access requests, wherein the request information includes at least one of the following: request type, request address and request size; merging the multiple sub-access requests based on the request information to obtain a merged result, wherein the merged result is used to indicate that sub-access results containing the same request information are merged; and allocating monitoring requests to the multiple sub-access requests based on the merged result.

[0079] The request type may be a read operation or a write operation. The request address may be a memory address requested to be accessed. The request size may be the amount of data requested to be accessed.

[0080] In an optional embodiment, information of multiple sub-access requests can be collected through a data channel. This information may include request type, request address, and request size. Based on the collected request information, sub-access requests with the same information can be merged. The purpose of the merger is to integrate access requests with the same request characteristics to form a merged result. This merged result will be used for subsequent processing to improve efficiency and simplify management. After merging the sub-access requests, monitoring requests can be allocated based on the merged results. Based on the merged request information, monitoring requests can be sent to the first core so that the first core can process and respond to these requests.

[0081] When multiple sub-access requests are merged, the merged result may include multiple access requests with the same request characteristics. These merged requests need to be processed by the first core. After the multiple sub-access requests are assigned monitoring requests based on the merged result, the monitoring requests may be sent to the first core so that the first core responds to the monitoring requests, so that the first core sends the accessed target data to the second core according to the monitoring requests, thereby improving the overall communication efficiency.

[0082] In the above embodiment of the present application, the method also includes: in response to receiving feedback information of the listening request, clearing the sub-access request corresponding to the listening request in the request queue based on the feedback information, and obtaining a clearing result, wherein the clearing result is used to release the cache in the request queue, and the feedback information is used to indicate that the listening request has been successfully sent to the first core.

[0083] In an optional embodiment, after receiving feedback information of the listening request, the feedback information may indicate that the listening request has been successfully sent to the first core. This means that the listening request has completed its target task and no longer needs to wait for or rely on the completion of other requests. Based on the feedback information, sub-access requests related to the listening request can be identified and cleared. The sub-access requests here may refer to those requests that depend on the listening request, or further memory access requests triggered by the listening request. After clearing the sub-access requests, a clearing result may be obtained. This result indicates which requests have been processed and which request entries can be released or converted. After clearing the sub-access requests, the entries that depend on the listening request should be converted from the waiting pop-up (WAI T_POP) state to the pop-up (POPPING) state, indicating that they are about to be completed. Once these requests are completed, they will be converted to the IDLE state, indicating that they no longer occupy resources. The clearing result is also used to release the cache in the request queue. This means that once a request is completed, the cache space it occupies can be released for use by other requests.

[0084] By monitoring the request feedback information and clearing the sub-access requests in the request queue, the request queue can be managed effectively, resource usage can be reduced, and system efficiency can be improved. Dependency management and state transition mechanisms ensure the correct processing of requests and the reasonable allocation of resources. At the same time, by clearing out no longer needed requests in a timely manner, the system can avoid potential dangers.

[0085] It should be noted that different request entries have their own specific structure, which contains multiple fields that define the dependencies and status of the request. Dependencies are created based on the order in which the requests arrive. When a new request arrives, if a dependency needs to be created, the system checks the request buffer and creates a dependency with the entry with the same address and tail bit. When creating a dependency, it is necessary to clear the tail bit of the previous entry, set the tail bit of the current entry, and set the identifier of the dependency to the identifier of the previous entry. Request entries can be in different states, including idle (IDLE), waiting to be popped (WAI T_POP), and popping (POPPING).

[0086] The request entry is the basic unit of the data structure when processing a request. Different request entries contain several fields that define the properties and status of the request. According to the image file content, these fields include: transaction information (Txninfos), dependency request entry identifier (Dependency req entry ID), tail bit (Tai l bit), and the state of the marked entry (State). Among them, the transaction information includes the type, address, ID and other information of the request. The dependency request entry identifier indicates which entry the request depends on. The tail bit, 'b1' indicates that the entry is the tail of the dependency chain; 'b0' indicates that it is not the tail. The state of the marked entry, the possible states are idle state, waiting to be popped up, and popping up.

[0087] When a new request arrives at the processing unit and a dependency needs to be created, the request buffer should be checked and a dependency should be created with the entry with the same address and tail bit 'b1'. The tail bit of the previous entry is cleared, the tail bit of the current entry is set, and the flag of the dependent entry is set to the flag of the previous entry. When the entry is popped, it means that the request has been completed. Other entries that depend on the popped entry should transition to the popping state, and the popped entry should transition to the idle state.

[0088] Figure 4 is a schematic diagram of creating a dependency according to an embodiment of the present application, such as Figure 4 As shown, it includes Txn0, Txn1, and Txn2. During the process of creating dependencies, when Txn0 has 'b0', it means that Txn0 is not the tail, and when Txn1 has the tail bit 'b1', it means that Txn1 is the tail of the dependency chain. At this time, the status of Txn0 is in the pop-up state, and the status of Txn1 is waiting for pop-up. When creating dependencies, Txn2 will depend on Txn1. At this time, the status of Txn1 and Txn2 is waiting for pop-up, and Txn0 is in the pop-up state. During the process of dependency creation, when the status of Txn1 is in the pop-up state, the tail bit of Txn2 becomes 'b1', indicating that Txn2 is now the tail of the dependency chain, and the status of Txn2 becomes in the pop-up state. During the entry pop-up process, if Txn2 is completed, Txn0 will become idle and Txn1 will become in the pop-up state.

[0089] Figure 5 is a schematic diagram of a state transition according to an embodiment of the present application, such as Figure 5 As shown, there are three states: popping, waiting for popping, and idle. If a request has a dependency with the previous request, the request may enter the waiting for popping state. If there is no dependency, the request can directly enter the popping state. If the previously dependent entry is popped, the dependent request may transition to the popping state. Finally, once the request processing flow is completed, the request will transition to the idle state.

[0090] In the above embodiment of the present application, a monitoring request is sent to the first core to control the first core to send the accessed target data to the second core, including: determining the monitoring type based on the cache status of the target data and the expected access status of the first core, wherein the cache status is used to indicate whether multiple cores are allowed to access the target data simultaneously; and sending a monitoring request corresponding to the monitoring type to the first core to control the first core to send the accessed target data to the second core.

[0091] The above cache status can be used to indicate whether the target data is unique data or shared data. Unique data indicates that the target data is unique in the cache, and shared data is used to indicate that the target data can be shared among multiple cores at the same time.

[0092] The above content describes a method for coordinating cache consistency and data access permissions between cores in a multi-core processor system. Specifically, the method uses a monitoring mechanism to ensure that different cores follow certain rules and orders when accessing the same data, thereby avoiding data inconsistency and conflict problems. The following is an explanation of the beneficial effects:

[0093] In an optional embodiment, the access rights to the target data may be determined according to the cache status of the target data. If the cache status is that simultaneous access is not allowed, it means that the current core needs to wait for other cores to complete access to the target data to ensure data consistency.

[0094] The expected access state can be determined based on the core's access requirements for the target data. If the expected access state is a read state, it means that the current core only needs to read the data and does not need to modify it; if the expected access state is a write-back state, it means that the current core needs to modify the data and write the modified data back to the cache.

[0095] According to the cache state and the expected access state, the corresponding monitoring type can be determined. If the cache state does not allow simultaneous access and the expected access state is a read state, the system will determine the first monitoring type. The monitoring request corresponding to the first monitoring type carries the identification information of the second core, so that the current core can know which cores are accessing the target data, thereby avoiding conflicts.

[0096] If the cache state allows simultaneous access and the expected access state is the write-back state, the system determines the second monitoring type. The monitoring request corresponding to the second monitoring type carries not only the identification information of the second core, but also the target permission information of the target data. In this way, when the current core modifies the data, it can ensure that it has the corresponding permission to avoid illegal access.

[0097] Through the above monitoring mechanism, the multi-core processor system can effectively solve the cache consistency and data access permission problems between cores and improve the stability and performance of the system. Through the monitoring mechanism, it is ensured that the cores follow a certain order when accessing the same data to avoid data inconsistency caused by simultaneous access. By reasonably allocating access rights, multiple cores are allowed to read data at the same time, improving the parallelism and efficiency of data access. Through the transmission of permission information, it is ensured that the core has the corresponding permission when modifying data to prevent illegal access and data leakage. Through the monitoring mechanism and permission control, the risk of system abnormality and crash caused by core conflicts and data inconsistency is reduced.

[0098] In the above embodiment of the present application, the monitoring type is determined based on the cache status and the access status, including: in response to the cache status being that simultaneous access to the target data is not allowed, and the expected access status is a read status, determining the monitoring type to be a first monitoring type, wherein the monitoring request corresponding to the first monitoring type carries the identification information of the second core; in response to the cache status being that simultaneous access to the target data is allowed, and the expected access status is a write-back status, determining the monitoring type to be a second monitoring type, wherein the monitoring request corresponding to the second monitoring type carries the identification information of the second core and the target permission information of the target data.

[0099] The above identification information may be a unique identification of the second core, or may be identification information of a cache address in the second core.

[0100] The above-mentioned target permission information may be a shared read permission for the target data. If the target data is being written back by the first core, the current permission of the target data may not allow the target data to be shared, or other cores may not allow the target data to be read. By receiving the target permission of the target data carried in the monitoring request, the current permission of the target data can be changed so that the target data can reach the target permission, so that the first core can send the target data to the second core.

[0101] In an optional embodiment, the monitoring type can be determined according to the current state and the expected access state of the target data, so that the permission information can be correctly processed when the target data is written back, thereby ensuring that the target data can be correctly shared or written back. By combining the first paragraph and the second paragraph, it is possible to better understand how to process the permission information of the target data in a multi-core system to ensure the correct sharing and transmission of data.

[0102] In a multi-core system, the first monitoring type and the second monitoring type ensure the accuracy of data access requests by carrying the identification information of the second core. This helps the system correctly identify the source of the request and avoid confusion of data among multiple cores. When the cache state allows simultaneous access and the expected access state is write-back, the second monitoring type will carry the target permission information of the target data. This allows the system to dynamically adjust the sharing permissions of the target data according to the current access requirements and status, thereby improving the flexibility and efficiency of data access.

[0103] When the target data is being written back by the first core, there may be permission restrictions that do not allow other cores to access or share it. By monitoring the target permission information carried in the request, the system can change the current permissions of the target data to achieve data sharing, even during the write-back process. By intelligently determining the monitoring type and carrying the corresponding identification information and permission information, the system can effectively avoid data conflicts between multiple cores. This helps maintain data consistency and integrity. By controlling the identification information of the second core and the permission information of the target data, the system can prevent unauthorized access and data leakage, enhancing the security of the system. Through flexible permission management and precise identification information transmission, the system can reduce performance losses caused by permission conflicts or data inconsistencies, thereby improving overall system performance.

[0104] In the case of target data that can be accessed simultaneously, the introduction of the second monitoring type allows multiple cores to access and modify data simultaneously, supports high-concurrency data access modes, and improves the parallel processing capabilities of the system. This mechanism can be flexibly adjusted according to changes in the number of cores and access modes, adapting to the needs of different application scenarios, and enhancing the scalability and adaptability of the system. By monitoring the target permission information in the request, the data status can be synchronized between multiple cores, ensuring that multiple cores see a consistent data view, which promotes data consistency.

[0105] In the above embodiments of the present application, when the monitoring type is determined to be the first monitoring type, a monitoring request corresponding to the monitoring type is sent to the first core to control the first core to send the accessed target data to the second core, including: sending a monitoring request corresponding to the first monitoring type to the first core to control the first core to send the accessed target data to the second core based on the identification information.

[0106] By sending a snoop request corresponding to the first snoop type to the first core, the system can precisely control when and how the first core sends data to the second core. This helps reduce unnecessary data transmission and improves system efficiency. By sending a snoop request, the second core can ensure that it receives the latest copy of the data after the first core completes access to the target data, thereby maintaining data consistency.

[0107] By sending monitoring requests and receiving data in a timely manner, the second core can respond to access needs for target data more quickly. This helps improve the system's response speed and enhance the user experience. In a multi-core system, different cores may access the same data resource at the same time, resulting in conflicts and competition. By using the monitoring mechanism, the second core can obtain a copy of the data immediately after the first core accesses the data, thereby reducing the possibility of conflicts and competition. By controlling the first core to send the accessed target data to the second core, the system can ensure the security of the data during transmission. This helps prevent unauthorized access or tampering of data during transmission.

[0108] In an optional embodiment, a monitoring request can be sent to the first core to control the first core to send data to the second core when accessing the target data. The permission information of the target data can be adjusted according to the monitoring request corresponding to the second monitoring type to ensure the security and integrity of the data, thereby effectively controlling the flow and transmission of the data and ensuring that the data is not obtained or tampered with by unauthorized users during the transmission process.

[0109] In the above embodiment of the present application, when it is determined that the monitoring type is the second monitoring type, a monitoring request corresponding to the monitoring type is sent to the first core to control the first core to send the accessed target data to the second core, including: sending the monitoring request corresponding to the second monitoring type to the first core; controlling the first core to adjust the current permission information of the accessed target data to the target permission information based on the monitoring request corresponding to the second monitoring type to obtain an adjustment result; and controlling the first core to send the accessed target data to the second core based on the adjustment result.

[0110] The above-mentioned current permission information may be permission that the target data is not allowed to be read or not allowed to be shared and read.

[0111] In an optional embodiment, by determining that the monitoring type is the second monitoring type and sending a corresponding monitoring request to the first core, the function of controlling the first core to send the accessed target data to the second core is realized. The authority control and adjustment of the target data can be realized to protect the security and privacy of the data. When the first core receives the monitoring request corresponding to the second monitoring type, the current authority information of the accessed target data will be adjusted according to the request and adjusted to the target authority information. In this way, it can be ensured that only users or systems that have passed the authority verification can obtain the target data, effectively preventing unauthorized access. Then, the first core sends the target data to the second core according to the adjusted authority information, realizing the secure transmission and control of the data. The access rights of the target data can be effectively controlled and managed, and the security and privacy protection level of the data can be improved.

[0112] By sending a specific listening request, the behavior of the first core sending data to the second core can be precisely controlled. After receiving the request of the second listening type, the first core can dynamically adjust the current permissions of the target data according to the target permission information contained in the request. By adjusting the permission information of the data, it can be ensured that only cores with corresponding permissions can access or modify the data. This enhances the security of the data and prevents unauthorized access and potential data leakage. This mechanism allows multiple cores to share data when performing tasks while ensuring that different cores comply with permission rules. This facilitates collaboration between multiple cores and improves the efficiency of parallel processing. By precisely controlling the access rights of data, conflicts that occur when multiple cores access the same data resource at the same time can be reduced, thereby reducing data contention and potential deadlock risks. When the data permissions are adjusted to meet the target permissions, the first core can quickly send the updated data to the second core, which improves the system's response speed to data needs.

[0113] In the above embodiment of the present application, the method further includes: controlling the first core to feed back a data snapshot of the target data after access to the cache; and updating the target data in the cache based on the data snapshot.

[0114] The data snapshot mentioned above can be a complete or partial copy of the data at a specific point in time. The data snapshot can provide a copy of the state of the data at a specific moment.

[0115] In an optional embodiment, by updating the data snapshot, it is possible to ensure that the data in the cache is up to date, reduce the performance loss caused by outdated cache data, and improve the cache hit rate and the overall efficiency of the system. The data snapshot usually only contains the changed part of the data since the last update, rather than the entire data set. This can reduce the amount of data transmitted between the core and the cache, thereby reducing the overhead of data transmission.

[0116] By controlling the first core to feed back a data snapshot of the target data after access to the cache, it is possible to ensure that the data in the cache is consistent with the data in the main memory. The benefit of this is that it can improve system performance and data reliability while reducing data conflicts and errors. Updating the target data in the cache based on the data snapshot can ensure that the data in the cache is the latest, thereby improving the system's response speed and data accuracy. This optimization method can help the system manage data more efficiently and improve the overall performance and stability of the system.

[0117] In the above embodiments of the present application, the processor adopts a reduced instruction set computing architecture.

[0118] Figure 6 is a communication flow chart of a read process according to an embodiment of the present application, such as Figure 6As shown, the communication process includes core 0 (CORE0), the third level / hierarchical network (L3 / HN), and core 1 (CORE1). The initial state (Initial State) of CORE0 is invalid (Inva l id). CORE0 sends an independent read request (Unique Read) to L3 / HN, L3 / HN feeds back computer data (CompData) to CORE0, CORE1 sends Unique Read to L3 / HN, L3 / HN forwards Forward Unique Snoop to CORE0, CORE0 feeds back snapshot response 1 (SnpResp1) to L3 / HN, and CORE0 sends CompData to CORE1.

[0119] like Figure 6 In the communication process shown, efficient data transmission and sharing can be achieved through data exchange between CORE0 and CORE1 and intermediate forwarding by L3 / HN. First, the initial invalid state of CORE0 means that CORE0 does not have the latest status information about the data before starting communication, and needs to be obtained through query. CORE0 sends an independent read request to L3 / HN to access the computer data, and L3 / HN feeds back the computer data required by CORE0. At the same time, CORE1 also sends an independent read request to L3 / HN, and L3 / HN forwards the forward unique snoop to CORE0. In order to ensure that if CORE0 has updated information about the data, it notifies CORE1. After receiving the forward unique snoop, CORE0 sends a snapshot response 1 to L3 / HN. This indicates that CORE0 has updated its cache or confirmed the validity of the computer data. Finally, CORE0 sends the computer data to CORE1. This step ensures that CORE1 can obtain the latest information about the data, which can ensure the synchronization and consistency of data between different cores.

[0120] In the whole process, through the collaboration between CORE0, CORE1 and L3 / HN, efficient data transmission and sharing can be achieved, improving the overall performance and efficiency of the system. At the same time, through mechanisms such as forward unique monitoring and snapshot response, unnecessary data transmission and conflicts can be reduced, thereby improving the stability and reliability of the system. Therefore, this communication process has a significant beneficial effect on the overall performance and efficiency of the system.

[0121] Figure 7 is a communication flow chart of a writing process according to an embodiment of the present application, such as Figure 7As shown in the figure, the communication flow chart includes core 0 (CORE0), the third level / hierarchical network (L3 / HN), and core 1 (CORE1). The initial state (Initial State) of CORE0 is invalid (Inva l id), the Initial State of CORE1 is the unique modification state (UniqueDirecty State, referred to as UD), CORE0 sends a shared read request (Read Not Shared Direct) to L3 / HN, and CORE1 sends a write back request (Write Back), L3 / HN sends a snoop (Snoop) to CORE1, the expected state (ExpState) is invalid (Ux), and the state after snoop (State After Snoop) is shared consistency (Shared Clean, referred to as SC), CORE1 changes the initial state UD to SC, and feeds back a snapshot data response (SnpDataResp) to L3 / HN, CORE1 feeds back computer data (CompData) to CORE0, and the state (State) of the computer data is SC, and L3 / HN feeds back parallel processing (COMP) from shared consistency to invalid (Inva l id, referred to as I).

[0122] like Figure 7 In the communication process shown, the consistency of data in the multi-core system is ensured through the communication between CORE0 and CORE1. After CORE0 sends a shared read request to L3 / HN, L3 / HN sends a snoop request to CORE1. CORE1 responds to the snoop request and sends a snapshot data response. This fast data exchange reduces the latency of data access. CORE0 and CORE1 can access and modify data at the same time without interfering with each other, which helps improve the overall performance of the system. When CORE0 issues a shared read request, CORE1 may have the only modified copy of the data. In this case, CORE1 needs to write the data back to L3 / HN, update its status to SC, and write the modified computer data to CORE0 at the same time, so that CORE0 can obtain the latest modified computer data, thereby maintaining the consistency of data in CORE0 and CORE1.

[0123] A third-level / hierarchical network refers to a hierarchical structure in the Internet topology, in which network nodes are organized into multiple layers, each with specific relationships and functions. A third-level / hierarchical network usually includes larger ISP (Internet Service Provider) networks and enterprise networks, which use the Border Gateway Protocol (BGP) for routing and communication. The third-level / hierarchical network is designed to improve the scalability, performance and stability of the network.

[0124] Figure 8 is a schematic diagram of a processing path of a monitoring request according to an embodiment of the present application, such as Figure 8 As shown, the System Network Protocol Interface (SNP INTF) receives a snoop request, assigns the snoop request to an entry in a request queue, and searches the current request queue. At the same time, the expected state of the core request can be searched to determine the absorption determinism. The snoop request in the request queue is processed according to the absorption determinism. The expected state can be a symmetric multiprocessing state (SMP EXP STATE) and a core request state (CORE REQ EXP STATE). When the snoop request has access to the L2 cache pipeline, operations of obtaining the physical address, snoop type, and expected cache state can be performed.

[0125] Fig. 9 This is a flow chart of a data reading method according to an embodiment of the present application, through which cache consistency maintenance and data synchronization processes can be implemented. In this protocol, multiple processor cores may have cache copies of the same data. In order to ensure that the data copies on all cores are consistent, a certain protocol needs to be followed to process data access and update requests. Fig. 9 As shown, the method includes:

[0126] Step S901, creating a dependency relationship;

[0127] Before processing data, dependencies between cores need to be established, which helps track which cores in the processor have cached copies of the same data, as well as the state of the data held in the core, such as dirty or clean.

[0128] Step S902, check whether it is ready to be ejected? If not, execute step S903; if so, execute steps S904 and S905;

[0129] The above steps can be used to determine whether the data currently in the cache is ready to be accessed or replaced by other cores.

[0130] Step S903, sleep and wait;

[0131] In some cases, a core may need to wait for operations from other cores to complete, for example, waiting for data synchronization or a response.

[0132] Step S904, checking L3 cache;

[0133] The L3 cache (L3) mentioned above refers to a certain layer in the inspection cache hierarchy.

[0134] Step S905, checking the monitoring filter;

[0135] The snoop filters described above are used to determine which cores or caches need to respond to the snoop request in order to maintain cache coherence.

[0136] Step S906, L3 cache and snoop filter status; if the L3 cache is hit, execute step S907, if the L3 cache is not hit, other cores are hit, execute step S908, if both the L3 cache and other cores are not hit, execute step S909;

[0137] The next step can be determined based on the hit or miss of the L3 cache and the status of the snoop filter.

[0138] Step S907, forwarding from L3 cache, executing step S910;

[0139] If the above L3 cache hits, the required data can be forwarded directly from the L3 cache to the requesting core.

[0140] Step S908, sending a monitoring request to the core;

[0141] If the above L3 cache misses, a snoop request needs to be sent to other cores that may have a copy of the data.

[0142] Step S909, reading can be done in the sub-cache;

[0143] If the L3 cache and other core caches miss, data may need to be obtained from lower-level caches or storage devices.

[0144] Step S910, confirm whether monitoring is required? If yes, execute step S911;

[0145] Through the above steps, it is determined whether it is necessary to send a monitoring request to other cores to maintain data consistency.

[0146] Step S911, receiving all sub-cache responses;

[0147] Wait for responses from all sub-caches to ensure that the relevant cores have processed the request.

[0148] The system may wait for responses from child caches (i.e., caches on other processors or cores) to ensure that all child caches have acknowledged receipt and processed the request before proceeding.

[0149] Step S912, receiving all sub-cache responses with data;

[0150] You can receive responses from all sub-caches that contain the required data.

[0151] Step S913, receiving read confirmation or completion data;

[0152] The above steps can be used to receive notifications of read confirmation or completion data from other cores or caches, thereby facilitating updating the status of the local cache.

[0153] Step S914, pop up the entry and clear the related dependent request entry identifier;

[0154] After the data synchronization and consistency maintenance operations are completed, the relevant entries can be popped from the queue or stack, and the entry identifiers related to the dependent requests can be cleared to facilitate subsequent operations.

[0155] The above steps are mainly a read process for managing entry creation and popping, which can ensure that in a multi-core system, the cache copies on all cores maintain consistency and recent status to avoid data inconsistency and potential calculation errors. The above method allows the system to efficiently process data access and update requests while reducing performance issues caused by cache inconsistency.

[0156] In a multi-core computer system, a cache is a piece of hardware or software used to reduce the time it takes for the processor to access main memory (RAM). A cache is a fast memory that stores copies of data and instructions that are frequently accessed by the processor. In a multi-core system, different cores may have their own caches, as well as higher-level caches that are shared by multiple cores, such as the L3 cache.

[0157] L3 Cache Hit, which means that when the processor requests data, the required data has been found in the L3 cache. Since the L3 cache is usually closer to the processor than the main memory, it provides faster access speed. When data hits in the L3 cache, the processor can directly obtain the data from the L3 cache without waiting for data transfer from the main memory, thereby improving performance.

[0158] Core Cache Hit, which means that when the processor requests data, the required data has been found in the private cache of the core (usually L1 or L2 cache). Each core's private cache is used by the core alone and does not need to be shared with other cores. If the data hits in the core's cache, the request will be processed much faster than getting the data from the L3 cache or main memory.

[0159] Cache coherence is a critical issue in multi-core systems. When one core modifies data in the cache, the copies of the same data in other cores may become outdated. To maintain data coherence, the system may need to use snooping filters to monitor the cache operations of other cores to ensure that all cores have access to the latest version of the data.

[0160] In the above steps, when the status of the L3 cache and the core cache is checked, the system will decide the next operation based on whether the data is hit in the L3 cache or the core cache. If the L3 cache hits, the data can be forwarded directly from the L3 cache; if the L3 cache misses but the cache of other cores hits, a snoop request may need to be sent to ensure data consistency; if both the L3 cache and the cache of other cores miss, the data may need to be read from a lower-level cache or storage device. These steps together ensure efficient and consistent data access in a multi-core system.

[0161] Fig.10 is a flow chart of a method for processing no data according to an embodiment of the present application, such as Fig.10 As shown, the method comprises the following steps:

[0162] Step S1001, creating dependencies;

[0163] You can create a dependency in the system to track which operations depend on the completion of other operations. This ensures that the required prerequisites are met before any operation is performed, thus avoiding potential data inconsistencies.

[0164] Step S1002, ready to pop up? If yes, go to step S1004, if no, go to step S1003;

[0165] Checks whether the operation is ready to be popped from the queue or cache, that is, all operations of its dependencies have completed, determines whether the operation can continue safely, and avoids executing operations that may cause errors when dependencies are not resolved.

[0166] Step S1003, sleep;

[0167] Suspends an operation until a desired event or condition occurs, such as a dependency completing or timing out. This saves resources and prevents unnecessary processor usage while waiting for dependencies to resolve.

[0168] Step S1004, checking the monitoring filter;

[0169] The snoop filter is checked to determine if snoop requests need to be sent to other cores to ensure cache coherency.

[0170] Step S1005: Is there a copy in other remote cores? If yes, go to step S1006; if no, go to step S1008;

[0171] The aforementioned remote core (RN-F) may be a core other than the current core.

[0172] Other cores in the system can be queried to determine if they have a copy of the target data. The distribution of data copies can be determined so that appropriate consistency maintenance measures can be taken.

[0173] Step S1006, sending a monitoring request;

[0174] Sends a snoop request to other cores that have a copy of the data, requesting them to update or confirm their cache status. Sends a snoop request to other cores to check if they have a copy of the target data, and requesting those cores to respond.

[0175] Step S1007, receiving all monitoring responses;

[0176] Wait for all requested cores to return snoop responses indicating whether they have the target data. Ensure that all core responses are received and processed to complete the consistency check.

[0177] Step S1008: Pop entry.

[0178] Once all the monitoring responses have been received, or it is confirmed that no monitoring request needs to be sent, the relevant items of the current operation can be popped up to indicate that the operation has been completed.

[0179] Throughout the above process, the main purpose of data-free transactions is to synchronize states and coordinate operations, rather than to transfer data. This helps reduce the amount of data transfer in the system, lowers latency, and improves overall performance. In this way, the system can handle data access and update requests more efficiently while ensuring that cache copies on multiple cores remain consistent.

[0180] Fig.11 is a flow chart of a data writing method according to an embodiment of the present application, such as Fig.11 As shown, the method comprises the following steps:

[0181] Step S1101, creating a dependency relationship;

[0182] Step S1102, ready to pop up?

[0183] Step S1103, sleep; if yes, execute step S1004, if no, execute step S1103;

[0184] Step S1104, sending a database response mark of completion;

[0185] The above identification may be used to initialize or set a response identifier (Seed CompDBIDResp) for confirming or tracking the completion status in subsequent operations.

[0186] Before the writeback transaction begins, a unique identifier is assigned to the transaction so that it can be tracked and verified after completion. Initializing or setting the response identifier is used to confirm or track the completion status in subsequent operations, which helps the system effectively manage the completion of transactions.

[0187] Step S1105: Does the write-back operation need to be canceled? If yes, execute step S1107; if no, execute step S1106;

[0188] Checks whether a write-back (WB) operation needs to be canceled, possibly because an error occurred or the operating conditions have changed.

[0189] Whether the write-back operation should be continued or canceled can be determined based on the system's internal logic or external signals. This helps avoid unnecessary resource waste and data inconsistency by checking and deciding whether the write-back operation needs to be canceled.

[0190] Step S1106, waiting for the cache to write back data;

[0191] Wait for the cache write-back operation to complete, which includes the data transmission and storage process. This ensures that the data has been successfully written back from the cache to the main memory or the previous level cache, ensuring the consistency and integrity of the data.

[0192] Step S1107, pop up the entry.

[0193] Through these steps, the system's write-back transactions can be effectively managed to ensure data consistency, system stability, and high performance.

[0194] Fig.12 is a flowchart of a method for writing non-copy data according to an embodiment of the present application. Fig.12 As shown, the method comprises the following steps:

[0195] Step S1201, creating dependencies;

[0196] Step S1202, ready to pop up? If yes, go to step S1204, if no, go to step S1203;

[0197] Step S1203, sleep;

[0198] Step S1204: Is monitoring required? If yes, go to step S1205; if no, go to step S1206; if no, go to step S1206;

[0199] Step S1205, check sharing and send a monitoring request;

[0200] In the case where a probe is needed, it checks whether the data is marked as shared (Shared NotFresh, SNF) in the cache, and then sends a probe request to other nodes to ensure data consistency.

[0201] Step S1206, receiving all monitoring responses;

[0202] Step S1207, waiting for the incoherent cache block to write back data.

[0203] After the data consistency is confirmed, wait for the data to be written back to the target storage location from the non-cacheable block (NCB). This step is to ensure that the written data can be correctly stored in the system.

[0204] The above steps reflect the key operations of the non-copy data writing method in the high-performance bus protocol, including creating dependencies, judging the operation readiness, waiting for conditions to mature, executing the detection mechanism, and confirming data consistency. These steps ensure the accurate writing of data and the stability of the system.

[0205] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0206] It should be noted that, for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the described order of actions, because according to the present application, 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 and modules involved are not necessarily required by the present application.

[0207] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course, it can also be implemented by hardware. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods of each embodiment of the present application.

[0208] According to an embodiment of the present application, a data access device for implementing the above data access method is also provided. Fig.13 It is a schematic diagram of a data access device according to an embodiment of the present application. The device 1300 includes: an acquisition module 1302 , a determination module 1304 , a generation module 1306 , and a control module 1308 .

[0209] Among them, the acquisition module is used to obtain the current access status and expected access status of multiple cores in response to receiving access requests sent by multiple cores, wherein the access request is used to access the target data in the cache, and the expected access status is used to characterize the access status to be achieved by the multiple cores; the determination module is used to determine the first core whose current access status is consistent with the expected access status from the multiple cores; the generation module is used to generate a monitoring request based on the access request sent by the second core, wherein the second core is the other core among the multiple cores except the first core; the control module is used to send a monitoring request to the first core to control the first core to send the accessed target data to the second core, wherein the second core is the other core among the multiple cores except the first core.

[0210] It should be noted here that the acquisition module 1302, the determination module 1304, the generation module 1306, and the control module 1308 correspond to steps S202 to S208 in Example 1, and the four modules are the same as the instances and application scenarios implemented by the corresponding steps, but are not limited to the contents disclosed in the above-mentioned Example 1. It should be noted that the above-mentioned modules or units may be hardware components or software components stored in a memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n), and the above-mentioned modules may also be part of the device and may be run in the RISC-V system 100 provided in Example 1.

[0211] In the above embodiments of the present application, the generation module is used to allocate a monitoring request to a single sub-access request in response to an access request containing a single sub-access request; and to allocate a monitoring request to the multiple sub-access requests based on request information of the multiple sub-access requests in response to an access request containing multiple sub-access requests.

[0212] In the above embodiment of the present application, the generation module is used to obtain request information of multiple sub-access requests, wherein the request information includes at least one of the following: request type, request address and request size; based on the request information, multiple sub-access requests are merged to obtain a merged result, wherein the merged result is used to indicate the merging of sub-access results containing the same request information; based on the merged result, monitoring requests are allocated to the multiple sub-access requests.

[0213] In the above embodiments of the present application, the device further includes: a clearing module.

[0214] Among them, the clearing module is used to respond to the feedback information of the listening request received, and based on the feedback information, clear the sub-access request corresponding to the listening request in the request queue to obtain a clearing result, wherein the clearing result is used to release the cache in the request queue, and the feedback information is used to indicate that the listening request has been successfully sent to the first core.

[0215] In the above embodiment of the present application, the control module is used to determine the monitoring type based on the cache status of the target data and the expected access status of the first core, wherein the cache status is used to indicate whether multiple cores are allowed to access the target data simultaneously; and send a monitoring request corresponding to the monitoring type to the first core to control the first core to send the accessed target data to the second core.

[0216] In the above embodiment of the present application, the determination module is used to determine that the monitoring type is the first monitoring type in response to the cache status not allowing simultaneous access to the target data and the expected access status being the read status, wherein the monitoring request corresponding to the first monitoring type carries the identification information of the second core; in response to the cache status allowing simultaneous access to the target data and the expected access status being the write-back status, the monitoring type is determined to be the second monitoring type, wherein the monitoring request corresponding to the second monitoring type carries the identification information of the second core and the target permission information of the target data.

[0217] In the above embodiment of the present application, the control module is used to send a monitoring request corresponding to the first monitoring type to the first core, so as to control the first core to send the accessed target data to the second core based on the identification information.

[0218] In the above embodiment of the present application, the control module is used to send a monitoring request corresponding to the second monitoring type to the first core; control the first core to adjust the current permission information of the target data after access to the target permission information based on the monitoring request corresponding to the second monitoring type, and obtain an adjustment result; control the first core to send the target data after access to the second core based on the adjustment result.

[0219] In the above embodiments of the present application, the device further includes: a feedback module and an update module.

[0220] The feedback module is used to control the first core to feed back a data snapshot of the accessed target data to the cache; and the update module is used to update the target data in the cache based on the data snapshot.

[0221] In the above embodiments of the present application, the processor adopts a reduced instruction set computing architecture.

[0222] It should be noted that the preferred implementation scheme involved in the above embodiments of the present application is the same as the scheme provided in Example 1, as well as the application scenario and implementation process, but is not limited to the scheme provided in Example 1.

[0223] The embodiment of the present application may provide an electronic device, which may be any electronic device in a group of electronic devices. Optionally, in this embodiment, the electronic device may also be replaced by a terminal device such as a mobile terminal.

[0224] Optionally, in this embodiment, the electronic device may be located in at least one network device among a plurality of network devices of a computer network.

[0225] In this embodiment, the electronic device can execute the program code in the method.

[0226] Optionally, Fig.14 is a structural block diagram of an electronic device according to an embodiment of the present application. Fig.14 As shown, the electronic device A may include: one or more ( Fig.14 (only one is shown) processor 102, memory 104, storage controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0227] Among them, the memory can be used to store software programs and modules, such as program instructions / modules corresponding to the methods and devices in the embodiments of the present application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, that is, implementing the methods in the above embodiments. The memory may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include a memory remotely arranged relative to the processor, and these remote memories may be connected to the terminal A via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0228] The processor can call the information and application stored in the memory through the transmission device to perform the following steps: in response to receiving access requests sent by multiple cores, obtain the current access status and expected access status of the multiple cores, wherein the access request is used to access the target data in the cache, and the expected access status is used to characterize the access status to be achieved by the multiple cores; determine the first core whose current access status is consistent with the expected access status from the multiple cores; generate a monitoring request based on the access request sent by the second core, wherein the second core is the other core among the multiple cores except the first core; send a monitoring request to the first core to control the first core to send the accessed target data to the second core, wherein the second core is the other core among the multiple cores except the first core.

[0229] According to an embodiment of the present application, in response to receiving access requests sent by multiple cores, current access states and expected access states of the multiple cores are obtained, wherein the access requests are used to access target data in a cache, and the expected access states are used to characterize the access states to be achieved by the multiple cores; a first core whose current access state is consistent with the expected access state is determined from the multiple cores; a monitoring request is generated based on the access request sent by the second core, wherein the second core is a core other than the first core among the multiple cores; and a monitoring request is sent to the first core to control the first core to send the accessed target data to the second core, wherein the second core is a core other than the first core among the multiple cores, thereby improving the efficiency of data access. It is easy to notice that when multiple cores access the target data in the cache at the same time, they can first compare the current access status of the multiple cores with the expected access status to determine whether there is a first core among the multiple cores whose current access status is the same as the expected access status. The first core does not need to feedback confirmation information to the cache, reducing the communication process between the core and the cache. Monitoring information can be generated based on the access requests of other second cores that have not reached the expected access status, so as to send the monitoring information to the first core. The first core can directly send the accessed target data to the second core, reducing the step of returning the accessed target data, improving the transmission efficiency of the accessed target data, and improving the communication efficiency of the data between cores, thereby solving the technical problem of low efficiency of data access in related technologies.

[0230] Those skilled in the art will understand that Fig.14 The structure shown is for illustration only, and the electronic device may also be a smart phone (such as an Android phone, an iOS phone, etc.), a tablet computer, a PDA, a mobile Internet device (Mobile Internet Devices, MID), a PAD, and other terminal devices. Fig.14 It does not limit the structure of the above electronic device. For example, the electronic device A may also include Fig.14 More or fewer components (such as network interfaces, display devices, etc.) shown in the figure, or having Fig.14 Different configurations are shown.

[0231] A person of ordinary skill in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing the hardware related to the terminal device through a program, and the program can be stored in a computer-readable storage medium, and the storage medium may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0232] The embodiment of the present application further provides a computer-readable storage medium. Optionally, in this embodiment, the computer-readable storage medium can be used to store the program code executed by the method provided in the above embodiment.

[0233] Optionally, in this embodiment, the above storage medium may be located in any electronic device in a group of electronic devices in a computer network, or in any mobile terminal in a group of mobile terminals.

[0234] Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for performing the following steps: in response to receiving access requests sent by multiple cores, obtaining current access states and expected access states of the multiple cores, wherein the access requests are used to access target data in the cache, and the expected access states are used to characterize the access states to be achieved by the multiple cores; determining a first core from the multiple cores whose current access state is consistent with the expected access state; generating a monitoring request based on the access request sent by the second core, wherein the second core is a core other than the first core among the multiple cores; and sending a monitoring request to the first core to control the first core to send the accessed target data to the second core, wherein the second core is a core other than the first core among the multiple cores.

[0235] According to an embodiment of the present application, in response to receiving access requests sent by multiple cores, current access states and expected access states of the multiple cores are obtained, wherein the access requests are used to access target data in a cache, and the expected access states are used to characterize the access states to be achieved by the multiple cores; a first core whose current access state is consistent with the expected access state is determined from the multiple cores; a monitoring request is generated based on the access request sent by the second core, wherein the second core is a core other than the first core among the multiple cores; and a monitoring request is sent to the first core to control the first core to send the accessed target data to the second core, wherein the second core is a core other than the first core among the multiple cores, thereby improving the efficiency of data access. It is easy to notice that when multiple cores access the target data in the cache at the same time, they can first compare the current access status of the multiple cores with the expected access status to determine whether there is a first core among the multiple cores whose current access status is the same as the expected access status. The first core does not need to feedback confirmation information to the cache, reducing the communication process between the core and the cache. Monitoring information can be generated based on the access requests of other second cores that have not reached the expected access status, so as to send the monitoring information to the first core. The first core can directly send the accessed target data to the second core, reducing the step of returning the accessed target data, improving the transmission efficiency of the accessed target data, and improving the communication efficiency of the data between cores, thereby solving the technical problem of low efficiency of data access in related technologies.

[0236] The embodiment of the present application further provides a computer program product. Optionally, in this embodiment, the computer program product may include a computer program, and the computer program implements the method provided in the embodiment when executed by a processor.

[0237] The embodiments of the present application also provide a computer program product. Optionally, the computer program product may include a non-volatile computer-readable storage medium, which may be used to store a computer program, and when the computer program is executed by a processor, the method provided in the embodiments is implemented.

[0238] The embodiment of the present application further provides a computer program. Optionally, in this embodiment, when the computer program is executed by a processor, the method provided in the above embodiment is implemented.

[0239] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0240] In the above embodiments of the present application, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0241] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0242] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0243] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0244] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, server or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, disk or CD-ROM and other media that can store program codes.

[0245] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A data access method, characterized in that: Applicable to processors, including: In response to receiving access requests sent by multiple cores, obtaining current access states and expected access states of the multiple cores, wherein the access requests are used to access target data in the cache, and the expected access states are used to characterize the access states to be achieved by the multiple cores; Determine a first core from the plurality of cores whose current access state is consistent with the expected access state; Generate a monitoring request based on an access request sent by a second core, wherein the second core is another core among the plurality of cores except the first core; A monitoring request is sent to the first core to control the first core to send the accessed target data to the second core, wherein the second core is another core among the multiple cores except the first core.

2. The data access method according to claim 1, characterized in that: Generate a monitoring request based on the access request sent by the second core, including: In response to the access request comprising a single sub-access request, allocating the monitoring request to the single sub-access request; In response to the access request including a plurality of sub-access requests, the snoop request is allocated to the plurality of sub-access requests based on request information of the plurality of sub-access requests.

3. The data access method according to claim 2, characterized in that: Allocating the monitoring request to the multiple sub-access requests based on the request information of the multiple sub-access requests includes: Obtaining request information of the plurality of sub-access requests, wherein the request information includes at least one of the following: a request type, a request address, and a request size; Merging the multiple sub-access requests based on the request information to obtain a merged result, wherein the merged result is used to indicate that sub-access results containing the same request information are merged; The snoop requests are allocated to the plurality of sub-access requests based on the merging result.

4. The data access method according to claim 3, characterized in that: The method further comprises: In response to receiving feedback information of the listening request, the sub-access request corresponding to the listening request in the request queue is cleared based on the feedback information to obtain a clearing result, wherein the clearing result is used to release the cache in the request queue, and the feedback information is used to indicate that the listening request has been successfully sent to the first core.

5. The data access method according to claim 3, characterized in that: Sending a monitoring request to the first core to control the first core to send the accessed target data to the second core includes: Determining a snoop type based on a cache state of the target data and the expected access state of the first core, wherein the cache state is used to indicate whether the multiple cores are allowed to access the target data simultaneously; A monitoring request corresponding to the monitoring type is sent to the first core to control the first core to send the accessed target data to the second core.

6. The data access method according to claim 5, characterized in that: Determining a monitoring type based on the cache status and the access status includes: In response to the cache state being that simultaneous access to the target data is not allowed and the expected access state being a read state, determining that the monitoring type is a first monitoring type, wherein the monitoring request corresponding to the first monitoring type carries identification information of the second core; In response to the cache status allowing simultaneous access to the target data and the expected access status being a write-back status, the monitoring type is determined to be a second monitoring type, wherein the monitoring request corresponding to the second monitoring type carries identification information of the second core and target permission information of the target data.

7. The data access method according to claim 6, characterized in that: When it is determined that the monitoring type is the first monitoring type, sending a monitoring request corresponding to the monitoring type to the first core to control the first core to send the accessed target data to the second core includes: A monitoring request corresponding to the first monitoring type is sent to the first core to control the first core to send the accessed target data to the second core based on the identification information.

8. The data access method according to claim 6, characterized in that: When it is determined that the monitoring type is the second monitoring type, sending a monitoring request corresponding to the monitoring type to the first core to control the first core to send the accessed target data to the second core includes: Sending a monitoring request corresponding to the second monitoring type to the first core; Controlling the first core to adjust the current permission information of the accessed target data to the target permission information based on the monitoring request corresponding to the second monitoring type, and obtaining an adjustment result; The first core is controlled to send the accessed target data to the second core based on the adjustment result.

9. The data access method according to claim 1, characterized in that: The method further comprises: Controlling the first core to feed back a data snapshot of the accessed target data to the cache; The target data in the cache is updated based on the data snapshot.

10. The data access method according to claim 1, characterized in that: The processor adopts a reduced instruction set computing framework.

11. An electronic device, characterized in that: include: A memory storing an executable program; A processor, configured to run the program, wherein the program executes the method according to any one of claims 1 to 10 when running.

12. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored executable program, wherein when the executable program is executed, the device where the storage medium is located is controlled to execute the method according to any one of claims 1 to 10.

13. A computer program product, characterized in that It comprises a computer program which, when executed by a processor, implements the method according to any one of claims 1 to 10.

Images