Task queue access method and device

Abstract

The invention discloses a task queue access method and device, the task queue is a one-way linked list, each node comprises a first storage area for storing a first intelligent pointer and a second storage area for storing a second intelligent pointer, the first intelligent pointer is used for storing a task data unit pointer, and the second intelligent pointer is used for storing a task data unit pointer. The second intelligent pointer is used for storing a node pointer of a next node. The method comprises the following steps: obtaining an access request for a task queue; determining whether a mutual exclusion lock needs to be added or not; if so, locking the head mutual exclusion lock and / or the tail mutual exclusion lock of the task queue; obtaining a head node and / or a tail node, and performing an access operation related to the access request; and if not, directly executing the access operation based on the access request. According to the scheme, the head and the tail of the task queue can be independently locked, operation of storing and acquiring data can be executed at the same time, and the data interaction speed is increased; and meanwhile, CPU and memory resources can be saved by using the intelligent pointer storage data structure.

Description

Technical Field

[0001] This application relates to the field of data processing technologies, and more specifically, to a method and apparatus for accessing a task queue. Background Art

[0002] Currently, general high-level programming languages usually have their own standard template container libraries, which are used to store and access data during the development of functions. For example, the standard template container library STL of the C++ language provides some common containers: the vector structure that supports data storage in the form of an array, the list structure that supports data storage in the form of a linked list, the queue structure that supports data storage in the form of a first-in, first-out queue, etc.

[0003] In the actual development process, especially when implementing business scenarios related to interactive communication, there are generally module units for task reception and processing. The technical requirements of this business module are as follows:

[0004] Define a data structure to store task units to be processed, usually using a queue;

[0005] Define a mutex for accessing this data, and perform mutual exclusion when putting data into and taking data out of the queue. Only one operation can be performed at the same time;

[0006] Define a condition variable to be used as a notification that new data has been stored in the queue; start a thread to monitor whether there is task data in the queue. If there is data, subsequent processing will be performed;

[0007] According to the existing technical foundation, the process of processing a task can have the following steps:

[0008] a. Start a thread to receive and process task data units;

[0009] b. Determine whether it is necessary to run and receive task data. If so, continue to step c; otherwise, jump to step i;

[0010] c. Lock the mutex and determine whether there are task units to be processed in the queue;

[0011] d. If there are, take out the task data, release the mutex, process the task, and jump to step b after processing;

[0012] e. If not, call the "wait" of the condition variable and enter the blocked state;

[0013] f. Lock the mutex and put the task processing unit into the queue;

[0014] g. Call the "notify" operation of the condition variable;

[0015] h. At this time, the receiving thread condition variable resumes from the blocked state and jumps to step b;

[0016] i. End the operation.

[0017] Currently, the solutions for non-blocking task data notification processing generally combine high-level language threads, thread synchronization means (mutex locks, condition variables, etc.) and standard container libraries to implement. Additionally, the container library is generally of template type, so during programming, it can store the task type structure formulated by itself, having a certain degree of generality.

[0018] Although the above-mentioned means of data processing synchronization are relatively general, there are still some problems. For example, the thread resource overhead is relatively large, and the mutual exclusion of data access leads to a decrease in the performance of task communication and interaction. Summary of the Invention

[0019] In view of this, the present application provides the following technical solutions:

[0020] The first aspect of the present application provides a method for accessing a task queue. The task queue is a singly linked list, and each node therein includes a first storage area for storing a first smart pointer and a second storage area for storing a second smart pointer. The first smart pointer is used to store a pointer to a task data unit, and the second smart pointer is used to store a pointer to the next node. The method includes:

[0021] Obtain an access request for the task queue;

[0022] Based on the access request, determine whether a mutex lock needs to be added;

[0023] If the mutex lock needs to be added, lock the head mutex lock and / or the tail mutex lock of the task queue; obtain the head node and / or the tail node, and perform an access operation related to the access request;

[0024] If the mutex lock does not need to be added, directly perform an access operation based on the access request.

[0025] In a possible implementation, the method further includes:

[0026] Obtain a control request for the task queue;

[0027] Based on the control request, perform corresponding control operations.

[0028] In a possible implementation, the access request is a request to obtain task data, and the request to obtain task data requires adding a mutex lock. The locking of the head mutex lock and / or the tail mutex lock of the task queue; obtaining the head node and / or the tail node, and performing an access operation related to the access request includes:

[0029] Lock the mutex of the head node of the task queue and lock the mutex of the tail node of the task queue;

[0030] Determine whether the task queue is empty;

[0031] If the task queue is empty, return an empty node;

[0032] If the task queue is not empty, return the head node data.

[0033] In a possible implementation, the access request is a request to block and wait for task data, and the locking of the mutex of the head of the task queue and / or the locking of the mutex of the tail; obtaining the head node and / or the tail node, and performing access operations related to the access request, including:

[0034] Lock the mutex of the head node of the task queue and lock the mutex of the tail node of the task queue;

[0035] Determine whether the task queue is empty;

[0036] If the task queue is empty and the task queue is in a running state, block and wait using the data condition variable until notified by the data condition variable, and then return the head node data;

[0037] If the task queue is not empty, directly return the head node data;

[0038] If the task queue is in a stopped running state, return an empty node.

[0039] In a possible implementation, the determining whether the task queue is empty includes:

[0040] Obtain the tail node data;

[0041] Based on the tail node data, determine whether the head node and the tail node of the task queue are the same node;

[0042] If so, determine that the task queue is empty;

[0043] If not, determine that the task queue is not empty.

[0044] In a possible implementation, the returning of the head node data includes removing the head node from the task queue and returning the first smart pointer of the head node, including:

[0045] Assign the head node to a first temporary smart pointer object;

[0046] Assign the second smart pointer of the first temporary smart pointer object to the head node pointer, where the head node pointer is a pointer pointing to the head node;

[0047] Return the first temporary smart pointer object.

[0048] In a possible implementation, the access request is a request to write task data to a task queue, and the method includes locking the head mutex and / or the tail mutex of the task queue; obtaining a head node and / or a tail node, and performing an access operation related to the access request, including:

[0049] Receive a target smart pointer object;

[0050] Create a new smart pointer object, where the new smart pointer object is a null node;

[0051] Lock the mutex of the head and / or the tail of the task queue;

[0052] Assign the target smart pointer object to the first storage area of the current tail node;

[0053] Assign the data in the first storage area of the new smart pointer object to a temporary node pointer;

[0054] Assign the new smart pointer object to the second storage area of the current tail node;

[0055] Assign the temporary node pointer to a tail node pointer, where the tail node pointer is a pointer pointing to the tail node.

[0056] In a possible implementation, after assigning the temporary node pointer to the tail node pointer, the method further includes:

[0057] Send a notification message using a data condition variable to notify the blocked waiting entity that new data has been added to the task queue.

[0058] In a possible implementation, the task queue includes a running status flag, and the running status flag is used to indicate the running status of the task queue.

[0059] A second aspect of the present application provides an access device for a task queue. The task queue is a singly linked list, and each node therein includes a first storage area for storing a first smart pointer and a second storage area for storing a second smart pointer. The first smart pointer is used to store a task data unit pointer, and the second smart pointer is used to store a node pointer to the next node. The device includes:

[0060] A request obtaining module, configured to obtain an access request for the task queue;

[0061] A locking determination module, configured to determine whether a mutex needs to be added based on the access request;

[0062] A locking operation module, configured to lock the head mutex and / or the tail mutex of the task queue when a mutex needs to be added, obtain the head node and / or the tail node, and perform an access operation related to the access request;

[0063] A direct operation module, configured to directly perform an access operation based on the access request when a mutex does not need to be added.

[0064] As can be seen from the above technical solutions, embodiments of the present application disclose a method and an apparatus for accessing a task queue. The task queue is a singly linked list, and each node therein includes a first storage area for storing a first smart pointer and a second storage area for storing a second smart pointer. The first smart pointer is used to store a pointer to a task data unit, and the second smart pointer is used to store a pointer to the next node. The method includes: obtaining an access request for the task queue; determining whether a mutex needs to be added based on the access request; if so, locking the head mutex and / or the tail mutex of the task queue; obtaining the head node and / or the tail node, and performing an access operation related to the access request; if not, directly performing an access operation based on the access request. The head and tail of the task queue in the above solution have independent mutexes and can be locked independently. Therefore, operations of storing and obtaining data can be performed simultaneously, improving the speed of data interaction. At the same time, using smart pointers to store data structures can save the copying and copying of data space, saving CPU and memory resources. Description of the Drawings

[0065] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the drawings in the following description are only the embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained according to the provided drawings without creative efforts.

[0066] Figure 1 Schematic diagram of the definition of the node class of the task queue disclosed in the embodiments of the present application;

[0067] Figure 2 Flowchart of a method for accessing a task queue disclosed in the embodiments of the present application;

[0068] Figure 3 Schematic diagram of the definition of the task queue structure disclosed in the embodiments of the present application;

[0069] Figure 4 Schematic diagram of the process of adding data to the DoPush method disclosed in the embodiments of the present application;

[0070] Figure 5Structural schematic diagram of an access device for a task queue disclosed in an embodiment of the present application. Detailed implementation manners

[0071] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0072] The present application aims to provide an access solution for a task queue. For the convenience of understanding, the implementation of the task queue will be introduced accordingly first. The task queue can exist in the form of a template and can be applicable to application scenarios with different data structures.

[0073] Since the task queue is first in first out and there is no need to randomly access internal data, a linked list can be used to store data. Since each task placed in the queue is at the end, it only needs to hang the data on the last node. Each time data is retrieved, the head node is retrieved from the front of the queue. Therefore, there is no need to use a doubly linked list that can perform two-way searches. Each node only needs to remember its next node, so a singly linked list is sufficient.

[0074] When task data is placed in or retrieved from the queue, if the data object itself is stored, at the computer operation level, a space of the same size as the object will be created first, then the content of the data object stored in the queue will be copied into the created data space, and then the data content stored in the queue will be destroyed. In this way, if a data message object with a larger structure is stored, there will be additional operations and overheads.

[0075] In order to avoid the additional overheads brought by object copying and destruction during data storage and retrieval, the task queue of the present application uses shared smart pointers to store the original task data objects. A shared smart pointer is a special type. The smart pointer type contains a reference counting member that can store integer data, indicating how many smart pointer objects are currently jointly managing a common pointer. When only one smart pointer object manages the common pointer, the reference count is 1. Similarly, when an additional smart pointer object that manages the pointer is added, the reference count will increase by one. All smart pointer objects that jointly manage the same common pointer share this reference count. When the life cycle of the last smart pointer object ends, the reference count will become 0, and at this time, the resources of the common pointer it manages need to be released. In this way, using shared smart pointers to store the original task data objects only requires dynamically allocating space once when creating the task data object (the size of the smart pointer object is 8 bytes), and subsequent storage and retrieval can use smart pointers to manage this space.

[0076] In addition, each node in the task queue, that is, the node in the singly linked list, also needs to have a smart pointer node to save the pointer address of the next node. The smart pointer can determine what type of data structure to point to. The linked list node here has two data members: one, a smart pointer of the task structure type, stored in the first storage area of the node, pointing to the stored message task data; two, a smart pointer of the node type, stored in the second storage area of the node, pointing to the next node storing the message task structure. That is, the node node in the task queue has two data members: a shared smart pointer data storing the task unit pointer and a shared smart pointer next storing the pointer of the next node, as shown in Figure 1 the following figure.

[0077] In summary, the task queue in this application is a singly linked list, and each node in it includes a first storage area storing the first smart pointer and a second storage area storing the second smart pointer. The first smart pointer is used to store the task data unit pointer, and the second smart pointer is used to store the node pointer of the next node.

[0078] The member variables of the task queue TaskQueue include:

[0079] (1) Head node headNode: A shared smart pointer that manages the pointer of the head node node;

[0080] (2) Tail node tailNode: A node pointer that saves the data of the last task unit;

[0081] (3) Head node operation mutex headMutex: Used to ensure the atomicity of operating on the head node;

[0082] (4) Tail node operation mutex tailMutex: Used to ensure the atomicity of operating on the tail node;

[0083] (5) Data condition variable dataCond: If new data is stored, it will send a notification, and the operation of fetching data will change from blocked to non-blocked state; A condition variable generally has two basic operations: "wait" and "notify". When calling the "wait" operation of a condition variable, the program will block here. If other code subsequently calls the "notify" operation of this condition variable, the program blocked at "wait" will resume non-blocked state and continue to run the program code downward. The condition variable needs to be used in combination with a mutex. Generally, lock the mutex before waiting. If certain conditions are not met, then call "wait" and release the corresponding mutex;

[0084] (6) Running status isRun: Saves the status of whether the current task queue is running. If it is in a non-running state, all method calls will return failure, and getting task unit data will return an empty smart pointer.

[0085] When initializing the task queue, the head node will save a pointer to an empty node. The next member of the head node points to itself, indicating that there is no data in the queue. When adding data to the queue subsequently, an empty node will always be retained at the tail of the task queue.

[0086] When initializing the task queue, the head node will save a pointer to an empty node. The next member of the head node points to itself, and the tail node also points to this node. At this time, the head node uses this empty node to indicate that there is no data in the queue. When adding data to the queue subsequently, an empty node will always be retained at the tail of the queue.

[0087] Figure 2 This is a flowchart of an access method for a task queue disclosed in an embodiment of the present application. Refer to Figure 1 As shown, the access method for the task queue may include:

[0088] Step 201: Obtain an access request for the task queue.

[0089] The access request may be a read data request or a write data request, and the present application does not impose a fixed limitation on this.

[0090] Step 202: Based on the access request, determine whether a mutex lock needs to be added, and enter Step 203 or Step 204.

[0091] It can be understood that when the task queue executes some methods, in order to ensure the atomicity of the corresponding operations, a mutex lock needs to be added to the relevant data. In the present application, there is an independently controllable mutex lock at the head of the task queue, and there is also an independently controllable mutex lock at the tail of the task queue. When performing an access operation on the task queue, if it is necessary to lock any one of the above two mutex locks, it is determined that a mutex lock needs to be added; if it is not necessary to lock the above two mutex locks, it is determined that no mutex lock needs to be added.

[0092] Step 203: If it is necessary to add the mutex lock, lock the head mutex lock and / or the tail mutex lock of the task queue; obtain the head node and / or the tail node, and perform an access operation related to the access request.

[0093] If it is necessary to lock the mutex lock, perform the corresponding mutex lock operation, and perform the corresponding access operation after the locking is completed. The implementation of the operation method of the task queue will be introduced in detail in the subsequent embodiment content and will not be elaborated here.

[0094] Step 204: If there is no need to add the mutex lock, directly perform an access operation based on the access request.

[0095] If there is no need to lock the mutex, the corresponding access operation can be directly performed on the task queue based on the access request.

[0096] In the traditional solution, at least one thread accessing the task queue needs to execute in a loop, continuously locking, judging whether task data has arrived and processing it, then waiting for notification and judging and processing again, and then locking, accessing, and waiting again. This operation of the thread running on an operating system with limited memory or CPU resources will be an additional overhead. However, the solution of this application uses smart pointers to store data structures, which can save the copy and copy operations of data space and save CPU and memory resources.

[0097] In the traditional solution, data access mutex leads to a reduction in task communication and interaction performance: Since the queue does not support multi-threaded safe operations, in this solution, before accessing and storing the task queue, it is necessary to lock it with a mutex to avoid internal data retrieval from the queue and external data insertion simultaneously. In scenarios where communication tasks interact frequently, the time wasted by the mutex between data insertion and retrieval is relatively significant compared to the performance of task processing. If the time wasted by mutex blocking can be reduced, the efficiency of task processing can be improved. However, in the solution of this application, the head and tail of the task queue have independent mutex locks and can be locked independently. Therefore, the operations of storing and retrieving data can be executed simultaneously, improving the speed of data interaction.

[0098] To implement the access operation of the task queue, the private methods of the task queue in this application will be introduced one by one later. Combined Figure 3 As shown, the private methods of the task queue are only used within the class and are the basis for implementing data operations.

[0099] 1. GetTail method for obtaining the tail node pointer

[0100] This method is used to obtain the tail pointer at the current moment to determine whether it is the same as the head pointer. If new data is added immediately at the next moment, it has nothing to do with this judgment. For example, both the operation of obtaining the tail and the operation of adding data to the tail of the task queue need to operate on the tail node. No matter which operation is performed, the tail node will be locked first to ensure that only one operation is in progress at the same time; that is, if the operation of GetTail is not completed, it will also be impossible to add new data.

[0101] Implementation of the GetTail method for obtaining the tail node pointer:

[0102] a. Add a tail mutex lock (to maintain the atomicity of tail node operations. At this time, there should be no operations modifying the tail node while adding data in progress);

[0103] b. Return the tail node.

[0104] (2) PopHead method for popping the head node smart pointer

[0105] This operation needs to be called when it is determined that the task queue is not empty. Essentially, it encapsulates the operation of returning the head node, facilitating calls from other methods, that is, simply obtaining the head node information. The implementation can include:

[0106] a. Assign the head node to the temporary smart pointer object temp;

[0107] b. Assign the next (second storage area) of this temporary smart pointer node to the head node pointer; (to make the head node pointer point to the node pointed to by next)

[0108] c. Return temp.

[0109] (3) TryPopHead method for attempting to pop the head node

[0110] This method will attempt to return the head node of the task queue. If the task queue is empty, it will return an empty smart pointer data; otherwise, it will return the data of the head node:

[0111] a. Add a head mutex lock;

[0112] b. Determine whether the current head node and the tail node returned by the GetTail method are the same node:

[0113] If they are the same node, it means the task queue is empty, and return an empty node;

[0114] Otherwise, the task queue is not empty, and return the data obtained by calling the PopHead method.

[0115] (4) WaitPopHead method for waiting for the task queue to be non-empty and popping the head node

[0116] This method is used to block and wait for data in the task queue. If data is added to the task queue, it will return the data of the head node; if the task queue is cancelled, it will return an empty node:

[0117] a. Add a head node mutex lock;

[0118] b. Determine that the current head node and the tail node returned by the GetTail method are not the same node or the current task queue is in a stopped state:

[0119] If it is the same node and not in the stop state, use the data condition variable to block and wait. Until notified by the data condition variable, jump to step b;

[0120] Otherwise, if the task queue is not empty, continue with subsequent step c;

[0121] c. Return the data obtained by calling the PopHead method;

[0122] d. If the task queue has stopped running, return empty data.

[0123] (5) The DoPush method for putting data into the queue can be understood in combination with Figure 4 the following content.

[0124] This method receives a smart pointer object pData that holds a pointer to the task data unit:

[0125] a. Create a new empty node smart pointer object pEmpty;

[0126] b. Lock the tail node mutex;

[0127] c. Assign pData to the data storage of the current tail node;

[0128] d. Declare a temporary node pointer pTemp and assign the data of pEmpty to it;

[0129] e. Assign pEmpty to the next of the tail node (the queue always stores an empty tail node);

[0130] f. Assign pTemp to the current tail node;

[0131] g. The data condition variable calls the "notify" method to notify the place blocked waiting for data that new data has been added.

[0132] Based on the above content, in one implementation, the access request is a request to obtain task data. The request to obtain task data needs to add a mutex, and lock the head mutex and / or tail mutex of the task queue; obtain the head node and / or tail node, and perform access operations related to the access request, which may include: locking the head node mutex of the task queue and locking the tail node mutex of the task queue; determining whether the task queue is empty; if the task queue is empty, return an empty node; if the task queue is not empty, return the head node data.

[0133] Obtaining task data provides an implementation for external operation calls of the public method of the task queue. It can be considered as an attempt to obtain the smart pointer of the task data unit TryPop method, including:

[0134] a. Call the TryPopHead method to return the smart pointer pHead of the node;

[0135] b. If pHead is not null, return the data of pHead; otherwise, return empty data.

[0136] In another implementation, the access request is a request to block and wait for task data, and the locking of the mutex for the head of the task queue and / or the locking of the mutex for the tail; obtaining the head node and / or the tail node, and performing access operations related to the access request may include: locking the mutex for the head node of the task queue and locking the mutex for the tail node of the task queue; determining whether the task queue is empty; if the task queue is empty and the task queue is in a running state, block and wait using the data condition variable until notified by the data condition variable, and then return the head node data; if the task queue is not empty, directly return the head node data; if the task queue is in a stopped running state, return an empty node.

[0137] Blocking and waiting for task data provides another implementation for external operation calls of the public method of the task queue, which can be considered as the WaitAndPop method that blocks and waits to obtain the smart pointer of the task data unit, including:

[0138] a. Call the WaitPopHead method to block and wait for the smart pointer pHead of the head node of the task queue to be returned;

[0139] b. If the current task queue is in a stopped running state, return empty data;

[0140] Otherwise, return the data of pHead.

[0141] Specifically, determining whether the task queue is empty in the foregoing content may include: obtaining the tail node data; determining whether the head node and the tail node of the task queue are the same node based on the tail node data; if so, determining that the task queue is empty; if not, determining that the task queue is not empty. It can be understood that if the head node and the tail node are the same node, it means that no nodes have been added after the task queue is created, so no data is stored and the task queue is empty; if the head node and the tail node are not the same node, it means that new nodes have been added and data has been stored after the task queue is created, and the task queue is not empty.

[0142] Implementation of the Empty method for determining whether the task queue is empty:

[0143] a. Lock the mutex for the head node;

[0144] b. Determine whether the node pointer saved by the first smart pointer of the head node is the same as the node pointer returned by GetTail, and return the result to the calling function.

[0145] Specifically, the content of returning the head node data in the foregoing description, which includes removing the head node from the task queue and returning the first smart pointer of the head node, may include: assigning the head node to a first temporary smart pointer object; assigning the second smart pointer of the first temporary smart pointer object to the head node pointer, where the head node pointer is a pointer pointing to the head node; and returning the first temporary smart pointer object. For the specific implementation, refer to the content of the PopHead method for popping the smart pointer of the head node.

[0146] In another implementation, the access request is a request to write task data to the task queue, and locking the head mutex and / or the tail mutex of the task queue; obtaining the head node and / or the tail node, and performing an access operation related to the access request may include: receiving a target smart pointer object; creating a new smart pointer object, where the new smart pointer object is an empty node; locking the head mutex and / or the tail mutex of the task queue; assigning the target smart pointer object to the first storage area of the current tail node; assigning the data in the first storage area of the new smart pointer object to a temporary node pointer; assigning the new smart pointer object to the second storage area of the current tail node; and assigning the temporary node pointer to the tail node pointer, where the tail node pointer is a pointer pointing to the tail node. For the specific implementation, refer to the content of the DoPush method for putting data into the queue.

[0147] Further, after assigning the temporary node pointer to the tail node pointer, optionally, it may further include: sending a notification message using a data condition variable to notify the blocked waiting entity that new data has been added to the task queue. Refer to the last step g in the DoPush method for putting data into the queue.

[0148] In other implementations, the task queue includes a running status flag, which is used to indicate the running status of the task queue. Such as the foregoing running status isRun. When writing data to the task queue, such as storing a task data unit into the task queue, if the current task queue is in a stopped running state, the end method is returned; if the current task queue is in a running state, the DoPush method is called to store the task data smart pointer.

[0149] In other implementations, the access method of the task queue may further include: obtaining a control request for the task queue; and performing a corresponding control operation based on the control request.

[0150] For example, if the control request is to terminate the task queue operation, it can be achieved by calling the CancelWait method to cancel the waiting for the task queue to terminate. Invoking this method will send a notification to the data condition variable, notifying all blocked and waiting code to abandon the wait and return to the end function. This includes: a. Setting the running status to false; b. Invoking the "notify" operation of the data condition variable.

[0151] Another example is that if the control request is to clear the task queue, it can be achieved by calling the Clear method to clear the data queue. This method is used to remove all the nodes that have been stored in the queue, leaving only an empty node.

[0152] Another example is that if the control request is to restart the task queue, it can be achieved by calling the Restart method of the task queue. Simply set the running status to true, and other methods will be able to run normally.

[0153] Based on the above, the present application is a task queue solution suitable for multi-threaded support of concurrent access to data storage and retrieval, and has the following advantages:

[0154] The task queue implemented in the present application uses headMutex and tailMutex to lock the operations at the head and tail of the queue respectively, so as to separate the data storage and retrieval as much as possible, and improve the data interaction speed in a multi-threaded scenario;

[0155] The internal data members of the task queue use smart pointers to store data. While being able to support the storage and retrieval of any type of data like traditional solutions, it reduces the large object copy operations during data storage and retrieval, saves space, and reduces the waste of CPU caused by data copying;

[0156] The task queue has its own running status and can be repeatedly enabled and stopped. The resource overhead is only the setting of a flag bit, avoiding the problem of repeated resource overhead caused by re-creating threads in traditional solutions;

[0157] The task queue has a high degree of integration. Only need to define a task queue variable of the specified task data structure at the application location; that is, encapsulate all the internal implementation logics, thus simplifying the external use. Only need to specify what data structure the task is, and this queue can perform the message task sending and receiving notification mechanism. When implementing the business function, only need to call the methods provided by this variable to achieve the business application of asynchronous data storage and retrieval, and it can be easily integrated into the project. The task queue described in the present application can be a template. When using it, it is necessary to specify the task data structure it stores, and then instantiate it into an object variable for use. Therefore, calling the methods of this variable can achieve the asynchronous data storage and retrieval of the task queue.

[0158] For the foregoing method embodiments, for the sake of simple description, they are all expressed as a series of action combinations. However, those skilled in the art should be aware that the present application is not limited by the described action sequence, because according to the present application, certain steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the present application.

[0159] In the embodiments of the present application disclosed above, the method has been described in detail. The method of the present application can be implemented by means of various forms of devices. Therefore, the present application also discloses a device, and specific embodiments are given below for detailed description.

[0160] Figure 5 The following is a schematic structural diagram of an access device for a task queue disclosed in an embodiment of the present application. The task queue is a singly linked list, and each node therein includes a first storage area for storing a first smart pointer and a second storage area for storing a second smart pointer. The first smart pointer is used to store a task data unit pointer, and the second smart pointer is used to store a node pointer of the next node. Refer to Figure 5 As shown, the access device 50 of the task queue may include:

[0161] A request acquisition module 501, configured to acquire an access request for the task queue.

[0162] A lock addition determination module 502, configured to determine whether a mutex lock needs to be added based on the access request.

[0163] A lock addition operation module 503, configured to, when a mutex lock needs to be added, lock the head mutex lock and / or the tail mutex lock of the task queue; acquire the head node and / or the tail node, and perform an access operation related to the access request.

[0164] A direct operation module 504, configured to directly execute an access operation based on the access request when a mutex lock does not need to be added.

[0165] In the access solution of the task queue of the present application, the head and tail of the task queue have independent mutex locks and can be locked independently. Therefore, operations of storing and acquiring data can be performed simultaneously, improving the speed of data interaction; at the same time, smart pointers are used to store data structures, which can save the copying of data space and save CPU and memory resources.

[0166] Any one of the access devices for the task queue in the above embodiments includes a processor and a memory. Modules such as the request acquisition module, lock determination module, lock operation module, and direct operation module in the above embodiments are stored in the memory as program modules, and the processor executes the above program modules stored in the memory to implement corresponding functions.

[0167] The processor contains a kernel, and the kernel retrieves the corresponding program module from the memory. One or more kernels can be set, and the processing of return visit data is achieved by adjusting the kernel parameters.

[0168] The memory may include non-permanent memory in a computer-readable medium, in the form of random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. The memory includes at least one storage chip.

[0169] In an exemplary embodiment, a computer-readable storage medium is also provided, which can be directly loaded into the internal memory of a computer and contains software code. After the computer program is loaded and executed by the computer, it can implement the steps shown in any one of the above-described access methods for the task queue.

[0170] In an exemplary embodiment, a computer program product is also provided, which can be directly loaded into the internal memory of a computer and contains software code. After the computer program is loaded and executed by the computer, it can implement the steps shown in any one of the above-described access methods for the task queue.

[0171] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The same or similar parts among the various embodiments can be referred to each other. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method part.

[0172] It should also be noted that in this article, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "comprises", "comprising" or any other variation thereof is intended to cover a non-exclusive inclusion, such that a process, method, article or device comprising a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "comprising an..." does not exclude the presence of additional identical elements in the process, method, article or device comprising the element.

[0173] The steps of the methods or algorithms described in connection with the embodiments disclosed herein may be implemented directly in hardware, in a software module executed by a processor, or in a combination thereof. The software module may be placed in a random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0174] The foregoing description of the disclosed embodiments enables those skilled in the art to make or use the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Thus, the present application is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for accessing a task queue, characterized in that: The task queue is a one-way linked list, each node of which includes a first storage area for storing a first smart pointer and a second storage area for storing a second smart pointer, the first smart pointer is used to store a task data unit pointer, and the second smart pointer is used to store a node pointer of a next node, and the method includes: Obtaining an access request for the task queue; Determining whether a mutex lock needs to be added based on the access request; If the mutex lock needs to be added, the head mutex lock and / or the tail mutex lock of the task queue are locked; the head node and / or the tail node are obtained, and the access operation related to the access request is performed; If the mutex does not need to be added, the access operation is directly performed based on the access request.

2. The method for accessing a task queue according to claim 1, characterized in that: Also includes: Obtaining a control request for the task queue; A corresponding control operation is performed based on the control request.

3. The method for accessing a task queue according to claim 1, characterized in that: The access request is a request for obtaining task data, and the request for obtaining task data needs to add a mutex lock, and the head mutex lock and / or the tail mutex lock of the task queue are locked; Obtaining the head node and / or tail node, and performing access operations related to the access request, including: Lock the head node mutex of the task queue, and lock the tail node mutex of the task queue; Determine whether the task queue is empty; If the task queue is empty, an empty node is fed back; If the task queue is not empty, the head node data is returned.

4. The method for accessing a task queue according to claim 1, characterized in that: The access request is a request for blocking waiting task data, the head mutex of the task queue is locked and / or the tail mutex is locked; the head node and / or the tail node are obtained, and the access operation related to the access request is performed, including: Lock the head node mutex of the task queue, and lock the tail node mutex of the task queue; Determine whether the task queue is empty; If the task queue is empty and the task queue is in a running state, the data condition variable is used to block and wait until a notification of the data condition variable is received, and then the head node data is returned; If the task queue is not empty, directly return the head node data; If the task queue is in a stopped state, an empty node is returned.

5. The method for accessing a task queue according to claim 3 or 4, characterized in that: Determining whether the task queue is empty includes: Get the tail node data; Determining whether the head node and the tail node of the task queue are the same node based on the tail node data; If so, determining that the task queue is empty; If not, it is determined that the task queue is not empty.

6. The method for accessing a task queue according to claim 3 or 4, characterized in that: The returning the head node data includes removing the head node from the task queue and returning the first smart pointer of the head node, including: Assigning the head node to a first temporary smart pointer object; Assigning the second smart pointer of the first temporary smart pointer object to the head node pointer, where the head node pointer is a pointer pointing to the head node; Returns the first temporary smart pointer object.

7. The method for accessing a task queue according to claim 1, characterized in that: The access request is a request to write task data to the task queue, and the head mutex of the task queue is locked and / or the tail mutex is locked; Obtaining the head node and / or tail node, and performing access operations related to the access request, including: Receive the target smart pointer object; Create a new smart pointer object, where the new smart pointer object is an empty node; Locking the task queue's / or tail mutex; Assign the target smart pointer object to the first storage area of ​​the current tail node; Assign the data in the first storage area of ​​the new smart pointer object to the temporary node pointer; Assigning the new smart pointer object to the second storage area of ​​the current tail node; The temporary node pointer is assigned a value as a tail node pointer, where the tail node pointer is a pointer pointing to the tail node.

8. The method for accessing a task queue according to claim 7, characterized in that: After assigning the temporary node pointer to the tail node pointer, the method further includes: A notification message is sent using a data condition variable to notify the blocked waiting subject that new data has been added to the task queue.

9. The method for accessing a task queue according to claim 1, characterized in that: The task queue includes an operation status identifier, and the operation status identifier is used to indicate the operation status of the task queue.

10. A task queue access device, characterized in that: The task queue is a one-way linked list, each node of which includes a first storage area for storing a first smart pointer and a second storage area for storing a second smart pointer, the first smart pointer is used to store a task data unit pointer, and the second smart pointer is used to store a node pointer of a next node, and the device includes: A request obtaining module, used for obtaining an access request for the task queue; A lock determination module, used to determine whether a mutex lock needs to be added based on the access request; A locking operation module, used to lock the head mutex and / or the tail mutex of the task queue when a mutex needs to be added; obtain the head node and / or the tail node, and perform access operations related to the access request; The direct operation module is used to directly perform the access operation based on the access request without adding a mutex lock.

Images