A work queue for efficiently processing mixed transactions and its implementation method

Abstract

The present invention relates to a work queue for efficiently processing mixed transactions and an implementation method thereof. The implementation method mainly comprises: introducing a lock group structure into the work queue, the lock group structure managing the same number of locks as the number of work threads; further encapsulating the locks managed by the lock group structure into a lock management unit, and setting two pointers, one pointing to the management structure of the work thread and the other pointing to a specific task in the task queue; adjusting the management structure of the work thread so that it no longer contains a pointer to the specific task in the task queue, but only contains a pointer to the lock management unit, and all task dequeue operations are controlled by the lock management unit; introducing a window pointer into the task queue, which cooperates with the head and tail pointers of the task queue to separate tasks that the current work thread can process from tasks that cannot be processed yet. The present invention can maximize the concurrency performance of threads in a thread pool.

Description

Technical Field

[0001] The present invention relates to the field of distributed storage technology, and in particular to a work queue for efficiently processing mixed transactions and an implementation method thereof. Background Art

[0002] The distributed storage system Ceph is a unified open source distributed storage system. Due to its unified storage, it supports the provision of block storage, file storage, and object storage services. It also has the characteristics of high availability, high scalability, and high performance. Therefore, it is widely used in various fields.

[0003] In the distributed storage system Ceph, when users store data, the data will be divided into multiple objects and then stored on each disk. Due to the large number of objects, in order to facilitate the management of these objects, Ceph introduced the concept of PG (Placement Group) to group and manage these objects. Therefore, each disk in the distributed storage system Ceph contains multiple PGs. Furthermore, when the disk processes data storage tasks, it often faces multiple tasks of multiple PGs at the same time.

[0004] Because storage systems require IO (Input / Output) order preservation, multiple storage tasks under the same PG are often required to be mutually exclusive when processed by disks. Therefore, the current technical implementation of work queues, when applied to disk management in the distributed storage system Ceph, significantly limits the concurrency of work queues. This results in unstable storage performance, lower-than-expected IOPS (Input / Output Operations Per Second), and lower-than-expected bandwidth performance.

[0005] Specifically, the task model of the disk work queue of the distributed storage system Ceph has the following characteristics:

[0006] This work queue is used to process various types of tasks. In the distributed storage system Ceph, each type corresponds to a specific PG;

[0007] When dequeuing, the working thread of the work queue, in addition to executing the dequeue operation, needs to perform a series of operations to release the thread and then execute the dequeue of the next task. These operations of tasks of the same type are mutually exclusive. That is, when a working thread dequeues a task, another dequeue thread dequeues a task of the same type and needs to wait for the previous task to be completed before it can perform the operation and then execute the dequeue of the next task.

[0008] Suppose there is a work queue that contains two work threads. The task model processed by the work queue has the above characteristics, and the task sequence contained in the queue is: [Class A transaction 1, Class A transaction 2, Class B transaction 3, Class C transaction 4, Class D transaction 1].

[0009] According to the work queue implemented by the existing technical solution, when processing the above scenario, work thread 1 dequeues to process Class A transaction 1, and work thread 2 dequeues to process Class A transaction 2. Since Class A transaction 1 and Class A transaction 2 are mutually exclusive, work thread 2 needs to wait for the completion of the task of work thread 1 before it can process it and then process the next task. It is obvious that the concurrency of the work queue is severely restricted; if the task sequence contained in the work queue is: [Class A transaction 1, Class A transaction 2, Class A transaction 3, Class A transaction 4, Class B transaction 1, Class B transaction 2, Class B transaction 3...], its dual concurrent work efficiency will even degenerate into a near-serial work efficiency, and its concurrent work efficiency will be greatly affected. In the above example, the same type is mutually exclusive, and different tasks of the same type are mutually exclusive when processing. This mutually exclusive relationship is a characteristic of the business corresponding to the application scenario of the present invention.

[0010] Therefore, it is necessary to design a new work queue based on the work queue of the above task model to improve efficiency and avoid the work queue becoming a performance bottleneck of the entire system, which will affect system performance.

[0011] In view of this, how to overcome the defects of the existing technology and solve the above technical problems is a difficult problem to be solved in this technical field. Summary of the Invention

[0012] The present invention addresses the defects or improvement needs in the prior art. The present invention provides a work queue and implementation method for efficiently processing mixed transactions, wherein "mixed" means that the task types are diverse, and tasks of the same type are mutually exclusive when being processed. The purpose of the present invention is to improve the dequeue efficiency of the work queue when managing tasks with the above characteristics, and give full play to its concurrency performance. It should be noted that the core idea of ​​the present invention is that different tasks of the same type within a period of time are only handed over to one thread under the thread pool for processing.

[0013] The embodiment of the present invention adopts the following technical solutions:

[0014] In a first aspect, the present invention provides a method for implementing a work queue for efficiently processing mixed transactions, comprising:

[0015] A lock group structure is introduced on the work queue. The lock group structure manages the same number of locks as the number of worker threads. Each lock corresponds to a task type, thus achieving mutually exclusive access control for different types of tasks.

[0016] The locks managed by the lock group structure are further encapsulated into a lock management unit, and two pointers are set, one pointer points to the management structure of the working thread, and the other pointer points to the specific task in the task queue;

[0017] Adjust the management structure of the worker thread so that it no longer contains pointers to specific tasks in the task queue, but only contains pointers to the lock management unit. All task dequeue operations are controlled by the lock management unit instead of the task queue.

[0018] Introducing a window pointer on the task queue, combined with the head and tail pointers of the task queue, separates the tasks that the current working thread can process from the tasks that cannot be processed yet.

[0019] Furthermore, the work queue includes a task queue, a thread pool, and a lock group structure, specifically:

[0020] The task queue is a storage structure for tasks, wherein each task is represented by a task management unit. The task queue includes a head pointer, a tail pointer, and a win pointer. The head pointer is used to point to the head node of the task queue, which does not store any task management unit. The tail pointer is used to point to the last task management unit in the task queue, and the win pointer represents the window pointer.

[0021] The thread pool is a storage structure of worker threads, wherein each worker thread is represented by a thread management unit, and the thread management unit includes a lock_point pointer, wherein the lock_point pointer points to the lock management unit assigned to the worker thread by the lock group structure;

[0022] The lock group structure is a storage structure of locks, in which each lock is represented by a lock management unit. The lock management unit includes a task_point pointer, a process_point pointer and a task_type attribute. The task_point pointer is used to point to a task management unit in the task queue, the process_point pointer is used to point to the thread management unit to which it is assigned, and the task_type attribute is used to record the task type associated with the lock management unit; the lock group structure includes an allocate_lock_list linked list and a free_lock_list linked list. The allocate_lock_list linked list is used to manage allocated lock management units, and the free_lock_list linked list is used to manage unallocated lock management units.

[0023] Furthermore, the execution unit of the work queue is the thread management unit in the thread pool, where the workflow of the work thread includes:

[0024] Lock management unit allocation step: Check whether the lock management unit is allocated. If the lock management unit is not allocated, apply to the lock group structure for allocation of the lock management unit. If the lock group structure successfully allocates the lock management unit, modify the lock_point pointer of the thread management unit to point to the allocated lock management unit, and then enter the task allocation step; if the lock group structure fails to allocate the lock management unit, re-enter the lock management unit allocation step; if the lock management unit has been allocated, enter the task allocation step;

[0025] Task allocation step: initiate a task allocation request to the lock management unit pointed to by the lock_point pointer of the thread management unit. If the task is obtained, that is, the task allocation is successful, then enter the task processing step. If the task is not obtained, that is, the task allocation fails, then enter the lock release step;

[0026] Task processing step: Process the acquired tasks and enter the lock management unit allocation step after the processing is completed;

[0027] Release lock step: initiate a lock release request to the lock management unit pointed to by the lock_point pointer of the thread management unit. If the lock management unit completes the release, enter the pointer update step, otherwise enter the lock management unit allocation step;

[0028] Pointer update step: modify the lock_point pointer of this thread management unit to be empty, and then enter the lock management unit allocation step.

[0029] Furthermore, the workflow of the lock group structure allocating the lock management unit includes:

[0030] Allocation step: Check whether the free_lock_list linked list is empty. If it is empty, return allocation failure. If it is not empty, obtain the first lock management unit in the free_lock_list linked list and record it as first_free_lock_unit, and enter the pre-allocation step. If the pre-allocation is successful, the allocation is successful, and the lock management unit pointed to by first_free_lock_unit is returned, otherwise, the allocation fails; among them, first_free_lock_unit is used to temporarily store an idle lock management unit obtained from the free_lock_list linked list, which is applied when the lock management unit allocation process starts and is released after the lock management unit allocation process ends.

[0031] Pre-allocation step: Execute the window redefinition step. If the execution fails, it returns a pre-allocation failure. If the execution succeeds, it executes the lock allocation step and the window expansion step in sequence, and returns the first_free_lock_unit returned by the lock allocation step.

[0032] Window redefinition steps: Move the win pointer until the win pointer and the tail pointer point to the same point or the win pointer points to a task management unit whose task_type is different from the task_type of any lock management unit in the allocate_lock_list list. If the win pointer and the tail pointer point to the same point and the tail pointer points to a task management unit whose task_type is the same as the task_type of a lock management unit in the allocate_lock_list list, the window redefinition fails. Otherwise, the window redefinition succeeds.

[0033] Lock allocation steps: modify the task_point pointer of first_free_lock_unit to point to the same pointer as win, and modify the task_type of first_free_lock_unit to the task_type of the task management unit pointed to by win pointer, modify the process_point pointer of first_free_lock_unit to the address of the thread unit that applies for the lock management unit, then remove first_free_lock_unit from the free_lock_list linked list and add it to the allocate_lock_list linked list, and return first_free_lock_unit, indicating that the lock allocation is successful;

[0034] Window expansion step: perform window expansion.

[0035] Furthermore, the workflow of releasing the lock management unit of the lock group structure includes:

[0036] Modify the task_point, task_type and process_point of the lock management unit to empty, remove the lock management unit from the allocate_lock_list linked list, and add it to the free_lock_list linked list for processing, and return a successful release.

[0037] Furthermore, the workflow of the lock management unit assigning tasks includes:

[0038] Pointer checking step: Check whether the task_point pointer of the lock management unit points to the address of the task queue win pointer. If so, enter the edge task allocation step; if not, enter the general task allocation step;

[0039] General task allocation steps: record the task management unit pointed to by the task_point pointer in tmp_task_unit, and at the same time point task_point to the next task management unit of the task management unit corresponding to tmp_task_unit, remove the task management unit corresponding to tmp_task_unit from the task queue, and enter the task_point pointer moving step, where tmp_task_unit is a temporary variable used to temporarily store the task to be allocated. It is defined when the process of allocating tasks by the lock management unit is started and is released after the process is completed;

[0040] Task_point pointer moving steps: By moving the task_point pointer, traverse all task management units between the task_point pointer and the task queue win pointer until the task type of the traversed task management unit is the same as the task_type of the lock management unit or the task_point pointer and the task queue win pointer point to the same point, then return tmp_task_unit, indicating that the task allocation is successful. If the task_point pointer and the task queue win pointer point to the same point before returning, then set task_point to the address of the win pointer;

[0041] Edge task allocation step: execute the window extension step, check whether the task_point pointer points to the address of the win pointer, if not, enter the pointer checking step, if so, check whether the task_type of the task management unit pointed to by the win pointer is the same as the task_type of the lock management unit, if they are the same, record the task management unit pointed to by the win pointer in tmp_task_unit, and modify the win pointer to point to the previous task management unit of tmp_task_unit, and return tmp_task_unit, indicating that the task allocation is successful. If they are not the same, return task allocation failure.

[0042] Furthermore, the window expansion step includes:

[0043] Win pointer determination step: determine whether the win pointer points to the same direction as the tail pointer. If so, proceed to the lock management unit pointer correction step and then end the window expansion step. Otherwise, proceed to the win pointer movement step.

[0044] Win pointer moving step: obtain the next task management unit of the win pointer, check whether there is a lock management unit with the same task_type as the task management unit in allocate_lock_list, if so, record the lock management unit as tmp_lock, if the task_type of the task management unit pointed to by the task_point of tmp_lock is different from the task_type corresponding to tmp_lock, modify the task_point pointer of tmp_lock to point to the task management unit pointed to by the win pointer, otherwise do not modify it, then the win pointer points to the next task management unit, and then re-enter the win pointer judgment step; if not, enter the lock management unit pointer correction step, and then end the window expansion step;

[0045] Lock management unit pointer correction steps: traverse the lock management units in allocate_lock_list, check whether there is a lock management unit whose corresponding task_type is different from the task_type of the task management unit pointed to by its task_point, or a lock management unit whose task_point points to the same point as the win pointer. If so, and the task_point of the lock management unit does not point to the address of the win pointer, then point the task_point pointer of the lock management unit to the address of the win pointer.

[0046] Furthermore, for the task queue, the task management units between its head pointer and win pointer represent the assigned task management units, which are about to be processed by the working threads; the task management units between its win pointer and tail pointer represent the task management units that have not yet been assigned, which will be processed by the working threads in the thread pool only after they are assigned.

[0047] Furthermore, for the thread management unit, when no lock is allocated, its lock_point is empty; for the lock group structure, the lock group structure initializes a corresponding number of lock management units according to the number of locks contained in the user-defined lock group during initialization, and manages these lock management units through the free_lock_list linked list.

[0048] On the other hand, the present invention provides a work queue for efficiently processing mixed transactions, including a task queue, a thread pool, and a lock group structure. Specifically:

[0049] The task queue is a storage structure for tasks, wherein each task is represented by a task management unit. The task queue includes a head pointer, a tail pointer, and a win pointer. The head pointer is used to point to the head node of the task queue, which does not store any task management unit. The tail pointer is used to point to the last task management unit in the task queue, and the win pointer represents the window pointer.

[0050] The thread pool is a storage structure of worker threads, wherein each worker thread is represented by a thread management unit, and the thread management unit includes a lock_point pointer, wherein the lock_point pointer points to the lock management unit assigned to the worker thread by the lock group structure;

[0051] The lock group structure is a storage structure of locks, in which each lock is represented by a lock management unit. The lock management unit includes a task_point pointer, a process_point pointer and a task_type attribute. The task_point pointer is used to point to a task management unit in the task queue, the process_point pointer is used to point to the thread management unit to which it is assigned, and the task_type attribute is used to record the task type associated with the lock management unit; the lock group structure includes an allocate_lock_list linked list and a free_lock_list linked list. The allocate_lock_list linked list is used to manage allocated lock management units, and the free_lock_list linked list is used to manage unallocated lock management units.

[0052] Compared with the existing technology, the beneficial effects of the present invention are: realizing the binding of working threads with specific types of tasks, and at the same time realizing the effect that a thread can only process tasks of the same type in a certain time period, thereby maximizing the concurrency performance of threads in the thread pool.

[0053] The present invention retains the versatility of existing work queues, and at the same time has similar performance when processing tasks that do not have the said "mixed" characteristics; when processing tasks with the said "mixed" characteristics, the performance of the present invention is significantly better than that of existing work queues. If the work queue contains n work threads, in extreme scenarios, the present invention can improve the performance by n times compared with the existing work queue. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] To more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments of the present invention. Obviously, the drawings described below are only some embodiments of the present invention. Those skilled in the art can also derive other drawings based on these drawings without inventive effort.

[0055] Figure 1 A schematic diagram of a work queue for efficiently processing mixed transactions provided by Example 1 of the present invention;

[0056] Figure 2 A schematic diagram of the workflow of a work thread provided in Example 1 of the present invention;

[0057] Figure 3 A schematic diagram of the workflow of allocating a lock management unit to a lock group structure provided in Example 1 of the present invention;

[0058] Figure 4 A schematic diagram of the workflow of the lock management unit allocating tasks provided in Example 1 of the present invention;

[0059] Figure 5 A timeline comparison diagram of the conventional solution provided in Example 1 of the present invention and the solution of the present invention;

[0060] Figure 6 A flowchart of a method for implementing a work queue for efficiently processing mixed transactions provided in Example 2 of the present invention;

[0061] Figure 7 This is a schematic diagram of the device architecture provided in Example 3 of the present invention. DETAILED DESCRIPTION

[0062] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0063] The present invention is an architecture of a specific functional system. Therefore, the specific embodiments mainly illustrate the functional logical relationship between the various structural modules, and do not limit the specific software and hardware implementation methods.

[0064] In addition, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other, and the order of the steps can be swapped if they are logical and do not conflict. The present invention will be described in detail below with reference to the accompanying drawings and embodiments.

[0065] Example 1:

[0066] like Figure 1As shown, embodiment 1 of the present invention provides a work queue for efficiently processing mixed transactions. The work queue mainly includes three structural units, namely, a task queue, a thread pool, and a lock group structure (the lock group structure corresponds to Figure 1 Middle lock group), specifically:

[0067] The task queue is a storage structure for tasks, in which each task is represented by a task management unit, and the task queue includes a head pointer, a tail pointer, and a win pointer. It should be noted that the task management unit includes a next pointer to point to the next task management unit in the queue. If the task management unit is the last one in the queue, the next pointer is empty. It should be noted that the linked list structure needs to connect the task management units through the next pointer. "If the task management unit is the last one in the queue, the next pointer is empty" describes the characteristics of the tail node of the linked list. For the task queue, its head pointer is used to point to the head node of the task queue, which does not store any task management unit; its tail pointer is used to point to the last task management unit in the task queue; its win pointer represents the window pointer; the task management units between the head pointer and the win pointer represent the assigned task management units, which are about to be processed by the working thread; the task management units between the win pointer and the tail pointer represent the task management units that have not yet been assigned. These task management units will be processed by the working thread in the thread pool only after they are assigned. It should be noted that the entire work queue is divided into two parts through the win pointer: (1) the front part is between the head and win pointers (including the current win pointer); (2) the back part is between the win and tail pointers (excluding the current win pointer). We call (1) the window. The tasks in the window are the tasks that have been assigned to the working thread to process or will be processed; the tasks in (2) are the tasks that have not yet been assigned to a thread.

[0068] The thread pool is a storage structure for worker threads, where each worker thread is represented by a thread management unit (TMU), which is the execution unit for tasks in the task queue. In addition to the thread itself, the thread management unit also contains a lock_point pointer, which points to the lock management unit assigned to the worker thread by the lock group structure. When no lock is assigned, the lock_point is null.

[0069] The lock group structure is a storage structure for locks, in which each lock is represented by a lock management unit. In addition to the lock itself, the lock management unit also includes a task_point pointer, a process_point pointer, and a task_type attribute. For the lock management unit, its task_point pointer is used to point to a task management unit in the task queue; its process_point pointer is used to point to the thread management unit to which it is assigned; and its task_type attribute is used to record the task type associated with the lock management unit. In addition, for the lock group structure, the lock group structure also includes an allocate_lock_list linked list and a free_lock_list linked list. The allocate_lock_list linked list is used to manage allocated lock management units, and the free_lock_list linked list is used to manage unallocated lock management units. When the lock group structure is initialized, the corresponding number of lock management units is initialized according to the number of locks contained in the user-defined lock group, and these lock management units are managed through the free_lock_list linked list.

[0070] like Figure 2 As shown, in one implementation of this preferred embodiment, the execution unit of the work queue is a thread management unit in the thread pool, wherein the workflow of the work thread includes:

[0071] Step 101: Lock management unit allocation step: Check whether the lock management unit is allocated (whether lock_point is empty). If the lock management unit is not allocated, apply to the lock group structure for allocation of the lock management unit. If the lock group structure successfully allocates the lock management unit, modify the lock_point pointer of the current thread management unit to point to the allocated lock management unit, and then enter the task allocation step; if the lock group structure fails to allocate the lock management unit, re-enter the lock management unit allocation step; if the lock management unit has been allocated, enter the task allocation step.

[0072] Step 102: Task allocation step: initiate a task allocation request to the lock management unit pointed to by the lock_point pointer of this thread management unit. If the task is obtained, that is, the task allocation is successful, then enter the task processing step. If the task is not obtained, that is, the task allocation fails, then enter the lock release step.

[0073] Step 103: Task processing step: Process the acquired task, and after the processing is completed, enter the lock management unit allocation step.

[0074] Step 104: Lock Release Step: A lock release request is initiated to the lock management unit pointed to by the lock_point pointer of the thread management unit. If the lock management unit completes the lock release, the pointer update step is entered; otherwise, the lock management unit allocation step is entered. It should be noted that unlike traditional work queues, which release locks after the work is completed, the lock management unit of the work queue of the present invention only releases the lock when the lock management unit cannot allocate a task; this is also a feature of the present invention.

[0075] Step 105: Pointer update step: modify the lock_point pointer of the thread management unit to be empty, and then enter the lock management unit allocation step.

[0076] It should be noted that in the above process, step 103 enters step 101 in order to execute step 102, that is, task allocation. Step 104 enters step 101, mainly to go through steps 101 to 104 again after the lock management unit fails to be released. Steps 101 to 103 determine again whether the lock management unit is to be released, and step 104 attempts to release the lock management unit again. Step 105 enters step 101, mainly to apply for a new lock management unit (the new lock management unit will be re-associated with the task type). This is not a timed wait, and steps 101 to 105 can be understood as a while infinite loop, and this while infinite loop is the work function of the thread.

[0077] like Figure 3 As shown, in one implementation of this preferred embodiment, the workflow of the lock group structure allocating the lock management unit includes:

[0078] Step 201: Allocation step: Check whether the free_lock_list linked list is empty. If it is empty, return allocation failure. If it is not empty, obtain the first lock management unit in the free_lock_list linked list and record it as first_free_lock_unit, and enter the pre-allocation step. If the pre-allocation is successful, the allocation is successful, and the lock management unit pointed to by first_free_lock_unit is returned. Otherwise, the allocation fails. Among them, first_free_lock_unit is used to temporarily store an idle lock management unit obtained from the free_lock_list linked list, which is applied when the lock management unit allocation process starts and is released after the lock management unit allocation process ends.

[0079] Step 202: Pre-allocation step: execute the window redefinition step. If the execution fails, the pre-allocation failure is returned. If the execution succeeds, the lock allocation step and the window expansion step are executed sequentially, and the first_free_lock_unit returned by the lock allocation step is returned.

[0080] Step 203: Window redefinition step: Move the win pointer until the win pointer and the tail pointer point to the same point or the win pointer points to a task management unit whose task_type is different from the task_type of any lock management unit in the allocate_lock_list list. If the win pointer and the tail pointer point to the same point and the tail pointer points to a task management unit whose task_type is the same as the task_type of any lock management unit in the allocate_lock_list list, the window redefinition fails. Otherwise, the window redefinition succeeds. In this step, when moving the win pointer, it moves in the direction of the tail pointer; the purpose is to split the work queue into two parts: allocated and unallocated by redefining the position of win. It should be noted that the window redefinition step is to explore a new task type in the work queue. The new task type must be a task management unit between the win pointer and the tail pointer of the work queue. Therefore, the movement of the win pointer should be in the direction of the tail pointer, that is, to the right.

[0081] Step 204: Lock allocation step: modify the task_point pointer of first_free_lock_unit to point to the same point as the win pointer, and modify the task_type of first_free_lock_unit to the task_type of the task management unit pointed to by the win pointer, modify the process_point pointer of first_free_lock_unit to the address of the thread unit that applies for the lock management unit, then remove first_free_lock_unit from the free_lock_list linked list and add it to the allocate_lock_list linked list, and return first_free_lock_unit, indicating that the lock allocation is successful.

[0082] Step 205: Window Expansion Step: Execute window expansion. It should be noted that during the window expansion step, the win pointer also moves toward the tail pointer. This is to check whether there are any unassigned tasks in the unassigned portion of the work queue that can be assigned. If so, the win pointer is moved to classify these tasks as assigned (i.e., assigned to a thread for processing). These tasks are defined as tasks between the head and win pointers.

[0083] In one implementation of this preferred embodiment, the workflow of the lock group structure releasing the lock management unit includes: modifying the task_point, task_type and process_point of the lock management unit to empty, removing the lock management unit from the allocate_lock_list linked list, and adding it to the free_lock_list linked list for processing, and returning a successful release.

[0084] like Figure 4 As shown, in one implementation of this preferred embodiment, the workflow of the lock management unit assigning tasks includes:

[0085] Step 301: Pointer checking step: Check whether the task_point pointer of the lock management unit points to the address of the task queue win pointer. If yes, enter the edge task allocation step; if not, enter the general task allocation step.

[0086] Step 302: General task allocation step: record the task management unit pointed to by the task_point pointer in tmp_task_unit, and at the same time point task_point to the next task management unit of the task management unit corresponding to tmp_task_unit, remove the task management unit corresponding to tmp_task_unit from the task queue, and enter the task_point pointer moving step, where tmp_task_unit is a temporary variable used to temporarily store the tasks to be allocated. It is defined when the process of allocating tasks by the lock management unit is started and is released after the process is completed.

[0087] Step 303: task_point pointer moving step: By moving the task_point pointer, traverse all task management units between the task_point pointer and the task queue win pointer until the task type of the traversed task management unit is the same as the task_type of the lock management unit or the task_point pointer and the task queue win pointer point to the same point, then return tmp_task_unit, indicating that the task allocation is successful. If the task_point pointer and the task queue win pointer point to the same point before returning, then point task_point to the address of the win pointer.

[0088] Step 304: Edge task allocation step: execute the window expansion step, check whether the task_point pointer points to the address of the win pointer, if not, enter the pointer checking step, if so, check whether the task_type of the task management unit pointed to by the win pointer is the same as the task_type of the lock management unit, if they are the same, record the task management unit pointed to by the win pointer in tmp_task_unit, and modify the win pointer to point to the previous task management unit of tmp_task_unit, return tmp_task_unit, indicating that the task allocation is successful, if they are not the same, return task allocation failure.

[0089] It should be noted that the window expansion step in step 205 is actually a reused step, and the window expansion step is also performed in step 304. Specifically, in one implementation of this preferred embodiment, the window expansion step includes:

[0090] Win pointer judgment step: judge whether the win pointer points to the same point as the tail pointer. If so, perform the lock management unit pointer correction step and then end the window expansion step. Otherwise, enter the win pointer movement step.

[0091] Win pointer moving step: obtain the next task management unit of the win pointer, check whether there is a lock management unit in allocate_lock_list whose task_type is the same as the task_type of the task management unit, if so, record the lock management unit as tmp_lock, if the task_type of the task management unit pointed to by the task_point of tmp_lock is different from the task_type corresponding to tmp_lock, modify the task_point pointer of tmp_lock to point to the task management unit pointed to by the win pointer, otherwise do not modify it, and then the win pointer points to the next task management unit, and then re-enter the win pointer judgment step; if not, enter the lock management unit pointer correction step, and then end the window expansion step.

[0092] Lock management unit pointer correction steps: traverse the lock management units in allocate_lock_list, check whether there is a lock management unit whose corresponding task_type is different from the task_type of the task management unit pointed to by its task_point, or a lock management unit whose task_point points to the same point as the win pointer. If so, and the task_point of the lock management unit does not point to the address of the win pointer, then point the task_point pointer of the lock management unit to the address of the win pointer.

[0093] The above is a detailed description of each process of the work queue in this embodiment. For the above processes, the working process of this embodiment is described in detail with examples through various scenarios.

[0094] First, the initialization scene is as follows:

[0095] Assume that the sequence of work queues is as follows: head:[A,D,E,B,C,B,E], where ABCDE represent different types. The above queue has seven tasks;

[0096] For ease of description, we record the work queue as an array TaskArray; the seven tasks are represented as TaskArray[0], TaskArray[1], ..., TaskArray[6]; it should be noted that the meaning of the array TaskArray is that TaskArray[0] corresponds to the first task element in the task queue, TaskArray[1] corresponds to the second task element in the task queue, and so on. When a task is removed from the task queue, the TaskArrays corresponding to the other tasks will change accordingly, starting from the first task and corresponding to TaskArray[0], TaskArray[1], ..., in sequence. For example, after A is removed from the queue, D corresponds to TaskArray[0], E corresponds to TaskArray[1], and so on. It should also be noted that the array here is only for the convenience of describing the relative position of the task management unit in the work queue. Although the relative position of the task management unit in the work queue will change as the task is removed from the queue, its storage address remains unchanged. That is, the original task management unit corresponds to TaskArray[3]. After the task is removed from the queue, the task management unit corresponds to TaskArray[2]. However, the address of the task management unit before and after removal remains unchanged, that is, &TaskArray[3] = &TaskArray[2], where & represents the address.

[0097] In order to facilitate the management of the work queue, we set a head node to represent the work queue. The head pointer of the head node points to a task management unit, but all the attribute values ​​of the task management are empty; at this time, the tail pointer of the work queue points to the last task in the queue, namely TaskArray[6].

[0098] The lock group LockList of the work queue contains four lock management units, which are recorded as Lock1, Lock2, Lock3, and Lock4 respectively;

[0099] The thread pool contains 4 threads, which are recorded as thread1, thread2, thread3, and thread4 respectively;

[0100] Lock1 is bound to task type A and assigned to thread1;

[0101] Lock2 is bound to task type D and assigned to thread2;

[0102] Lock3 is bound to task type E and assigned to thread3;

[0103] Lock4 is bound to task type B and assigned to thread4;

[0104] Take Lock1 as an example (each lock management unit contains a task_point pointer, a process_point pointer, and a task_type attribute). That is, at this time, Lock1.task_type = A, the value of Lock1.process_point is the address of the thread management unit corresponding to thread1, and the value of thread1.lock_point is the address of Lock1. Through the above values, the lock management unit is bound to a specific task type on the one hand, and the lock management unit is bound to the thread at the same time;

[0105] Lock1.task_point = &TaskArray[0], indicating that the next task assigned to Lock1 is TaskArray[0];

[0106] Lock2.task_point = &TaskArray[1], indicating that the next task assigned to Lock2 is TaskArray[1];

[0107] Lock3.task_point = &TaskArray[2], indicating that the next task assigned to Lock3 is TaskArray[2];

[0108] Lock4.task_point = &TaskArray[3], indicating that the next task assigned to Lock4 is TaskArray[3];

[0109] Since the task_type of TaskArray[4] is C, which is different from the task type of any lock management unit in LockList, the win pointer of the work queue points to TaskArray[3], indicating that TaskArray[0] to TaskArray[3] have been allocated and will be processed;

[0110] Since Lock4.task_point and win pointer have the same pointer, in the window expansion step, Lock4.task_point will be pointed to the address of win pointer, that is, Lock4.task_point = &win;

[0111] At this time, the two queues of the lock group, free_lock_list and allocate_lock_list, are:

[0112] free_lock_list = [];

[0113] allocate_lock_list=[Lock1,Lock2,Lock3,Lock4].

[0114] Operation process description:

[0115] Scenario 1: Thread 1 completes its task and enters the task allocation process, requesting the next task from its lock management unit Lock1.

[0116] First, a pointer check step is performed, that is, whether the task_point pointer of the lock management unit points to the address of the task queue win pointer. If so, the edge task allocation step is entered. If not, the general task allocation step is entered; because Lock1.task_point = TaskArray[0] does not point to win (i.e. Lock1.task_point! = &win), the general task allocation step is entered;

[0117] For the general task allocation step: record the task management unit pointed to by the task_point pointer in tmp_task_unit, and at the same time point task_point to the next task management unit of the task management unit corresponding to tmp_task_unit, remove the task management unit corresponding to tmp_task_unit from the task queue, and enter the task_point pointer movement step. In other words, remove task A originally corresponding to Lock1 from the task queue, and then enter the task_point pointer movement step. After the general task allocation step is completed, the work queue and its pointer status are as follows:

[0118] head:[D,E,B,C,B,E]; At this time, D corresponds to TaskArray[0], the first E corresponds to TaskArray[1], the first B corresponds to TaskArray[2], C corresponds to TaskArray[3], the second B corresponds to TaskArray[4], and the second E corresponds to TaskArray[5]. win points to the first B, which is TaskArray[2].

[0119] For the task_point pointer movement step: by moving the task_point pointer, traverse all task management units between the task_point pointer and the task queue win pointer until the task type of the traversed task management unit is the same as the task_type of the lock management unit or the task_point pointer and the task queue win pointer point to the same point. Then return tmp_task_unit, indicating that the task allocation is successful. If the task_point pointer and the task queue win pointer point to the same point before returning, then point task_point to the address of the win pointer. Because Lock1.task_type = A, which is different from the task_type of D, E, and B, Lock1.task_type is moved to the same point as the task queue win pointer, that is, TaskArray[2], the first B, and then Lock1.task_type points to the address of the win pointer. At this time, Lock1.task_point finally points to the first B, that is, TaskArray[2], which is the same as win points to (Lock1.task_point=win=&TaskArray[2]), so Lock1.task_point=&win.

[0120] It should be noted that this scenario only illustrates the first round of allocation process and pointer changes of Lock1 after Task A is completed. At this time, Lock1.task_point and Lock4.task_point both point to the same as win, that is, to the first B (TaskArray[2]). Because Lock1's task type (task_type) is A, which is different from B, Lock1 at this moment actually needs to perform other steps when applying for the next task. The specific process can be referred to in Scenario 3, so it will not be repeated here.

[0121] Scenario 2: Thread 4 completes its task and enters the task allocation process, requesting the next task from its lock management unit Lock4.

[0122] First, a pointer check step is performed, that is, checking whether the task_point pointer of the lock management unit points to the address of the task queue win pointer. If so, the edge task allocation step is entered. If not, the general task allocation step is entered. Because Lock4.task_point points to win, that is, Lock4.task_point = &win, the edge task allocation step is entered.

[0123] When performing the edge task allocation step, the window expansion step is performed first, and the win pointer judgment step is performed first to determine whether the win pointer points to the same point as the tail pointer. Because the win pointer and the tail pointer do not point to the same point, the win pointer movement step is entered. For the win pointer movement step: obtain the task management unit after the win pointer, check whether there is a lock management unit in the allocate_lock_list with the same task_type as the task management unit's task_type. If so, record the lock management unit as tmp_lock. If the task_type of the task management unit pointed to by the task_point of tmp_lock is different from the task_type corresponding to tmp_lock, modify the task_point pointer of tmp_lock to point to the task management unit pointed to by the win pointer. Otherwise, do not modify it, and then the win pointer points to the next task management unit, and then re-enter the win pointer judgment step; if not, enter the lock management unit pointer correction step, and then end the window expansion step. Since the task type of TaskArray[3] is C, and the task types of Lock1, Lock2, Lock3, and Lock4 are A, D, E, and B at this time, the lock management unit pointer correction step is entered: traverse the lock management units in allocate_lock_list and check whether there is a lock management unit whose corresponding task_type is different from the task_type of the task management unit pointed to by its task_point, or a lock management unit whose task_point points to the same address as the win pointer. If so, and the task_point of the lock management unit does not point to the address of the win pointer, then point the task_point pointer of the lock management unit to the address of the win pointer.Since Lock1.task_point = &win, Lock2.task_point = &TaskArray[0], Lock3.task_point = &TaskArray[1], Lock4.task_point = &win, the task_point of Lock1, Lock2, Lock3, and Lock4 are not equal to win, that is, the task_point of no lock management unit points to the same point as win, and the task type D of TaskArray[0] pointed to by Lock2.task_point is the same as the task type D corresponding to Lock2, the task type E of TaskArray[1] pointed to by Lock3.task_point is the same as the task type E corresponding to Lock2, and Lock1.task_point and Lock4.task_point both point to the address of the win pointer, so the window expansion step does not make any modification and ends directly; it should be noted that =&win is different from =win(win=), =&win means pointing to the address of win, not the same point as win, only =win(win=) means the same point as win.

[0124] The above is the process of executing the window expansion step in the edge task allocation step. For the edge task allocation step, after executing the window expansion step, it is also necessary to check whether the task_point pointer points to the address of the win pointer. If not, enter the pointer check step. If so, check whether the task_type of the task management unit pointed to by the win pointer is the same as the task_type of the lock management unit. If they are the same, record the task management unit pointed to by the win pointer in tmp_task_unit, and modify the win pointer to point to the previous task management unit of tmp_task_unit. Return tmp_task_unit, indicating that the task allocation is successful. If they are not the same, return task allocation failure. Since Lock4.task_point = &win and the task type of the task management unit TaskArray[2] pointed to by the win pointer is B, which is the same as Lock4, the win pointer now points to TaskArray[1], and TaskArray[2] is removed from the queue and returned to the thread for processing;

[0125] After processing, the work queue and its pointers are as follows:

[0126] head:[D,E,C,B,E];

[0127] Lock4.task_point=Lock1.task_point=&win.

[0128] Scenario 3: Thread 1 completes its task and enters the task allocation process, requesting the next task from its lock management unit Lock1.

[0129] When a round of allocation process has been completed in scenario 1, the lock management unit re-performs a round of allocation process, that is, first performs a pointer check step: checks whether the task_point pointer of the lock management unit points to the address of the task queue win pointer. If so, enters the edge task allocation step; if not, enters the general task allocation step.

[0130] Since Lock1.task_point=&win, the edge task allocation step is entered, and the window expansion step is performed first: the win pointer judgment step is performed first to determine whether the win pointer points to the same point as the tail pointer. If so, the window expansion step is ended, otherwise the win pointer movement step is entered. Because the win pointer and the tail pointer do not point to the same point, the win pointer movement step is entered. For the win pointer movement step: obtain the next task management unit after the win pointer, check whether there is a lock management unit in allocate_lock_list with the same task_type as the task management unit. If so, the lock management unit is recorded as tmp_lock, and then the win pointer points to the next task management unit, and then the task_point pointer of tmp_lock is modified to point to the task management unit pointed to by the win pointer, and then the win pointer judgment step is re-entered; if not, the lock management unit pointer correction step is entered, and then the window expansion step is ended.

[0131] Since the task type of TaskArray[2] is C, and the task types of Lock1, Lock2, Lock3, and Lock4 are A, D, E, and B at this time, the lock management unit pointer correction step is entered: traverse the lock management units in allocate_lock_list and check whether there is a lock management unit whose corresponding task_type is different from the task_type of the task management unit pointed to by its task_point, or a lock management unit whose task_point points to the same address as the win pointer. If so, and the task_point of the lock management unit does not point to the address of the win pointer, then the task_point pointer of the lock management unit is pointed to the address of the win pointer. Since the pointing direction and task type of the lock management unit do not meet the conditions for lock management unit pointer correction (for specific judgment, please refer to the judgment method in scenario 2, which will not be repeated here), the window expansion step is not modified and ends directly;

[0132] The above is the process of executing the window expansion step in the edge task allocation step. For the edge task allocation step, after executing the window expansion step, it is also necessary to check whether the task_point pointer points to the address of the win pointer. If not, enter the pointer check step. If so, check whether the task_type of the task management unit pointed to by the win pointer is the same as the task_type of the lock management unit. If they are the same, record the task management unit pointed to by the win pointer in tmp_task_unit, and modify the win pointer to point to the previous task management unit of tmp_task_unit. Return tmp_task_unit, indicating that the task allocation is successful. If they are not the same, return task allocation failure. Since Lock1.task_point = &win and the task type of the task management unit TaskArray[1] pointed to by the win pointer lock is E, which is different from the task type A of Lock1, the task allocation fails.

[0133] Since the task allocation fails, thread1 will release the lock management unit at this time, and the free_lock_list of the work queue will become:

[0134] free_lock_list = [Lock1];

[0135] allocate_lock_list=[Lock2,Lock3,Lock4];

[0136] Then the lock application process is entered again. Since free_lock_list = [Lock1], thread1 obtains Lock1 through the workflow of the lock allocation management unit. At the same time, the window redefinition and window expansion steps in the lock allocation management unit step realize the modification of the win pointer, etc.

[0137] Among them, the workflow of allocating lock management units is as follows: first, execute the allocation step, check whether the free_lock_list linked list is empty, because it is not empty, so obtain the first lock management unit in the free_lock_list linked list and record it as first_free_lock_unit, and enter the pre-allocation step; that is, Lock1 is recorded as first_free_lock_unit. For the pre-allocation step, it is necessary to execute the window redefinition step, that is, move the win pointer until the win pointer and the tail pointer point to the same point or the win pointer points to a task management unit whose task_type is different from the task_type of any lock management unit in the allocate_lock_list linked list; because the task_type of Lock2, Lock3, and Lock4 are D, E, and B respectively, the win pointer stops when it moves to the task management unit corresponding to C, and then execute the lock allocation step, modify the task_point pointer of first_free_lock_unit to point to the same point as the win pointer, and at the same time modify the task_type of first_free_lock_unit to the task_type of the task management unit pointed to by the win pointer. At this time, the first_free_lock_unit is Lock1, that is, Lock1.task_point is modified to point to TaskArray[2] (corresponding to C), Lock1.task_type is modified to C, and then Lock1 is also removed from the free_lock_list linked list and added to the allocate_lock_list linked list.Then execute the window expansion step: first, perform the win pointer judgment step. Because the win pointer and the tail pointer do not point to the same thing, enter the win pointer movement step and obtain the next task management unit of the win pointer, that is, TaskArray[3](B). The task_type of Lock4 in allocate_lock_list is B, which is the same as B in TaskArray[3]. Therefore, Lock4 is recorded as tmp_lock. Since the task_point of tmp_lock points to win, win points to TaskArray[2], the task type of TaskArray[2] is C and tmp_lock. The corresponding task type (B) is different, so the task_point pointer of tmp_lock is modified to point to TaskArray[3], that is, Lock4.task_point = TaskArray[3], and then the win pointer points to the next task management unit, that is, TaskArray[3]; then re-enter the win pointer judgment step, because the win pointer is not pointing to the same point as the tail pointer, so enter the win pointer movement step, obtain the next task management unit of the win pointer, that is, TaskArray[4](E), the task_ty of Lock3 in allocate_lock_list pe is E, which is the same as E of TaskArray[1], so Lock3 is recorded as tmp_lock. Since task_point of tmp_lock points to TaskArray[1], the task type of TaskArray[1] is E, which is the same as the task type (E) corresponding to tmp_lock, so no modification is made. Then the win pointer points to the next task management unit, that is, TaskArray[4]. Then re-enter the win pointer judgment step. Because the win pointer and the tail pointer point to the same point, the lock management unit pointer correction step is performed, traversing allocate_lock_list, Lock1.ta sk_point points to TaskArray[2](C), Lock2.task_point points to TaskArray[0](D), Lock3.task_point points to TaskArray[1](E), Lock4.task_point points to TaskArray[3](B), and win points to TaskArray[4](E). No lock management unit points to the same pointer as win, and no lock management unit has a task type different from the type of the task management unit pointed to by its task_point. Therefore, no modification is made, the lock management unit pointer correction step is completed, and the window expansion step is completed.

[0138] After completing the allocation lock management unit step, the work queue and its pointer situation will become:

[0139] head:[D,E,C,B,E];

[0140] Lock1.task_point=&TaskArray[2];

[0141] Lock2.task_point=&TaskArray[0];

[0142] Lock3.task_point=&TaskArray[1];

[0143] Lock4.task_point=&TaskArray[3];

[0144] win=&TaskArray[4];

[0145] tail=&TaskArray[4].

[0146] Scenario 4: Thread 2 completes its task and enters the task allocation process, requesting the next task from its lock management unit Lock2. Similar to the processing process in Scenario 1 (not repeated here), after completion, the work queue and its pointer status will become:

[0147] head:[E,C,B,E];

[0148] Lock1.task_point=&TaskArray[1];

[0149] Lock2.task_point = &win;

[0150] Lock3.task_point=&TaskArray[0];

[0151] Lock4.task_point=&TaskArray[2];

[0152] win=&TaskArray[3];

[0153] tail=&TaskArray[3].

[0154] Scenario 5: Thread 2 completes its task and enters the task allocation process, requesting the next task from its lock management unit Lock2.

[0155] Since Lock2.task_point = &win, the edge task allocation step is entered. Since win = tail and the pointing and task types of each lock management unit do not meet the lock management unit pointer correction conditions (for specific judgment, please refer to the judgment method in Scenario 2, which will not be repeated here), the window expansion step is not modified and ends directly;

[0156] Since Lock2.task_point = &win and the task type of the task management unit TaskArray[3] pointed to by the win pointer is E, which is different from the task type D of Lock2, the task allocation fails;

[0157] Since the task allocation fails, thread2 will release the lock management unit at this time, and the free_lock_list of the work queue will become:

[0158] free_lock_list = [Lock2];

[0159] allocate_lock_list=[Lock1,Lock3,Lock4];

[0160] Then, the lock application process is entered again (that is, the workflow of the lock group structure allocation lock management unit is carried out with reference to the aforementioned allocation step, pre-allocation step, window redefinition step, lock allocation step, and window expansion step, which will not be repeated here). Since free_lock_list = [Lock2], the window redefinition step is executed, but since win = tail and the task type of TaskArray[3] is E, which is the same as Lock3, the window redefinition fails, the lock allocation fails, and thread2 will re-enter the task allocation process;

[0161] At this point the work queue and its pointer situation will become:

[0162] head:[E,C,B,E];

[0163] Lock1.task_point=&TaskArray[1];

[0164] Lock2.task_point = None;

[0165] Lock3.task_point=&TaskArray[0];

[0166] Lock4.task_point=&TaskArray[2];

[0167] win=&TaskArray[3];

[0168] tail=&TaskArray[3];

[0169] free_lock_list = [Lock2];

[0170] allocate_lock_list=[Lock1,Lock3,Lock4].

[0171] Scenario 6: After thread 1, thread 3, and thread 4 complete their tasks, the work queue and its pointer status become:

[0172] head:[];

[0173] Lock1.task_point = &win;

[0174] Lock2.task_point = None;

[0175] Lock3.task_point = &win;

[0176] Lock4.task_point = &win;

[0177] win=head;

[0178] tail=head;

[0179] free_lock_list = [Lock2];

[0180] allocate_lock_list=[Lock1,Lock3,Lock4];

[0181] When thread1, thread3, and thread4 continue to apply for tasks, the work queue and its pointer status become:

[0182] Lock1.task_point = None;

[0183] Lock2.task_point = None;

[0184] Lock3.task_point = None;

[0185] Lock4.task_point = None;

[0186] win=head;

[0187] tail=head;

[0188] free_lock_list=[Lock1,Lock2,Lock3,Lock4];

[0189] allocate_lock_list=[].

[0190] Scenario 7: If a new task is added to the queue, the work queue becomes:

[0191] head:[M];

[0192] Lock1.task_point = None;

[0193] Lock2.task_point = None;

[0194] Lock3.task_point = None;

[0195] Lock4.task_point = None;

[0196] win=head;

[0197] tail=head;

[0198] free_lock_list=[Lock1,Lock2,Lock3,Lock4];

[0199] allocate_lock_list = [];

[0200] Assume that thread1 is scheduled by the CPU first and executes the lock management unit process. Since free_lock_list[0] = Lock1 and the task type of TaskArray[0] is M, and no lock management unit task type in allocate_lock_list is consistent with it, the lock allocation is successful, and thread1 will be associated with Lock1. At this time, the work queue becomes:

[0201] head:[M];

[0202] Lock1.task_point = &win;

[0203] Lock2.task_point = None;

[0204] Lock3.task_point = None;

[0205] Lock4.task_point = None;

[0206] win = TaskArray[0];

[0207] tail=head;

[0208] free_lock_list=[Lock2,Lock3,Lock4];

[0209] allocate_lock_list=[Lock1].

[0210] The above is a description of the work queue and pointer changes under seven scenarios. Most actual application scenarios can be obtained by combining the above seven scenarios.

[0211] In summary, the embodiment of the present invention implements the binding of working threads to specific types of tasks, and at the same time achieves the effect that a thread can only process tasks of the same type in a certain time period, thereby maximizing the concurrency performance of threads in the thread pool. The embodiment of the present invention retains the versatility of existing work queues, and at the same time, when processing tasks that do not have the aforementioned "mixed" characteristics, it still has similar performance; when processing tasks that have the aforementioned "mixed" characteristics, the performance of the embodiment of the present invention is significantly better than that of existing work queues. If the work queue contains n working threads, in extreme scenarios, the present invention can improve performance by n times compared to existing work queues.

[0212] An example of the above effect is as follows: if the work queue is [Class A transaction 1, Class A transaction 2, Class A transaction 3, Class A transaction 4, Class B transaction 1, Class B transaction 2, Class B transaction 3, Class B transaction 4], and the thread pool contains 2 worker threads; the completion time of task processing = queuing waiting time + processing time.

[0213] Thread 1 processes Class A transaction 1, and thread 2 processes Class A transaction 2. Since Class A transactions cannot be executed simultaneously, thread 2 needs to wait for thread 1 to complete before it can execute.

[0214] If the average time to process a transaction is a, then the time it takes for the two threads to complete the above tasks is:

[0215] (1) Completion time of class A transaction 1 = 0 + a

[0216] (2) Completion time of type A transaction 2 = a + a

[0217] (3) Completion time of Class A transaction 3 = (a+a)+a

[0218] (4) Completion time of Class A transaction 4 = (a+a+a)+a

[0219] (5) Completion time of Class B transaction 1 = (a+a+a)+a

[0220] (6) Completion time of type B transaction 2 = (a+a+a+a)+a

[0221] (7) Completion time of Class B transaction 3 = (a+a+a+a+a)+a

[0222] (8) Completion time of Class B transaction 4 = (a+a+a+a+a+a)+a

[0223] It should be noted that for (4) and (5), since Class A task 4 and Class B task 1 can be performed concurrently, their completion time is the same.

[0224] That is, the time required to complete processing of all tasks is (a+a+a+a+a+a)+a=7a.

[0225] And according to the scheme of the present invention:

[0226] (1) Completion time of class A transaction 1 = 0 + a

[0227] (2) Completion time of type A transaction 2 = a + a

[0228] (3) Completion time of Class A transaction 3 = (a+a)+a

[0229] (4) Completion time of Class A transaction 4 = (a+a+a)+a

[0230] (5) Completion time of Class B transaction 1 = 0 + a

[0231] (6) Completion time of Class B transaction 2 = a + a

[0232] (7) Completion time of Class B transaction 3 = (a+a)+a

[0233] (8) Completion time of Class B transaction 4 = (a+a+a)+a

[0234] That is, the time required to complete processing of all tasks is (a+a+a)+a=4a.

[0235] The above process is Figure 5 The timeline diagram shown is used as an example for a more intuitive display (Note: WT stands for waiting, and threads take work queue tasks in sequence. If they take them at the same time, thread 1 takes them first):

[0236] Traditional solution:

[0237] Thread 1: A1, WT, A3, B1, B2, WT, B4.

[0238] Thread 2: WT, A2, WT, A4, WT, B3.

[0239] Assuming that the average time taken for each transaction is one unit of time, the traditional solution takes 7 units of time.

[0240] The solution of the present invention:

[0241] Thread 1: A1, A2, A3, A4.

[0242] Thread 2: B1, B2, B3, B4.

[0243] It takes 4 time units.

[0244] By comparison, it can be seen that the performance improvement is approximately n times at most (n is the number of threads).

[0245] When processing tasks that are not "mixed", both the traditional solution and our solution use two threads to process tasks simultaneously, so they have similar performance.

[0246] Example 2:

[0247] Based on the work queue for efficiently processing mixed transactions provided in Example 1, this Example 2 provides an implementation method for the work queue for efficiently processing mixed transactions to illustrate the implementation idea of ​​the work queue in Example 1.

[0248] like Figure 6 As shown, the implementation method of the work queue for efficiently processing mixed transactions provided by this embodiment specifically includes the following steps:

[0249] Step 401: A lock group structure is introduced into the work queue. This lock group structure manages the same number of locks as the number of worker threads. Each lock corresponds to a task type, thereby implementing mutually exclusive access control for different types of tasks. It should be noted that the lock group structure is introduced into the work queue to decouple task storage from access control, allowing access control of the work queue to be managed by the lock group.

[0250] Step 402: The locks managed by the lock group structure are further encapsulated into a lock management unit, and two pointers are set, one pointer pointing to the management structure of the working thread, and the other pointer pointing to a specific task in the task queue. In other words, in addition to the lock in the traditional sense, the lock management unit also contains two pointers, one pointer pointing to the management structure of the working thread, and the other pointer pointing to a specific task in the working queue. It should be noted that the lock management unit has an attribute that records the associated task type, and the lock management unit is bound to the task type through this attribute; the lock management unit is bound to the thread through the pointer pointing to the management structure of the working thread, and then the specific thread is bound to the specific type of task; the traditional task dequeueing controlled by the working queue is transformed into task dequeueing controlled by the lock management unit through the pointer pointing to the specific task in the task queue.

[0251] Step 403: Adjust the management structure of the working thread so that it no longer contains a pointer to a specific task in the task queue, but only contains a pointer to the lock management unit. All task dequeue operations are controlled by the lock management unit instead of the task queue.

[0252] Step 404: Introduce a window pointer to the task queue, and cooperate with the head and tail pointers of the task queue to separate the tasks that the current working thread can process from the tasks that cannot be processed yet.

[0253] Combining the above four steps, we can bind the worker thread to a specific type of task, and at the same time achieve the effect that a thread can only process tasks of the same type in a certain period of time, thereby maximizing the concurrency performance of the threads in the thread pool.

[0254] Specifically, in a preferred embodiment, this embodiment represents each task in the task queue by a task management unit. The task queue has three pointers, one is the head pointer, which is used to point to the head node of the queue. This node does not store any task management unit. Another is the tail pointer, which is used to point to the last task management unit in the queue. The other is the win pointer, which represents the window pointer. The task management units between the head pointer and the win pointer represent the assigned task management units, which are about to be processed by the working thread. The task management units between the win pointer and the tail pointer represent the task management units that have not yet been assigned. These task management units will be processed by the working thread in the thread pool only after they are assigned.

[0255] In a preferred embodiment, each thread in the thread pool is represented by a thread management unit, which is the execution unit of tasks in the task queue. In addition to the thread itself, the thread management unit also contains a lock_point pointer, which points to the lock management unit assigned to the thread by the lock group. When no lock is assigned, the lock_point is NULL.

[0256] In a preferred embodiment, each lock in the lock group structure is represented by a lock management unit, which includes, in addition to the lock itself, a task_point pointer for pointing to a task management unit in the task queue, a process_point pointer for pointing to the thread management unit to which it is assigned, and a task_type attribute for recording the task type associated with the lock management unit. In addition, the lock group structure also includes an allocate_lock_list linked list and a free_lock_list linked list. The allocate_lock_list linked list is used to manage allocated lock management units, and the free_lock_list linked list is used to manage unallocated lock management units. During initialization, the lock group structure initializes a corresponding number of lock management units based on the number of locks contained in the user-defined lock group, and manages these lock management units through the free_lock_list linked list.

[0257] Based on the above settings, the execution unit of the work queue is the thread management unit in the thread pool. The workflow of the working thread, the workflow of the lock group allocating the lock management unit, the workflow of the lock group releasing the lock management unit, and the workflow of the lock management unit allocating tasks can refer to the corresponding workflow steps in Example 1 and will not be repeated here.

[0258] In summary, the embodiment of the present invention implements the binding of working threads to specific types of tasks, and at the same time achieves the effect that a thread can only process tasks of the same type in a certain time period, thereby maximizing the concurrency performance of threads in the thread pool. The embodiment of the present invention retains the versatility of existing work queues, and at the same time, when processing tasks that do not have the aforementioned "mixed" characteristics, it still has similar performance; when processing tasks that have the aforementioned "mixed" characteristics, the performance of the embodiment of the present invention is significantly better than that of existing work queues. If the work queue contains n working threads, in extreme scenarios, the present invention can improve performance by n times compared to existing work queues.

[0259] Example 3:

[0260] Based on the work queue for efficiently processing mixed transactions and its implementation method provided in the above embodiments 1 and 2, the present invention also provides a device that can be used to implement the above work queue workflow, such as Figure 7 FIG2 is a schematic diagram of the device architecture of an embodiment of the present invention. The device of this embodiment includes one or more processors 21 and a memory 22. Figure 7 A processor 21 is taken as an example.

[0261] The processor 21 and the memory 22 may be connected via a bus or other means. Figure 7 The bus connection is taken as an example.

[0262] The memory 22, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer executable programs, and modules, such as the implementation methods of the various workflows in Example 1. The processor 21 executes the non-volatile software programs, instructions, and modules stored in the memory 22 to execute various functional applications and data processing of the work queue for efficiently processing mixed transactions, thereby implementing the work queue for efficiently processing mixed transactions in Example 1.

[0263] The memory 22 may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state memory device. In some embodiments, the memory 22 may optionally include a memory remotely located relative to the processor 21, and such remote memory may be connected to the processor 21 via a network. Examples of such networks include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0264] The program instructions / modules are stored in the memory 22. When executed by one or more processors 21, the program instructions / modules execute the various workflows of the work queue for efficiently processing mixed transactions in the above embodiment 1, for example, the above described Figure 2-Figure 4 The steps shown.

[0265] Those skilled in the art will understand that all or part of the steps in the various methods of the embodiments can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), a disk or an optical disk, etc.

[0266] It should also be noted that the present invention relates to the field of distributed storage systems, but its application scenarios are not limited to distributed storage systems, but can also be extended to any software system that requires a work queue.

[0267] The foregoing description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention shall be included within the scope of protection of the present invention. Any matters not described in detail in this specification constitute prior art known to those skilled in the art.

Claims

1. A method for implementing a work queue for efficiently processing mixed transactions, characterized in that: include: A lock group structure is introduced on the work queue. The lock group structure manages locks with the same number of working threads. Each lock corresponds to a task type, thereby realizing mutually exclusive access control of tasks of different types. The lock group structure is a storage structure of locks, wherein each lock is represented by a lock management unit. The lock management unit includes a task_point pointer, a process_point pointer and a task_type attribute. The task_point pointer is used to point to a task management unit in the task queue, the process_point pointer is used to point to the thread management unit to which it is assigned, and the task_type attribute is used to record the task type associated with the lock management unit. The lock group structure includes an allocate_lock_list linked list and a free_lock_list linked list. The allocate_lock_list linked list is used to manage allocated lock management units, and the free_lock_list linked list is used to manage unallocated lock management units. The locks managed by the lock group structure are further encapsulated into a lock management unit, and two pointers are set, one pointer points to the management structure of the working thread, and the other pointer points to the specific task in the task queue; Adjust the management structure of the worker thread so that it no longer contains pointers to specific tasks in the task queue, but only contains pointers to the lock management unit. All task dequeue operations are controlled by the lock management unit instead of the task queue. A window pointer is introduced on the task queue, and cooperated with the head and tail pointers of the task queue to separate the tasks that the current working thread can process from the tasks that cannot be processed yet; the task queue is a storage structure for tasks, in which each task is represented by a task management unit, and the task queue contains a head pointer, a tail pointer and a win pointer. The head pointer is used to point to the head node of the task queue, which does not store any task management unit, and the tail pointer is used to point to the last task management unit in the task queue. The win pointer represents the window pointer.

2. A method for implementing a work queue for efficiently processing mixed transactions, characterized in that: The work queue includes a task queue, a thread pool, and a lock group structure. Specifically: The task queue is a storage structure for tasks, wherein each task is represented by a task management unit. The task queue includes a head pointer, a tail pointer, and a win pointer. The head pointer is used to point to the head node of the task queue, which does not store any task management unit. The tail pointer is used to point to the last task management unit in the task queue, and the win pointer represents the window pointer. The thread pool is a storage structure of worker threads, wherein each worker thread is represented by a thread management unit, and the thread management unit includes a lock_point pointer, wherein the lock_point pointer points to the lock management unit assigned to the worker thread by the lock group structure; The lock group structure is a storage structure of locks, in which each lock is represented by a lock management unit. The lock management unit includes a task_point pointer, a process_point pointer and a task_type attribute. Its task_point pointer is used to point to a task management unit in the task queue, its process_point pointer is used to point to the thread management unit to which it is assigned, and its task_type attribute is used to record the task type associated with the lock management unit. Each lock corresponds to a task type, thereby realizing mutual exclusive access control of different types of tasks; the lock group structure includes an allocate_lock_list linked list and a free_lock_list linked list. Its allocate_lock_list linked list is used to manage allocated lock management units, and its free_lock_list linked list is used to manage unallocated lock management units.

3. The method for implementing a work queue for efficiently processing mixed transactions according to claim 2, characterized in that: The execution unit of the work queue is the thread management unit in the thread pool, where the workflow of the worker thread includes: Lock management unit allocation step: Check whether the lock management unit is allocated. If the lock management unit is not allocated, apply to the lock group structure for allocation of the lock management unit. If the lock group structure successfully allocates the lock management unit, modify the lock_point pointer of the thread management unit to point to the allocated lock management unit, and then enter the task allocation step; if the lock group structure fails to allocate the lock management unit, re-enter the lock management unit allocation step; if the lock management unit has been allocated, enter the task allocation step; Task allocation step: initiate a task allocation request to the lock management unit pointed to by the lock_point pointer of the thread management unit. If the task is obtained, that is, the task allocation is successful, then enter the task processing step. If the task is not obtained, that is, the task allocation fails, then enter the lock release step; Task processing step: Process the acquired tasks and enter the lock management unit allocation step after the processing is completed; Release lock step: initiate a lock release request to the lock management unit pointed to by the lock_point pointer of the thread management unit. If the lock management unit completes the release, enter the pointer update step, otherwise enter the lock management unit allocation step; Pointer update step: modify the lock_point pointer of this thread management unit to be empty, and then enter the lock management unit allocation step.

4. The method for implementing a work queue for efficiently processing mixed transactions according to claim 3, characterized in that: The workflow of the lock group structure allocation lock management unit includes: Allocation step: Check whether the free_lock_list linked list is empty. If it is empty, return allocation failure. If it is not empty, obtain the first lock management unit in the free_lock_list linked list and record it as first_free_lock_unit, and enter the pre-allocation step. If the pre-allocation is successful, the allocation is successful and the lock management unit pointed to by first_free_lock_unit is returned. Otherwise, the allocation fails. Among them, first_free_lock_unit is used to temporarily store an idle lock management unit obtained from the free_lock_list linked list. It is applied when the lock management unit allocation process starts and is released after the lock management unit allocation process ends. Pre-allocation step: Execute the window redefinition step. If the execution fails, it returns a pre-allocation failure. If the execution succeeds, it executes the lock allocation step and the window expansion step in sequence, and returns the first_free_lock_unit returned by the lock allocation step. Window redefinition steps: Move the win pointer until the win pointer and the tail pointer point to the same point or the win pointer points to a task management unit whose task_type is different from the task_type of any lock management unit in the allocate_lock_list list. If the win pointer and the tail pointer point to the same point and the tail pointer points to a task management unit whose task_type is the same as the task_type of a lock management unit in the allocate_lock_list list, the window redefinition fails. Otherwise, the window redefinition succeeds. Lock allocation steps: modify the task_point pointer of first_free_lock_unit to point to the same pointer as win, and modify the task_type of first_free_lock_unit to the task_type of the task management unit pointed to by win pointer, modify the process_point pointer of first_free_lock_unit to the address of the thread unit that applies for the lock management unit, then remove first_free_lock_unit from the free_lock_list linked list and add it to the allocate_lock_list linked list, and return first_free_lock_unit, indicating that the lock allocation is successful; Window expansion step: perform window expansion.

5. The method for implementing a work queue for efficiently processing mixed transactions according to claim 3, characterized in that: The workflow of the lock group structure releasing the lock management unit includes: Modify the task_point, task_type and process_point of the lock management unit to empty, remove the lock management unit from the allocate_lock_list linked list, and add it to the free_lock_list linked list for processing, and return a successful release.

6. The method for implementing a work queue for efficiently processing mixed transactions according to claim 3, characterized in that: The workflow of the lock management unit assigning tasks includes: Pointer checking step: Check whether the task_point pointer of the lock management unit points to the address of the task queue win pointer. If so, enter the edge task allocation step; if not, enter the general task allocation step; General task allocation steps: record the task management unit pointed to by the task_point pointer in tmp_task_unit, and at the same time point task_point to the next task management unit of the task management unit corresponding to tmp_task_unit, remove the task management unit corresponding to tmp_task_unit from the task queue, and enter the task_point pointer movement step. Among them, tmp_task_unit is a temporary variable used to temporarily store the task to be allocated. It is defined when the process of allocating tasks by the lock management unit is started and is released after the process is completed; Task_point pointer moving steps: By moving the task_point pointer, traverse all task management units between the task_point pointer and the task queue win pointer until the task type of the traversed task management unit is the same as the task_type of the lock management unit or the task_point pointer and the task queue win pointer point to the same point. Then return tmp_task_unit, indicating that the task allocation is successful. If the task_point pointer and the task queue win pointer point to the same point before returning, set task_point to the address of the win pointer. Edge task allocation step: execute the window extension step, check whether the task_point pointer points to the address of the win pointer, if not, enter the pointer check step, if so, check whether the task_type of the task management unit pointed to by the win pointer is the same as the task_type of the lock management unit, if they are the same, record the task management unit pointed to by the win pointer in tmp_task_unit, and modify the win pointer to point to the previous task management unit of tmp_task_unit, and return tmp_task_unit, indicating that the task allocation is successful. If they are not the same, the task allocation failure is returned.

7. The method for implementing a work queue for efficiently processing mixed transactions according to any one of claims 4 or 6, characterized in that: The window expansion step includes: Win pointer determination step: determine whether the win pointer and the tail pointer point to the same direction. If so, proceed to the lock management unit pointer correction step and then end the window expansion step. Otherwise, proceed to the win pointer movement step. Win pointer moving step: obtain the next task management unit of the win pointer, check whether there is a lock management unit with the same task_type as the task management unit in allocate_lock_list, if so, record the lock management unit as tmp_lock, if the task_type of the task management unit pointed to by the task_point of tmp_lock is different from the task_type corresponding to tmp_lock, modify the task_point pointer of tmp_lock to point to the task management unit pointed to by the win pointer, otherwise do not modify it, then the win pointer points to the next task management unit, and then re-enter the win pointer judgment step; if not, enter the lock management unit pointer correction step, and then end the window expansion step; Lock management unit pointer correction steps: traverse the lock management units in allocate_lock_list, check whether there is a lock management unit whose corresponding task_type is different from the task_type of the task management unit pointed to by its task_point, or a lock management unit whose task_point points to the same point as the win pointer. If so, and the task_point of the lock management unit does not point to the address of the win pointer, then point the task_point pointer of the lock management unit to the address of the win pointer.

8. The method for implementing a work queue for efficiently processing mixed transactions according to any one of claims 2 to 6, characterized in that: For the task queue, the task management units between its head pointer and win pointer represent the assigned task management units, which are about to be processed by the working threads; the task management units between its win pointer and tail pointer represent the task management units that have not yet been assigned, which will be processed by the working threads in the thread pool only after they are assigned.

9. The method for implementing a work queue for efficiently processing mixed transactions according to any one of claims 2 to 6, characterized in that: For the thread management unit, when no lock is allocated, its lock_point is empty; for the lock group structure, when the lock group structure is initialized, the corresponding number of lock management units is initialized according to the number of locks contained in the user-defined lock group, and these lock management units are managed through the free_lock_list linked list.

Images