Directory distributed data structure implementation method and system
By using a directory-based distributed data structure, distributed hash tables, and synchronizers, efficient distributed storage and operation of data are achieved in a non-cached consistent multi-core architecture. This solves the problems of scalability and low performance of traditional data structures in multi-core processors and adapts to the high-efficiency data operation requirements of non-cached consistent multi-core architectures.
Patent Information
- Application Number
- CN202511565260.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-30
- Publication Date
- 2026-01-23
AI Technical Summary
Traditional fully cached coherent architectures suffer from scalability bottlenecks and low performance in multi-core processors. Existing distributed data structures cannot effectively adapt to non-cache-coherent/partially cache-coherent multi-core architectures, resulting in high communication overhead and difficulty in achieving efficient data operations.
It adopts a directory-based distributed data structure, which divides the multi-core architecture into consistency islands, uses distributed hash tables and synchronizers to achieve cross-island communication, and combines hardware FIFO mailboxes and DMA transfer to dynamically expand the data structure, ensuring linear consistency and efficient operation.
It achieves scalability and performance improvement of data structures under a non-cached consistent multi-core architecture, reduces cross-island communication overhead, supports high-concurrency operations, and is compatible with programming models of high-level languages such as Java.
Smart Images
Figure CN121388043A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of data storage and concurrent processing, in particular to a directory-based distributed data structure implementation method and system. BACKGROUND
[0002] With the continuous growth of the number of cores of multi-core processors, the traditional full cache consistency architecture faces serious scalability bottlenecks. Cache consistency maintenance needs to synchronize memory data among a large number of cores, resulting in a dramatic increase in communication overhead. Therefore, future multi-core architectures (such as Intel Runnemede, SSC architecture, and Formic 512-core prototype machine) generally adopt non-cache consistency or partial cache consistency design. In such architectures, memory is divided into multiple "consistency islands", and cores within an island share a consistent memory view. There is no hardware cache consistency support between islands, and communication and synchronization need to be completed through explicit message passing or DMA.
[0003] Traditional concurrent data structures for full cache consistency shared memory (such as queues and stacks in the Java.util.concurrent package) cannot adapt to the above architecture characteristics. On the one hand, they do not take advantage of the local communication of the consistency island, and frequent cross-island communication leads to high latency. On the other hand, the data is not implemented in a distributed manner, making it difficult to solve the load balancing problem. Even if it is run through virtual machine transplantation, a large amount of additional overhead will be generated due to the mismatch of synchronization mechanisms, and the performance will be greatly reduced.
[0004] Existing distributed data structure solutions have limitations. Distributed transaction memory (DTM) provides synchronization abstraction, but has significant performance overhead and requires transaction-compatible code. Distributed directory protocols are mainly used for object location and are difficult to integrate to implement efficient data structure operations. Some distributed implementations (such as Hazelcast's queue and list) are limited to single-node storage or rely on underlying data storage, and cannot balance scalability and performance.
[0005] The poor scalability and low performance of traditional data structures under non-cache consistency / partial cache consistency multi-core architectures are technical problems that need to be solved. SUMMARY
[0006] The technical task of the present application is to provide a directory-based distributed data structure implementation method and system to solve the technical problems of poor scalability and low performance of traditional data structures under non-cache consistency / partial cache consistency multi-core architectures.
[0007] In a first aspect, the present application provides a directory-based distributed data structure implementation method applied to a non-cache consistency multi-core architecture, comprising the following steps:
[0008] Hardware environment configuration: divide the multi-core architecture into multiple consistent islands, each island has multiple cores, and the islands are connected through a high-speed non-loss network, and the cores are connected through two communication primitives for cross-island communication, wherein the two communication primitives are short messages based on hardware FIFO mailbox and long data blocks based on DMA;
[0009] Distributed hash table implementation: a distributed hash table DHT is constructed, which contains multiple server nodes, each server node maintains multiple hash buckets, the hash bucket adopts a linked list to solve conflicts and stores key-value pairs, for an operation request submitted by a client, a target server node and a hash bucket are located through a hash function, the operation request is sent to the FIFO mailbox of the target server node, the target server node performs an operation on the specified hash bucket based on the operation request, and returns the operation result through a message;
[0010] Directory data structure implementation: select a server node as a synchronizer, the synchronizer only maintains atomic counters related to the data structure semantics of stack, queue and double-ended queue, which are used to allocate or recycle operation keys for clients, and the clients implement the data structure operations of stack, queue and double-ended queue through the combination of two short messages and one DHT primitive, and the linearization point of all operations only depends on the time when the synchronizer returns the key value, so that global linear consistency is achieved without the need for hardware cache consistency.
[0011] Dynamic expansion: when the number of cores increases, the dynamic expansion of the data structure is realized by horizontally expanding the DHT server nodes and recalculating the hash function.
[0012] As a preferred embodiment, the islands are connected through a 3D-mesh high-speed non-loss network.
[0013] The hash bucket stores key-value pairs in a doubly linked list, and the linked list node contains key, data, prev pointer and next pointer.
[0014] As a preferred embodiment, the hash function calculation formula is:
[0015] hash(key)=(key%(NS×B)),
[0016] wherein NS represents the number of server nodes, B represents the number of hash buckets in each server node, the target server ID is obtained by integer division, and the index of the hash bucket is obtained by taking the remainder.
[0017] As a preferred embodiment, the distributed hash table is the core storage component of the directory data structure, responsible for distributed insertion, deletion and search of data, and supports the following operations:
[0018] DirInsert(key, data): the client determines the target server according to the hash function, sends a message containing <INSERT, key, data, cid>, the server locates the corresponding hash bucket, inserts <key, data> and returns ACK to the client;
[0019] DirDelete(key): the client sends a <DELETE, key, cid> message to the target server; the server searches the hash bucket, deletes and returns data if the corresponding key exists, otherwise returns ⊥;
[0020] BlockDirDelete(key): the client sends a <DELETE_BLOCK, key, cid> message; the server blocks if the key is not found, and performs deletion and returns data after the key is inserted, ensuring that the operation is finally completed;
[0021] DirSearch(key): the client sends a <SEARCH, key, cid> message; the server searches the hash bucket, returns data and ACK if the key exists, otherwise returns NACK.
[0022] As a preferred, when the directory data structure is a directory stack mode, the synchronizer manages the top key value, the distributed hash table DHT stores the stack elements, and high-concurrency Push and Pop operations are performed;
[0023] The Push operation includes the following steps:
[0024] Push operation flow:
[0025] The client calls ClientPush(cid, data) and sends a <PUSH, cid> request to the synchronizer s_s;
[0026] After the synchronizer s_s receives the request, it increments top_key by 1 and sends the new top_key to the client;
[0027] After the client receives the top_key, it calls DirInsert(top_key, data) to insert <top_key, data> into the DHT;
[0028] The DHT server returns ACK after performing the insertion, and the client confirms that the Push operation is successful;
[0029] The Pop operation includes the following steps:
[0030] The client calls ClientPop(cid) and sends a <POP, cid> request to the synchronizer s_s;
[0031] The synchronizer s_s checks the top_key. If the top_key is not equal to -1, the current top_key is sent to the client, and then the top_key is decremented by 1. If the top_key is equal to -1, -1 is sent to the client.
[0032] The client receives the top_key. If the top_key is -1, the client returns ⊥. Otherwise, the client repeatedly calls DirDelete(top_key) until the DHT returns a non-⊥ result, and finally returns the deleted data.
[0033] The linearization point of the Push operation is set as the time when the synchronizer s_s sends the top_key, and the linearization point of the Pop operation is set as the time when the synchronizer s_s sends the top_key or -1. It is proved that all concurrent operations can be equivalent to serial execution conforming to the stack logic.
[0034] Preferably, when the directory data structure is a directory queue mode, the synchronizer manages the head and tail keys, the distributed hash table DHT stores the queue elements, and the FIFO Enqueue and Dequeue operations are performed.
[0035] The Enqueue operation includes the following steps:
[0036] The client calls ClientEnqueue(cid, data) and sends a <ENQ, cid> request to the synchronizer s_s.
[0037] After receiving the request, the synchronizer s_s increments the tail_key by 1 and sends the new tail_key to the client.
[0038] The client calls DirInsert(tail_key, data) to insert <tail_key, data> into the DHT. After the DHT returns an ACK, the operation is completed.
[0039] The Dequeue operation includes the following steps:
[0040] The client calls ClientDequeue(cid) and sends a <DEQ, cid> request to the synchronizer s_s.
[0041] The synchronizer s_s checks the head_key and the tail_key. If the head_key is less than the tail_key, the current head_key is sent to the client, and then the head_key is incremented by 1. If the head_key is equal to the tail_key, an NACK is sent to the client.
[0042] The client receives the head_key, and returns if it is a NACK; otherwise, calls BlockDirDelete(head_key) to block and wait for the DHT to delete the corresponding element and returns data, and the operation is completed.
[0043] The linearization point of the Enqueue operation is set as the time when the synchronizer s_s sends the tail_key, and the linearization point of the Dequeue operation is set as the time when the synchronizer s_s sends the head_key or NACK, so as to ensure that the operations meet the FIFO order of the queue.
[0044] Preferably, when the directory data structure is a directory double-ended queue mode, the synchronizer manages bidirectional keys, the distributed hash table DHT stores elements, and the EnqueueTail, EnqueueHead, DequeueTail and DequeueHead operations are performed.
[0045] EnqueueTail: The client calls ClientEnqueue(cid, data) to send a <ENQ, cid> request to the synchronizer s_s; after receiving the request, the synchronizer s_s increments the tail_key by 1, and sends the new tail_key to the client; the client calls DirInsert(tail_key, data) to insert <tail_key, data> into the DHT, and the operation is completed after the DHT returns an ACK;
[0046] EnqueueHead: The client sends <ENQ_H, cid> to the synchronizer s_s, the synchronizer s_s sends the current head_key to the client, then decrements the head_key by 1, and the client calls DirInsert(head_key, data);
[0047] DequeueTail: The client sends <DEQ_T, cid> to s_s, and the s_s sends the current tail_key and decrements it if tail_key!= head_key; the client calls DirDelete(tail_key) until it succeeds; and if it is empty, a NACK is sent.
[0048] DequeueHead: Client invokes ClientDequeue(cid), sends <DEQ, cid> request to synchronizer s_s; synchronizer s_s checks head_key and tail_key, if head_key < tail_key, sends current head_key to client, then increments head_key by 1; if head_key = tail_key, sends NACK to client; client receives head_key, if NACK, returns ⊥; otherwise invokes BlockDirDelete(head_key), blocks waiting for DHT to delete corresponding element and returns data, operation is completed;
[0049] wherein, for each bidirectional operation, a linearization point is assigned as the time when the synchronizer returns the key value, and the operation is proved to meet the logical order of the double-ended queue.
[0050] In a second aspect, the present application is a directory distributed data structure implementation system, comprising a client, a consistency island, and a server node, and the system implements a directory data structure of a non-cache consistency multi-core architecture based on the directory distributed data structure implementation method of any one of the first aspect.
[0051] The directory distributed data structure implementation method and system have the following advantages: a directory core is constructed based on a distributed hash table (DHT), distributed storage of data across consistency islands is achieved, and load balancing is achieved; a synchronization mechanism suitable for the architecture is designed, communication overhead across islands is reduced, and the operation throughput of stacks, queues, and double-ended queues is improved; correctness of concurrent operations is ensured through linear consistency proof, and dynamic expansion is supported, and the core number growth is adapted; the concurrent programming model of high-level languages such as Java is compatible, and the application code does not need to be modified to run efficiently. BRIEF DESCRIPTION OF DRAWINGS
[0052] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.
[0053] The present application will be further described below in conjunction with the drawings.
[0054] Figure 1 The flowchart of the directory distributed data structure implementation method of embodiment 1 is shown in the figure.
[0055] Figure 2 The principle diagram of the directory distributed data structure implementation method of embodiment 1 is shown in the figure. DETAILED DESCRIPTION
[0056] The present application will be further described below in connection with the drawings and specific embodiments so that those skilled in the art can better understand and implement the present application, but the embodiments are not intended to limit the present application, and the embodiments and technical features in the embodiments can be combined with each other without conflict.
[0057] The embodiment of the present application provides a directory distributed data structure implementation method and system, which is used for solving the technical problems of poor scalability and low performance of a traditional data structure under a non-cache consistency / partial cache consistency multi-core architecture.
[0058] Embodiment 1:
[0059] The directory distributed data structure implementation method of the present application is applied to a non-cache consistency multi-core architecture, and includes four steps of hardware environment configuration, distributed hash table implementation, directory data structure implementation and dynamic expansion.
[0060] Step S100 hardware environment configuration: the multi-core architecture is divided into a plurality of consistency islands, each island has a plurality of cores, the islands are connected through a high-speed non-loss packet network, and the cores are connected through two communication primitives for cross-island communication, wherein the two communication primitives are short messages based on hardware FIFO mailbox and long data blocks based on DMA.
[0061] The islands are connected through a 3D-mesh high-speed non-loss packet network.
[0062] Step S200 distributed hash table implementation: a distributed hash table DHT is constructed, the distributed hash table DHT includes a plurality of server nodes, each server node maintains a plurality of hash buckets, the hash bucket adopts a linked list to solve conflicts and stores a key-value pair, for an operation request submitted by a client, a target server node and a hash bucket are located through a hash function, the operation request is sent to a FIFO mailbox of the target server node, the target server node operates a specified hash bucket based on the operation request, and an operation result is returned through a message.
[0063] The hash bucket stores the key-value pair <key, data> by using a double-linked list, and the linked list node includes key, data, a prev pointer and a next pointer. The hash function calculation formula is:
[0064] hash(key)=(key%(NS×B)),
[0065] Wherein, NS represents the number of server nodes, B represents the number of hash buckets in each server node, the target server ID is obtained through integer division, and the index of the hash bucket is obtained through remainder.
[0066] The distributed hash table as a core storage component of the directory data structure is responsible for distributed insertion, deletion and search of data, and supports the following operations:
[0067] (1) DirInsert (key, data): the client determines the target server according to the hash function, sends a message containing <INSERT, key, data, cid>, the server locates the corresponding hash bucket, inserts <key, data> and returns ACK to the client;
[0068] (2) DirDelete (key): the client sends <DELETE, key, cid> message to the target server; the server searches the hash bucket, deletes and returns data if the corresponding key exists, otherwise returns ⊥;
[0069] (3) BlockDirDelete (key): the client sends <DELETE_BLOCK, key, cid> message; the server is blocked if the key is not found, and executes deletion and returns data after the key is inserted, ensuring that the operation is finally completed;
[0070] (4) DirSearch (key): the client sends <SEARCH, key, cid> message; the server searches the hash bucket, returns data and ACK if the key exists, otherwise returns NACK.
[0071] Step S300: The directory data structure is implemented: a server node is selected as a synchronizer, the synchronizer only maintains atomic counters related to the data structure semantics of stack, queue and double-ended queue, which is used to allocate or recycle operation keys for clients, and the client implements the stack, queue and double-ended queue data structure operations through the combination of two short messages and one DHT primitive, and the linearization point of all operations only depends on the time when the synchronizer returns the key value, so that global linear consistency is realized without the need of hardware cache consistency.
[0072] In this embodiment, when the directory data structure is a directory stack mode, the synchronizer manages the top key value, the distributed hash table DHT stores the stack elements, and high-concurrency Push and Pop operations are performed.
[0073] The Push operation includes the following steps:
[0074] (1) The client calls ClientPush (cid, data) to send a <PUSH, cid> request to the synchronizer s_s;
[0075] (2) After receiving the request, the synchronizer s_s increments top_key by 1, and sends the new top_key to the client;
[0076] (3) The client receives the top_key, and calls DirInsert(top_key, data) to insert <top_key, data> into the DHT.
[0077] (4) The DHT server returns an ACK after performing the insertion, and the client confirms that the Push operation is successful.
[0078] The Pop operation includes the following steps:
[0079] (1) The client calls ClientPop(cid) to send a <POP, cid> request to the synchronizer s_s.
[0080] (2) The synchronizer s_s checks the top_key. If top_key!= -1, it sends the current top_key to the client, and then decrements the top_key by 1. If top_key = -1, it sends -1 to the client.
[0081] (3) The client receives the top_key. If it is -1, it returns ⊥. Otherwise, it repeatedly calls DirDelete(top_key) until the DHT returns a non-⊥ result, and finally returns the deleted data.
[0082] The linearization point of the Push operation is set as the time when the synchronizer s_s sends the top_key, and the linearization point of the Pop operation is set as the time when the synchronizer s_s sends the top_key or -1. It is proved that all concurrent operations can be equivalent to serial execution that conforms to the stack logic.
[0083] When the directory data structure is a directory queue mode, the synchronizer manages the head and tail keys, and the distributed hash table DHT stores the queue elements, and performs FIFO Enqueue and Dequeue operations.
[0084] The Enqueue operation includes the following steps:
[0085] (1) The client calls ClientEnqueue(cid, data) to send an <ENQ, cid> request to the synchronizer s_s.
[0086] (2) The synchronizer s_s receives the request, increments the tail_key by 1, and sends the new tail_key to the client.
[0087] (3) The client calls DirInsert(tail_key, data) to insert <tail_key, data> into the DHT, and the operation is completed after the DHT returns an ACK.
[0088] The Dequeue operation includes the following steps:
[0089] (1) Client invokes ClientDequeue(cid) to send <DEQ, cid> request to synchronizer s_s;
[0090] (2) Synchronizer s_s checks head_key and tail_key. If head_key < tail_key, it sends current head_key to the client and then increments head_key by 1. If head_key = tail_key, it sends NACK to the client;
[0091] (3) The client receives head_key. If it is NACK, it returns ⊥. Otherwise, it invokes BlockDirDelete(head_key) to block and wait for the DHT to delete the corresponding element and return data, and the operation is completed.
[0092] The linearization point of the Enqueue operation is set as the time when the synchronizer s_s sends tail_key, and the linearization point of the Dequeue operation is set as the time when the synchronizer s_s sends head_key or NACK, ensuring that the operations meet the FIFO order of the queue.
[0093] When the directory data structure is a directory double-ended queue mode, the synchronizer manages bidirectional keys, and the distributed hash table DHT stores elements, and executes tail insertion EnqueueTail, head insertion EnqueueHead, tail deletion DequeueTail, and head deletion DequeueHead operations.
[0094] EnqueueTail: The client invokes ClientEnqueue(cid, data) to send <ENQ, cid> request to the synchronizer s_s. After receiving the request, the synchronizer s_s increments tail_key by 1 and sends the new tail_key to the client. The client invokes DirInsert(tail_key, data) to insert <tail_key, data> into the DHT, and the DHT returns ACK after the operation is completed.
[0095] EnqueueHead: The client sends <ENQ_H, cid> to the synchronizer s_s. The synchronizer s_s sends the current head_key to the client and then decrements head_key by 1. The client invokes DirInsert(head_key, data).
[0096] DequeueTail: Client sends <DEQ_T,cid> to s_s, s_s sends current tail_key and decrements if tail_key!= head_key, Client calls DirDelete(tail_key) until success; sends NACK if empty.
[0097] DequeueHead: Client calls ClientDequeue(cid), sends <DEQ,cid> to s_s; s_s checks head_key and tail_key, if head_key < tail_key, sends current head_key to Client, then increments head_key by 1; if head_key = tail_key, sends NACK to Client; Client receives head_key, returns ⊥ if NACK; otherwise calls BlockDirDelete(head_key), blocks waiting for DHT to delete corresponding element and returns data, operation completed.
[0098] Wherein, linearization point is assigned for each bidirectional operation as the time when the synchronizer returns the key value, and the operation is proved to meet the logical order of the double-ended queue.
[0099] Step S400 dynamically expands: when the number of cores increases, the data structure is dynamically expanded by horizontally expanding the DHT server nodes and recalculating the hash function.
[0100] The core of the method of the embodiment is a "synchronizer-distributed hash table (DHT)" architecture, which coordinates operations through a synchronizer, realizes distributed storage of data through a DHT, and optimizes the operation process in combination with the communication characteristics (message passing, DMA) of the non-cache coherence architecture, as follows:
[0101] Infrastructure adaptation model: for a non-cache coherence multi-core architecture, define core adaptation rules, respectively for consistency islands and communication and data distribution principles.
[0102] Consistency island and communication: the architecture includes m consistency islands, each island contains c cores, and the islands are interconnected through high-speed communication channels; the cores support two kinds of communication: one is message passing based on hardware FIFO mailbox (`send` / `receive`, message without loss and FIFO delivery), and the other is DMA transmission (suitable for large data blocks, when the data volume exceeds the maximum message size MMS, to reduce CPU participation overhead);
[0103] Data distribution principle: data is stored in the server nodes of each consistency island through DHT distributed storage, each server manages part of the data buckets, and the client locates the target server through a hash function to avoid single node load overload.
[0104] Distributed Hash Table (DHT) is the core storage component of the directory data structure, responsible for the distributed insertion, deletion and search of data, and the specific design is as follows:
[0105] (1) Structure composition: contains NS server nodes (numbered by ID), each server maintains a number of hash buckets, and the bucket uses a hash chain (linked list) to solve hash conflicts, and stores <key, data> key-value pairs;
[0106] (2) Hash function: implemented by using modulo operation, the formula is `hash(key)=(key%(NS B))`, where B is the number of buckets of each server; the calculation result is divided by B to get the target server ID, and the remainder is obtained. Bucket index ensures uniform distribution of key values;
[0107] (3) Core operations:
[0108] DirInsert(key, data): the client determines the target server according to the hash function, and sends a message containing <INSERT, key, data, cid>; the server locates the corresponding bucket and inserts <key, data> (without duplicate keys), and returns ACK to the client;
[0109] DirDelete(key): the client sends <DELETE, key, cid> message to the target server; the server searches the bucket, and if the corresponding key exists, it deletes and returns data, otherwise it returns ⊥;
[0110] BlockDirDelete(key): the client sends <DELETE_BLOCK, key, cid> message; the server blocks if the key is not found, and executes the deletion and returns data after the key is inserted, ensuring that the operation is finally completed;
[0111] DirSearch(key): the client sends <SEARCH, key, cid> message; the server searches the bucket, and if the key exists, it returns data and ACK, otherwise it returns NACK.
[0112] In this embodiment, the directory core data structure is implemented: based on the "synchronizer + DHT" architecture, three core data structures of stack, queue and double-ended queue are implemented, and linear consistency verification is performed to ensure the correctness of concurrent operations.
[0113] The directory stack mode manages the stack top key value through a synchronizer, stores stack elements in a DHT, and implements high-concurrency Push and Pop operations. The synchronizer is designed as follows: a server is specified as a synchronizer (s_s), a top_key variable (initial value -1, indicating an empty stack) is maintained, and the s_s is responsible for assigning a unique key for Push operations and providing the stack top key for Pop operations.
[0114] Push operation flow:
[0115] (1) The client calls ClientPush(cid, data) to send a <PUSH, cid> request to the synchronizer s_s.
[0116] (2) After receiving the request, the s_s increments the top_key by 1 (e.g., from k to k+1) and sends the new top_key (k+1) to the client.
[0117] (3) After receiving the top_key, the client calls DirInsert(top_key, data) to insert <top_key, data> into the DHT.
[0118] (4) The DHT server returns an ACK after executing the insertion, and the client confirms the success of the Push operation.
[0119] Pop operation flow:
[0120] (1) The client calls ClientPop(cid) to send a <POP, cid> request to the synchronizer s_s.
[0121] (2) The s_s checks the top_key. If top_key!= -1 (the stack is not empty), it sends the current top_key to the client and then decrements the top_key by 1 (e.g., from k to k-1). If top_key = -1 (the stack is empty), it sends -1 to the client.
[0122] (3) The client receives the top_key. If it is -1, it returns ⊥ (the stack is empty). Otherwise, it repeatedly calls DirDelete(top_key) until the DHT returns a non-⊥ result (ensuring that the key has been inserted into the DHT), and finally returns the deleted data.
[0123] Linear consistency guarantee: The linearization point of the Push operation is set to the time when the s_s sends the top_key, and the linearization point of the Pop operation is set to the time when the s_s sends the top_key or -1. It is proved that all concurrent operations can be equivalent to a serial execution that conforms to the stack logic.
[0124] Directory queue pattern, through the synchronizer to manage the head and tail key values, DHT stores the queue elements, and realizes the Enqueue and Dequeue operations of FIFO. The synchronizer design: the synchronizer s_s maintains the `head_key` (the head element key, initially 0) and the `tail_key` (the tail element key, initially 0), which correspond to the dequeue and enqueue positions of the queue respectively.
[0125] Enqueue operation process:
[0126] (1) The client calls `ClientEnqueue(cid, data)` and sends an <ENQ, cid> request to s_s;
[0127] (2) After s_s receives the request, it increments the `tail_key` by 1 (for example, from t to t+1), and sends the new `tail_key` (t+1) to the client;
[0128] (3) The client calls `DirInsert(tail_key, data)` and inserts <tail_key, data> into DHT. After DHT returns ACK, the operation is completed;
[0129] Dequeue operation process:
[0130] (1) The client calls `ClientDequeue(cid)` and sends an <DEQ, cid> request to s_s;
[0131] (2) s_s checks the `head_key` and the `tail_key`. If `head_key < tail_key` (the queue is not empty), it sends the current `head_key` to the client, and then increments the `head_key` by 1 (for example, from h to h+1). If `head_key = tail_key` (the queue is empty), it sends NACK to the client;
[0132] (3) The client receives the `head_key`. If it is NACK, it returns ⊥; otherwise, it calls `BlockDirDelete(head_key)` to block and wait for DHT to delete the corresponding element and return data, and the operation is completed;
[0133] Linear consistency guarantee: the linearization point of the Enqueue operation is set as the time when s_s sends the `tail_key`, and the linearization point of the Dequeue operation is set as the time when s_s sends the `head_key` or NACK, which ensures that the operations meet the FIFO order of the queue.
[0134] Deque, extended queue design, supports bidirectional insertion and deletion of head / tail, synchronizer manages bidirectional key value, DHT stores elements. Synchronizer design: s_s maintains `head_key` (head key, initially 0) and `tail_key` (tail key, initially 0), supports negative integer key values to adapt to bidirectional operations.
[0135] Based on the method disclosed in the embodiment, a specific example is given.
[0136] Hardware environment configuration: based on Formic-Cube 512-core non-cache coherence prototype machine, which contains 64 board cards (each board card is a coherence island), each board has 8 cores (512 cores in total); each core is equipped with 8KB private L1 cache and 256KB private L2 cache (no hardware cache coherence), and the board cards are connected through 3D-mesh high-speed non-loss network (diameter 6 hops); each core has a 4KB hardware FIFO mailbox supporting message passing; the DMA engine supports burst transmission of maximum 64 bytes (cache line size), and the maximum message size MMS is set to 64 bytes.
[0137] Software implementation: distributed hash table (DHT) implementation.
[0138] Server deployment: configure 16 DHT servers (ID 0-15), each server maintains 256 buckets (B=256), and the bucket uses a doubly linked list to store <key, data> pairs, and the linked list node contains key, data, prev pointer, next pointer;
[0139] Hash function implementation: using `hash(key) = (key%(16 256)) = key%4096`, calculate the result `h`, server ID = h / 256, bucket index = h%256; for example, key = 1000, h = 1000, server ID = 1000 / 256 = 3 (integer division), bucket index = 1000%256 = 232;
[0140] Core operation code snippet (pseudo code):
[0141]
[0142]
[0143] Deque, extended queue design, supports bidirectional insertion and deletion of head / tail, synchronizer manages bidirectional key value, DHT stores elements. Synchronizer design: s_s maintains `head_key` (head key, initially 0) and `tail_key` (tail key, initially 0), supports negative integer key values to adapt to bidirectional operations.
[0144]
[0145] Client operation code snippet (pseudo code) :
[0146]
[0147]
[0148] Directory queue implementation, synchronizer deployment: same as directory stack, synchronizer s_s maintains `head_key' (initial 0) and `tail_key' (initial 0), both of which are updated using atomic operations;
[0149] Client Enqueue code snippet (pseudo code) :
[0150]
[0151]
[0152] Client Dequeue code snippet (pseudo code) :
[0153]
[0154] The method of the embodiment can be applied to the concurrent runtime environment of high-level programming languages such as Java, and provides distributed support with high scalability and high throughput for core data structures such as stacks, queues, and double-ended queues, to meet the large-scale concurrent data access requirements under a multi-core architecture.
[0155] Embodiment 2
[0156] The directory distributed data structure implementation system provided by the application, characterized in that it comprises a client, a consistency island, and a server node, and is based on the method disclosed in embodiment 1 to implement a directory data structure for a non-cache consistency multi-core architecture.
[0157] The directory distributed data structure implementation method and system provided by the application are described in detail above, and the principles and implementation modes of the application are described by applying specific examples in this paper; the above embodiment descriptions are only used to help understand the method of the application and its core idea; at the same time, for those skilled in the art, according to the idea of the application, the specific implementation modes and application ranges will be changed; in view of the above, the content of the specification should not be understood as a limitation of the application.
Claims
1. A method for implementing a directory-style distributed data structure, the method comprising: The application is applied to a non-cache consistency multi-core architecture, and comprises the following steps: Hardware environment configuration: the multi-core architecture is divided into multiple consistency islands, each island has multiple cores, the islands are connected through a high-speed non-loss network, and the cores are connected through two communication primitives for cross-island communication, wherein the two communication primitives are short messages based on hardware FIFO mailbox and long data blocks based on DMA; Distributed hash table implementation: a distributed hash table DHT is constructed, the distributed hash table DHT comprises multiple server nodes, each server node maintains multiple hash buckets, the hash bucket adopts a linked list to solve conflicts and stores a key-value pair, for an operation request submitted by a client, a target server node and a hash bucket are located through a hash function, the operation request is sent to the FIFO mailbox of the target server node, the target server node operates the specified hash bucket based on the operation request, and the operation result is returned through a message; Directory data structure implementation: a server node is selected as a synchronizer, the synchronizer only maintains atomic counters related to the data structure semantics of stacks, queues and double-ended queues, and is used for allocating or recycling operation keys for clients, the clients implement the data structure operations of stacks, queues and double-ended queues through a combination of two short messages and one DHT primitive, and the linearization point of all operations only depends on the time when the synchronizer returns the key value, so that global linear consistency is realized without the need of hardware cache consistency; Dynamic expansion: when the number of cores increases, the dynamic expansion of the data structure is realized by horizontally expanding the DHT server nodes and recalculating the hash function.
2. The catalog-based distributed data structure implementation method of claim 1, wherein, The islands are connected through a 3D-mesh high-speed non-loss network. The hash bucket stores the key-value pair <key, data> through a double-linked list, and the linked list node comprises a key, a data, a prev pointer and a next pointer.
3. The catalog-based distributed data structure implementation method of claim 1, wherein, The hash function calculation formula is: hash(key)=(key%(NS×B)), wherein NS represents the number of server nodes, B represents the number of hash buckets in each server node, the target server ID is obtained through integer division, and the index of the hash bucket is obtained through remainder.
4. The catalog-based distributed data structure implementation method of claim 1, wherein, The distributed hash table is a core storage component of the directory data structure, and is responsible for distributed insertion, deletion and search of data, and supports the following operations: DirInsert(key, data): the client determines a target server according to a hash function, and sends a message containing <INSERT, key, data, cid>; the server locates the corresponding hash bucket, inserts <key, data> and returns ACK to the client; DirDelete(key): the client sends a <DELETE, key, cid> message to the target server; the server searches the hash bucket, deletes and returns data if the corresponding key exists, or returns ⊥ otherwise; BlockDirDelete(key): the client sends a <DELETE_BLOCK, key, cid> message; the server is blocked if the key is not found, and performs deletion and returns data after the key is inserted, to ensure that the operation is finally completed; DirSearch(key): the client sends a <SEARCH, key, cid> message; the server searches the hash bucket, and returns data and ACK if the key exists, or returns NACK otherwise.
5. The catalog-based distributed data structure implementation method of claim 1, wherein, When the directory data structure is a directory stack mode, the synchronizer manages the stack top key value, and the distributed hash table DHT stores the stack elements, and performs high-concurrency Push and Pop operations. The Push operation includes the following steps: The client calls ClientPush(cid, data) to send a <PUSH, cid> request to the synchronizer s_s. After receiving the request, the synchronizer s_s increments top_key by 1 and sends the new top_key to the client. After receiving the top_key, the client calls DirInsert(top_key, data) to insert <top_key, data> into the DHT. After the DHT server performs the insertion and returns ACK, the client confirms that the Push operation is successful. The Pop operation includes the following steps: The client calls ClientPop(cid) to send a <POP, cid> request to the synchronizer s_s. The synchronizer s_s checks `top_key`, and if top_key!= -1, it sends the current top_key to the client and then decrements top_key by 1; if top_key = -1, it sends -1 to the client. After receiving the top_key, if it is -1, the client returns ⊥; otherwise, it loops and calls DirDelete(top_key) until the DHT returns a non-⊥ result, and finally returns the deleted data. The linearization point of the Push operation is set to the time when s_s sends top_key, and the linearization point of the Pop operation is set to the time when s_s sends `top_key` or -1, and it is proved that all concurrent operations can be equivalent to serial execution that conforms to the stack logic.
6. The catalog-based distributed data structure implementation method of claim 1, wherein, When the directory data structure is a directory queue mode, the synchronizer manages the queue head and tail key values, and the distributed hash table DHT stores the queue elements, and performs FIFO Enqueue and Dequeue operations. The Enqueue operation includes the following steps: The client calls ClientEnqueue(cid, data) to send an <ENQ, cid> request to the synchronizer s_s. After receiving the request, the synchronizer s_s increments tail_key by 1 and sends the new tail_key to the client. The client calls DirInsert(tail_key, data) to insert <tail_key, data> into the DHT, and the operation is completed after the DHT returns ACK. The Dequeue operation includes the following steps: The client calls ClientDequeue(cid) to send a <DEQ, cid> request to the synchronizer s_s. The synchronizer s_s checks the head_key and the tail_key. If the head_key < the tail_key, the current head_key is sent to the client, and then the head_key is incremented by 1. If the head_key = the tail_key, a NACK is sent to the client. The client receives the head_key. If it is a NACK, returns ⊥. Otherwise, calls BlockDirDelete(head_key), blocks and waits for the DHT to delete the corresponding element and returns data, and the operation is completed. The linearization point of the Enqueue operation is set as the time when the synchronizer s_s sends the tail_key, and the linearization point of the Dequeue operation is set as the time when the synchronizer s_s sends the head_key or NACK, so as to ensure that the operation meets the FIFO order of the queue.
7. The catalog-based distributed data structure implementation method of claim 1, wherein, When the directory data structure is a directory double-ended queue mode, the synchronizer manages the bidirectional key value, the distributed hash table DHT stores elements, and the operations of tail insertion EnqueueTail, head insertion EnqueueHead, tail deletion DequeueTail and head deletion DequeueHead are executed. EnqueueTail: the client calls ClientEnqueue(cid, data) and sends a <ENQ, cid> request to the synchronizer s_s. After receiving the request, the synchronizer s_s increments the tail_key by 1, sends the new tail_key to the client, and then the client calls DirInsert(tail_key, data) to insert <tail_key, data> into the DHT. After the DHT returns ACK, the operation is completed. EnqueueHead: the client sends <ENQ_H, cid> to the synchronizer s_s, the synchronizer s_s sends the current head_key to the client, then decrements the head_key by 1, and the client calls DirInsert(head_key, data). DequeueTail: the client sends <DEQ_T, cid> to s_s. If the tail_key!= head_key, the synchronizer s_s sends the current tail_key and decrements it. The client calls DirDelete(tail_key) until it succeeds. If it is empty, a NACK is sent. DequeueHead: Client invokes ClientDequeue(cid), sends <DEQ, cid> request to synchronizer s_s; synchronizer s_s checks head_key and tail_key, if head_key < tail_key, sends current head_key to client, then increments head_key by 1; if head_key = tail_key, sends NACK to client; client receives head_key, if it is NACK, returns ; otherwise invokes BlockDirDelete(head_key), blocks and waits for DHT to delete corresponding element and returns data, operation is completed; Wherein, linearization point is assigned to each bidirectional operation as the time when synchronizer returns key value, and it is proved that the operation meets the logical order of double-ended queue.
8. A system for implementing a distributed directory data structure, characterized in that, The system comprises a client, a consistency island and a server node, and is based on the directory distributed data structure implementation method of any one of claims 1-7 to implement a directory data structure of a non-cache consistency multi-core architecture.