Multi-thread message queue implementation method and system

Abstract

The invention discloses a multi-thread message queue implementation method and system, and the method comprises the steps: recording thread information corresponding to a thread of a to-be-sent or to-be-received message into a blocking thread chain table of a corresponding message queue when the message needs to be sent to the message queue or the message needs to be received from the message queue, recording the relative time of the system as the first relative time in the recorded thread information; under the condition that the message can be sent to the message queue or the message can be received, removing thread information corresponding to the message which can be sent or received from the blocked thread chain table; or, removing the thread information from the blocked thread chain table under the condition of judging overtime according to the current relative time of the system and the first relative time recorded in the thread information. According to the scheme, on one hand, the defects of two types of traditional POSIX and System V message queues on a timeout mechanism are overcome; and on the other hand, more convenient positioning is realized by using the blocked thread chain table.

Description

Technical Field

[0001] The embodiments of the present application relate to but are not limited to the field of communication technology, and in particular to a method and system for implementing a multi-threaded message queue. Background Art

[0002] A message queue can be considered as a linked list of messages, which allows processes to exchange data in the form of messages with a specific format and priority. Currently, there are two main types of message queues: POSIX (Portable Operating System Interface of UNIX, a process communication mechanism based on the POSIX standard, and a general term for a series of interrelated standards that define APIs for running software on various UNIX or UNIX-like systems by IEEE) and System V. Messages in a POSIX message queue have an associated priority in the queue, and messages are stored and transmitted strictly in order of priority; messages in a System V message queue have an integer type, and messages can be selected in various ways through the receiving API.

[0003] On distributed network devices, the defects of the two message queues are mainly reflected in the timeout mechanism of the message queue. The receiving and sending of the POSIX message queue have the same attributes, that is, it can only send and receive, and it is blocked or non-blocking at the same time. In the POSIX technical standard, the time used for timeout sending and timeout receiving is the absolute time ABS_TIMEOUT. This leads to the fact that in systems that require clock synchronization, after the operator performs time calibration for the network equipment or the equipment automatically synchronizes the time, the timeout mechanism cannot be used correctly, resulting in the system not being able to run normally according to the designed process; System V message queues do not support the timeout mechanism for receiving and sending. Summary of the invention

[0004] The following is a summary of the subject matter described in detail herein. This summary is not intended to limit the scope of the claims.

[0005] The embodiments of the present application provide a multi-threaded message queue implementation method and system, which implements a new message queue implementation scheme, solves the problem of inaccurate timeout mechanism in some cases caused by the use of absolute time in traditional POSIX type message queues, and solves the problem that System V type message queues cannot perform timeout judgment, and conveniently locates the problem, which can reduce the maintenance work of multi-threaded systems.

[0006] An embodiment of the present application provides a multi-threaded message queue implementation method, including: when a message needs to be sent to a message queue or a message needs to be received from a message queue, the thread information corresponding to the thread to be sent or received is recorded in the blocked thread list of the corresponding message queue, and the relative time of the system at this time is recorded in the recorded thread information as a first relative time; when a message can be sent to the message queue or a message can be received, the thread information corresponding to the message that can be sent or received is removed from the blocked thread list; or, when a timeout is determined based on the current relative time of the system and the first relative time recorded in the thread information, the thread information is removed from the blocked thread list.

[0007] An embodiment of the present application also provides a multi-threaded message queue implementation system, including: a memory and a processor; the memory is used to store a program for implementing a multi-threaded message queue; the processor is used to read the program for implementing a multi-threaded message queue and execute the multi-threaded message queue implementation method as described in any embodiment of the present application.

[0008] Compared with the related art, the embodiment of the present application provides a new multi-threaded message queue implementation method and system. When a message needs to be sent to a message queue or a message needs to be received from a message queue, the thread information corresponding to the thread to be sent or received is recorded in the blocked thread list of the corresponding message queue, and the relative time of the system at this time is recorded in the recorded thread information as the first relative time; when a message can be sent to a message queue or a message can be received, the thread information corresponding to the message that can be sent or received is removed from the blocked thread list; or, when the timeout is determined according to the current relative time of the system and the first relative time recorded in the thread information, the thread information is removed from the blocked thread list. The message queue implementation scheme, on the one hand, when sending a message to a message queue or receiving a message from a message queue, determines whether it is timed out by relative time, solves the defects of the traditional POSIX and System V types of message queues in the timeout mechanism, and can better determine whether it is timed out; on the other hand, the thread information of sending or receiving messages is recorded through the blocked thread list, so that when blocking occurs, it is more convenient to locate the problem and reduce the maintenance work of the multi-threaded system.

[0009] Other features and advantages of the present application will be described in the following description, and partly become apparent from the description, or be understood by implementing the present application. Other advantages of the present application can be realized and obtained by the schemes described in the description and the drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The accompanying drawings are used to provide an understanding of the technical solution of the present application and constitute a part of the specification. Together with the embodiments of the present application, they are used to explain the technical solution of the present application and do not constitute a limitation on the technical solution of the present application.

[0011] Figure 1 This is a flowchart of a method for implementing a multi-threaded message queue according to an embodiment of the present application; Figure 2 A flowchart for creating and initializing a message queue for an embodiment of the present application; Figure 3 A flowchart of sending a message to a message queue according to an embodiment of the present application; Figure 4 A flowchart of receiving a message from a message queue according to an embodiment of the present application; Figure 5 A flowchart of querying the number of messages in a message queue according to an embodiment of the present application; Figure 6 A flowchart for checking the message queue status for an embodiment of the present application; Figure 7 A flowchart of deleting and releasing a message queue in an embodiment of the present application; Figure 8 This is a schematic diagram of a multi-threaded message queue implementation system according to an embodiment of the present application. DETAILED DESCRIPTION

[0012] The present application describes multiple embodiments, but the description is exemplary rather than restrictive, and it is obvious to those skilled in the art that there may be more embodiments and implementations within the scope of the embodiments described in the present application. Although many possible feature combinations are shown in the drawings and discussed in the specific embodiments, many other combinations of the disclosed features are also possible. Unless specifically limited, any feature or element of any embodiment may be used in combination with any other feature or element in any other embodiment, or may replace any other feature or element in any other embodiment.

[0013] The present application includes and contemplates combinations of features and elements known to those of ordinary skill in the art. The embodiments, features and elements disclosed in the present application may also be combined with any conventional features or elements to form a unique invention scheme. Any features or elements of any embodiment may also be combined with features or elements from other invention schemes to form another unique invention scheme. Therefore, it should be understood that any feature shown and / or discussed in the present application may be implemented individually or in any appropriate combination. Therefore, except for the limitations made according to the attached claims and their equivalents, the embodiments are not subject to other restrictions. In addition, various modifications and changes may be made within the scope of protection of the attached claims.

[0014] In addition, when describing representative embodiments, the specification may have presented the method and / or process as a specific sequence of steps. However, to the extent that the method or process does not rely on the specific order of the steps described herein, the method or process should not be limited to the steps of the specific order described. As will be understood by those of ordinary skill in the art, other sequences of steps are also possible. Therefore, the specific sequence of the steps set forth in the specification should not be interpreted as a limitation to the claims. In addition, the claims for the method and / or process should not be limited to the steps of performing them in the order written, and those skilled in the art can easily understand that these sequences can be changed and still remain within the spirit and scope of the embodiments of the present application.

[0015] First, we will take the POSIX message queue as an example to explain the problem of the timeout mechanism. According to the POSIX message queue standard, "The timeout shall expire when the absolute time specified by abs_timeout passes, as measured by the clock on which timeouts are based (that is, when the value of that clock equals or exceeds abs_timeout), or if the absolute time specified by abs_timeout has already been passed at the time of the call", etc., we can see that the POSIX message queue uses absolute time and the standard cannot be changed. This means that the timeout will expire when the absolute time specified by abs_timeout passes, which is measured by the clock on which the timeout is based (that is, when the value of that clock equals or exceeds abs_timeout), or if the absolute time specified by abs_timeout has already been passed at the time of the call. Therefore, when the network device performs time calibration or device automatic time synchronization (SNTP), the timeout mechanism of the POSIX message queue will not work properly.

[0016] An embodiment of the present application provides a multi-threaded message queue implementation method, such as Figure 1 As shown, the following steps may be included: Step S110: when a message needs to be sent to a message queue or a message needs to be received from a message queue, the thread information corresponding to the thread to be sent or received is recorded in a blocked thread list of the corresponding message queue, and the relative time of the system at this time is recorded in the recorded thread information as a first relative time; Step S120: When a message can be sent to the message queue or a message can be received, the thread information corresponding to the message that can be sent or received is removed from the blocked thread list; or, when a timeout is determined based on the current relative time of the system and the first relative time recorded in the thread information, the thread information is removed from the blocked thread list.

[0017] The multi-threaded message queue implementation method of this embodiment records the thread information corresponding to the thread to be sent or received into the blocked thread list of the corresponding message queue when a message needs to be sent to the message queue or a message needs to be received from the message queue, and records the relative time of the system at this time as the first relative time in the recorded thread information; when a message can be sent to the message queue or a message can be received, the thread information corresponding to the message that can be sent or received is removed from the blocked thread list; or, when a timeout is determined based on the current relative time of the system and the first relative time recorded in the thread information, the thread information is removed from the blocked thread list. The multi-thread message queue implementation method, on the one hand, is not based on the traditional POSIX and System V types of message queue implementations, but customizes a new message queue implementation method, so that when sending a message to a message queue or receiving a message from a message queue, it can be determined whether a timeout has occurred by relative time, thereby solving the problem of inaccurate timeout mechanism in some cases caused by the use of absolute time in the traditional POSIX, and the problem that System V cannot perform timeout judgment, and can better determine whether a timeout has occurred; on the other hand, the thread information corresponding to the thread to be sent or to be received is recorded through the blocked thread linked list, so that when blocking occurs, the problem can be more conveniently located, thereby reducing the maintenance work of the multi-thread system.

[0018] Exemplarily, the multi-threaded message queue implementation method can be applied to Linux, but can also be applied to other systems without limitation.

[0019] In an exemplary embodiment, each message queue is identified by a message queue number; sending a message to a message queue or receiving a message from a message queue includes: The message queue to which the message is to be sent or the message queue for receiving the message is specified according to the message queue number.

[0020] In an example of this embodiment, the message queue can be implemented based on a message queue management structure, which is a brand-new message queue management structure customized by this application. The message queue management structure may include: a message queue number; in this way, each message queue corresponds to a message queue number, and the message queue to which the message is to be sent or the message queue for receiving the message can be specified by the message queue number.

[0021] Exemplarily, the message queue number corresponding to each message queue is automatically allocated by the system after the message queue is created and initialized.

[0022] The message queue implementation method of this embodiment uses a message queue number to identify each message queue, so that the message queue to which the message is to be sent or the message queue for receiving the message can be specified by the message queue number to complete the sending or receiving of the message.

[0023] In an exemplary embodiment, determining the timeout according to the current relative time of the system and the first relative time recorded in the thread information includes: For each message queue, periodically determine whether a message can be sent to the message queue or whether the message queue can be received. If not, obtain the relative time of the system at this time as the second relative time; For each thread information, the time difference between the acquired second relative time and the first relative time recorded in the thread information is calculated respectively, and whether the thread information has timed out is determined based on a comparison result between the time difference and a preset timeout duration.

[0024] Exemplarily, the message queue management structure may further include: a preset timeout period; a user may set the preset timeout period in the above embodiment through the "preset timeout period" field in the message queue management structure.

[0025] It can be specifically seen from this embodiment that the multi-threaded message queue implementation method of this embodiment is to obtain the first relative time of the system before judging that the corresponding message queue cannot add the message to be sent or no message can be received; each time it is judged that the corresponding message queue cannot add the message to be sent or no message can be received, obtain the second relative time of the system; in this way, it is possible to judge whether the sending or receiving message has timed out by the second relative time and the first relative time. Since this solution is based on a brand-new message queue implementation, and is not based on the traditional POSIX and System V types of message queues, it solves the problem of inaccurate timeout mechanism in some cases caused by the use of absolute time in traditional POSIX type message queues, and the problem that System V type message queues cannot perform timeout judgment, and can better judge whether it has timed out.

[0026] In an exemplary embodiment, when a message can be sent to a message queue or a message can be received, after removing thread information corresponding to the message that can be sent or received from a blocked thread list of the message queue, the method further includes: Get the mutex semaphore of the corresponding message queue; Determine whether the corresponding message queue has been deleted. If the message queue has not been deleted, add the message to the corresponding message queue or receive the message from the corresponding message queue, and release the mutex semaphore after completion. When the message queue has been deleted, a message sending failure or a message receiving failure is fed back to the corresponding thread, and the mutex semaphore is released.

[0027] Exemplarily, the message queue management structure may also include: a mutex semaphore and a delete mark; when the message queue is implemented based on the message queue management structure, the "mutually exclusive semaphore" field of the message queue management structure corresponds to the mutex semaphore of the message queue in the above embodiment, and the "deletion mark" field of the message queue management structure can be used to determine whether the message queue is deleted.

[0028] The message queue implementation method of this embodiment uses a mutex semaphore before and after determining whether the corresponding message queue has been deleted, ensuring that only one task can access shared resources at any time, thereby avoiding the occurrence of race conditions and ensuring the accuracy of the acquired information.

[0029] In an exemplary embodiment, each piece of thread information in the blocked thread linked list corresponds to a first identification information; the first identification information is used to identify that the corresponding thread information is a thread corresponding to a message to be sent or a message to be received.

[0030] It should be noted that, in the present application, each message queue stores thread information corresponding to threads to be sent or received messages through a blocked thread linked list, and then uses the first identification field to distinguish whether the stored information is "thread information corresponding to threads to be sent messages" or "thread information corresponding to threads to be received messages". However, in actual use, two blocked thread linked lists can also be used to store thread information corresponding to threads to be sent or received messages respectively, and the present application does not limit this.

[0031] The message queue implementation method of this embodiment records the thread information corresponding to the thread to be sent or received through the blocked thread linked list, so that the problem can be more easily located when blocking occurs. For example, when the message queue is full and multiple tasks are blocked waiting to send messages to the message queue, it is easy to know which tasks are blocked in sending messages, and then infer whether these tasks have caused the normal execution of other tasks (for example, after a task obtains a mutex semaphore, it is always blocked here, which may cause other tasks to fail to obtain the semaphore and fail to execute).

[0032] In an exemplary embodiment, the message queue management structure may further include: blocked thread information, the blocked thread information being the blocked thread linked list described in the above embodiment. Exemplarily, each piece of information in the blocked thread linked list includes: a preset timeout duration, a thread address, and a first identification information.

[0033] In an exemplary embodiment, adding the message to the corresponding message queue includes: obtaining a node from the head of an unoccupied message linked list of the corresponding message queue; storing the message in the node, and mounting the node to the occupied message linked list; The receiving of the message from the corresponding message queue includes: obtaining a node from the head of the occupied message linked list of the corresponding message queue; reading the message stored in the node, and mounting the node to the tail of the unoccupied message linked list after the reading is completed; The node corresponds to a memory storing the message.

[0034] Exemplarily, the message queue management structure may further include: an occupied message linked list and an unoccupied message linked list.

[0035] The message queue implementation method of this embodiment realizes the function of the message queue through a single linked list, has good portability, and can greatly reduce the development and maintenance work of the multi-threaded system. The solution has strong scalability, high efficiency, and good software and hardware reusability.

[0036] In an example of this embodiment, mounting the node to an occupied message linked list includes: Determine whether the message stored in the node is an emergency message; When the message is an emergency message, the node is mounted to the head of the occupied message linked list; when the message is a non-emergency message, the node is mounted to the tail of the occupied message linked list.

[0037] It can be seen from this embodiment that the message queue implementation method of this embodiment also supports setting the urgency of the message, and the processing order of the messages can be controlled according to the urgency of the message.

[0038] In an exemplary embodiment, after adding a message to a corresponding message queue or receiving a message from a corresponding message queue, the method further includes: The number of existing messages, the number of received message resources, and the number of sent message resources of the corresponding message queue are updated.

[0039] Exemplarily, the message queue management structure may also include: the number of existing messages, the number of received message resources, and the number of sent message resources.

[0040] The message queue implementation method of this embodiment updates the number of existing messages, the number of received message resources, and the number of sent message resources of the corresponding message queue after a message is sent to the corresponding message queue or a message is received from the corresponding message queue, so that it can be determined based on the above information that the corresponding message queue can add messages to be sent or messages can be received, thereby avoiding errors.

[0041] Exemplarily, the "number of existing messages in the message queue" can be progressively increased / decreased when the message queue is accessed. The "number of received message resources" corresponds to a first counting semaphore of a sending resource, and the change of the "number of received message resources" can be achieved by monitoring the change of the first counting semaphore (for example, the number of received resources is implemented using a counting semaphore, and the number of received resources count is automatically reduced by 1 after the semaphore is successfully taken, and the number of received resources count is automatically increased by 1 after the semaphore is successfully released). Similarly, the number of sending resources also corresponds to a second technical semaphore of a sending resource, and the change of the "number of sent message resources" can be achieved by monitoring the second counting semaphore. The implementation related to technical semaphores can refer to the existing technology.

[0042] In an exemplary embodiment, determining whether a message can be sent to a message queue includes: determining whether the message queue can add a message to be sent according to the number of message sending resources of the corresponding message queue and the length of the message queue; when the number of message sending resources is less than the length of the message queue, determining that the message can be sent to the message queue; when the number of message sending resources is equal to the length of the message queue, determining that the message cannot be sent to the message queue; Determine whether a corresponding message queue has a message that can be received, including: determining whether the message queue has a message that can be received based on the number of received message resources of the corresponding message queue; when the number of received message resources is greater than 0, determine that the message queue has a message that can be received; when the number of received message resources is equal to 0, determine that the message queue has no message that can be received.

[0043] Exemplarily, the message queue management structure may further include: a message queue length; the message queue length indicates the maximum number of messages that the message queue can accommodate.

[0044] The message queue implementation method of this embodiment, when sending a message to a message queue or receiving a message from a message queue, first determines whether the corresponding message queue can add a message to be sent or has a message to be received. If the corresponding message queue can add a message to be sent or has a message to be received, the message is sent or received; if the corresponding message queue cannot add a message to be sent or has no message to be received, the thread information is blocked to wait. Through the above design, data confusion, loss, etc. can be avoided, and the accuracy of message sending and receiving can be ensured.

[0045] In an exemplary embodiment, the method further includes: obtaining information of the corresponding message queue through the message queue number identifier. Exemplarily, when the message queue is implemented based on the above-mentioned message queue management structure, all information stored in the message queue management structure can be obtained. In this way, the status of the corresponding message queue, blocked thread information, etc. can be known through the above-mentioned information, so as to facilitate further operations. For example, after a long period of blocking occurs, the blocked thread information can be obtained, and then the cause of the blocking can be located according to the blocked thread information.

[0046] It can be seen from the above embodiments that the present application defines a new message queue management structure, and the message queue implementation method of the present application can be implemented through the message queue management structure. It should be understood that the message queue implementation method of the present application is not limited to the message management structure, and any solution based on the design concept of the message queue implementation method of the present application should be within the protection scope of the present application.

[0047] In summary, the present application implements a new message queue management structure and a message queue implementation method, which can solve the problem of inaccurate timeout mechanism in some cases caused by the use of absolute time in traditional POSIX, and the problem that System V cannot perform timeout judgment, and can locate the problem more conveniently, and has strong scalability, high efficiency, and good software and hardware reusability.

[0048] The following describes in detail the method for implementing the multi-threaded message queue of the present application by using the message queue management structure in the above example as an example.

[0049] The first part introduces the above message queue management structure.

[0050] Exemplarily, the message queue management structure may include properties such as magic words, message queue name, message queue number, code location for creating a message queue, message queue length (also known as the maximum number of messages in the message queue), message length supported by the message queue (also known as the maximum length of each variable-length message in the message queue), message queue options, message queue mutex semaphore (also known as message queue protection semaphore), number of receiving message resources, number of sending message resources, message queue blocked thread information, number of existing messages in the message queue, message queue deletion mark, message queue memory pool, occupied message linked list and unoccupied message linked list.

[0051] The description of each attribute in the message queue management structure can be as follows: Magic word, used to verify whether it is a message queue; Message queue number, used to identify a unique message queue; The message queue name is used to manage the message queue. It is highly readable and easy for users to understand and use. The code location where the message queue is created is used to quickly locate the problem and find the corresponding code segment; The message queue length is used to identify the maximum number of messages in the message queue; The maximum length of each variable-length message in the message queue, used to identify the message length supported by the message queue (in bytes); Message queue options, used to identify message queue queuing rules, first-in-first-out and priority; Message queue mutual exclusion semaphore, used to protect the critical resources of the message queue from mutual exclusion access; The number of received message resources is used to identify the number of occupied message resources. When the number is 0, it means that the message queue is empty and there are no messages that can be received. The number of sent message resources is used to identify the number of available message resources. When this number is the maximum number of messages in the message queue, it indicates that the message queue is full and messages cannot be sent to the message queue. The thread information blocked by the message queue is used to record the thread information waiting for the message queue to facilitate problem location; The number of existing messages in the message queue is used to record the number of messages that can be received in the message queue at present; Message queue deletion mark, used to mark whether the message queue has been deleted; The message queue memory pool is used to allocate the memory pool used by the message queue when creating a message queue according to the message queue length and the maximum length of each variable-length message. After the memory application is completed, the memory pool is formatted according to "chain list header + actual message length record + maximum length of each variable-length message", and then attached to the unoccupied message chain list one by one; The unoccupied message linked list is used when all message queue memories are attached to the linked list after they are created and initialized. When a message is sent to a message queue, a node is taken from the linked list, and after the message is sent and processed, it is attached to the occupied message linked list. The occupied message linked list is used when it is just created and initialized. The linked list is empty. When a message is received from the message queue, a node is taken from the linked list, and after the received message is processed, it is put back to the unoccupied linked list.

[0052] Exemplarily, the code of the message queue management structure may be as follows: typedef struct MSGQ_TASK_INFO_S { BOOL isSend; / *TRUE means sending, FALSE means receiving* / pthread_t taskID; / *thread address* / int timeout; / *timeout* / } MSGQ_TASK_INFO_T; typedef struct MSGQ_S { int magic; / *magic word* / int msgQID; / *Message queue number* / char msgQName

[16] ; / *message queue name* / char msgQLocation

[16] ; / *Code location for creating message queue* / int maxMsgNum; / *Message queue length* / int maxMsgLen; / *Message length supported by the message queue (in bytes)* / int options; / *Message queue options* / SEM_ID semLock; / *Message queue mutual exclusion semaphore: protect the critical resources of the message queue from mutual exclusion access* / SEM_ID semRcvCnt; / *Number of message receiving resources: receive blocking is achieved through this semaphore* / SEM_ID semSndCnt; / *Number of message sending resources: Send blocking is achieved through this semaphore* / MSGQ_TASK_INFO_T taskInfo; / *Message queue blocked thread information* / int msgNum; / *Number of existing messages in the message queue* / int isDelete; / *Message queue deletion mark* / char *msgPool; / *Message queue memory pool* / SL_LIST msgQ; / *occupied message list* / SL_LIST freeQ; / *Unoccupied message list* / } MSGQ_T; typedef MSGQ_T* MSG_Q_ID; As can be seen from the above structure, a timeout field can be set for each thread information through the timeout field. Of course, if it is not set, a default value can also be given, and there is no limitation on this.

[0053] The second part is to create and initialize the message queue. The implementation process of this part can refer to Figure 2 .

[0054] The interface of the second part can be int msgq_create_os(char *msgQName, intmaxMsgNum, int maxMsgLen, int options, char *file, int line); the input fields of this interface include msgQName (representing the message queue name), maxMsgNum (representing the message queue length), maxMsgLen (representing the maximum number of bytes of each message, that is, the maximum length of each variable-length message in the message queue), options (representing message queue options), file (representing the name of the message queue file to be created), and line (representing the line number of the message queue file to be created); the output is empty; and the message queue number msgQID of the message queue is returned when the creation is successful, and an error message is returned when the creation fails.

[0055] The second part provides the system with a unified interface for creating and initializing message queues. When creating a message queue, specify the message queue name, the code location for creating the message queue, the message queue length, the maximum length of each variable-length message in the message queue, and the thread queuing method, and return the message queue number. There are no messages in the newly created message queue, and it is in an empty state; sending or receiving messages to the message queue will increase or decrease the number of messages. When the number reaches the maximum length of the message queue, the message queue is in a full state; when the message queue is between the empty state and the full state, it is in a non-empty state.

[0056] The third part is sending messages to the message queue. The implementation process of this part can refer to Figure 3 .

[0057] The interface of the third part can be int msgq_send_os(MSG_Q_ID msgQID, char *buffer, int bufferLen, int timeout, int priority); the input fields of the interface include: msgQID (representing the message queue number), buffer (representing the buffer used to send messages, the user applies for space), bufferLen (representing the maximum message length that the buffer used to send messages can receive), timeout (representing the sending timeout, the unit can be milliseconds ms), priority (representing the priority, which can include NORMAL and URGENT priorities); the output is empty; and a success mark is returned when the creation is successful, and an error message is returned when the creation fails.

[0058] The third part provides the system with a unified interface for sending messages to message queues. When sending messages to a specified message queue, the message queue number, message length, message memory, timeout and priority are specified. If the number of message resources is available and the message is sent successfully within the specified timeout, success is returned.

[0059] When multiple threads send messages to the message queue, these messages are queued on the message queue. The messages pass through the message queue in FIFO order. When the priority is NORMAL, the new message is inserted at the tail of the message queue. When the priority is URGENT, the message is inserted at the head of the message queue.

[0060] When the message queue is full, the thread will block and wait for space in the message queue to be freed. The timeout period gives the time the thread waits for the timeout. The timeout period is calculated using the relative time of system startup (CLOCK_MONOTONIC) (the time elapsed after the system is started, which is initialized to 0 each time the system is started). This solves the problem caused by system time calibration or automatic time synchronization when the device uses absolute time (CLOCK_RAELTIME). The timeout period can include NO_WAIT, WAIT_FOREVER and timeout. Before the timeout, once the thread has the opportunity to send a message to the queue, it will exit the blocking state; if it has not been sent successfully until the timeout, the thread will exit the blocking state, delete the sending thread information from the blocked thread list and return an error.

[0061] When sending a message to a specified message queue, first record the sending thread information to the blocked thread list, then block and wait for the number of message sending resources to be available. After the resources are available, delete the sending thread information from the blocked thread list. In this way, when checking the message queue status, you can know what threads are queued on the message queue. After obtaining the message queue mutex semaphore, you can first check whether the message queue has been deleted, which can ensure the robustness of the system.

[0062] The fourth part is receiving messages from the message queue. The implementation process of this part can refer to Figure 4 .

[0063] The interface of the fourth part can be int msgq_receive_os(MSG_Q_ID msgQID, char *buffer, int bufferLen, int timeout); the input fields of the interface include: msgQID (representing the message queue number), buffer (representing the buffer used to receive messages, the user applies for space), bufferLen (representing the maximum message length that the buffer used to receive messages can receive), timeout (representing the timeout period, the unit can be milliseconds ms); output buffer (representing the buffer used to receive messages, the user applies for space), bufferLen (representing the maximum message length that the buffer used to receive messages can receive); and return a success mark when the creation is successful, and return an error message when the creation fails.

[0064] The fourth part provides the system with a unified interface for receiving messages from a message queue. When receiving a message from a message queue, the message queue number, the length of the received message, the memory for receiving the message and the timeout period are specified, and the message length and the message memory are returned.

[0065] When the message queue is not empty, the first message in the message queue will be taken out immediately. The timeout period gives the time when the thread receives the waiting timeout (i.e., the preset timeout period described in the above embodiment). Like the timeout period for sending messages, the timeout period is calculated using the relative time of system startup (CLOCK_MONOTONIC) (the time elapsed after the system is started, which is initialized to 0 each time the system is started). This solves the problem of system time calibration or automatic time synchronization when the device uses absolute time (CLOCK_RAELTIME). Before the timeout, the receiving thread will be blocked on the receiving queue of the message queue. The threads on the receiving queue are queued according to the queuing rules specified when the message queue is created. When the message queue receives a message, it will be directly sent to the first thread on the receiving queue.

[0066] When receiving a message from a message queue, the receiving thread information is first recorded in the blocked thread list, and then blocked to wait for the number of resources to receive the message to be available. After the resources are available, the receiving thread information is deleted from the blocked thread list. In this way, when checking the message queue status, you can know what threads are queued on the message queue. After obtaining the message queue mutex semaphore, you can first check whether the message queue has been deleted to ensure the robustness of the system.

[0067] The fifth part is to query the number of messages in the message queue. The implementation process of this part can refer to Figure 5 .

[0068] The interface of the fifth part may be msgq_msgNum_os (MSG_Q_ID msgQId), which is used to query the number of messages in a specified message queue; the input fields of the interface include: msgQID (representing the message queue number); and when the query is successful, the number of messages in the queried specified message queue is returned, and when the query fails, an error message is returned.

[0069] The fifth part provides the system with the function of querying the number of messages in the message queue. When querying the number of messages in the message queue, the message queue number is specified and the number of messages in the message queue is returned. This function can be called to monitor the number of messages in the message queue in real time.

[0070] The sixth part is to check the message queue status. The implementation process of this part can refer to Figure 6 .

[0071] The interface of the sixth part may be int msgq_show_os(MSG_Q_ID msgQId), which is used to query the status of a specified message queue. The input fields of the interface include: msgQID (representing the message queue number). A success flag is returned when the query is successful, and an error message is returned when the query fails.

[0072] The sixth part provides the system with a unified interface for viewing the message queue status. When viewing the message queue status, specify the message queue number and return information such as the message queue number, message queue name, code location for creating the message queue, maximum number of messages in the message queue, maximum length of each variable-length message in the message queue, message queue options, and threads blocked by the message queue.

[0073] The seventh part, delete and release the message queue, the implementation process of this part can refer to Figure 7 : The interface of the seventh part may be STATUS msgq_delete_os (MSG_Q_ID msgQID), which is used to delete a specified message queue. The input fields of the interface include: msgQID (representing the message queue number); and a success flag is returned when the query is successful, and an error message is returned when the query fails.

[0074] The seventh part provides the system with a unified interface for deleting and releasing message queues. When deleting and releasing a message queue, specify the message queue number to automatically delete and release the message queue. After the release is completed, the threads blocked on the sending queue and the receiving queue will be awakened, and the message queue number will no longer be useful.

[0075] In summary, the present application provides a method for implementing a multi-threaded system message queue, which implements functions such as creating and initializing a message queue, sending messages to a message queue, receiving messages from a message queue, querying the number of messages in a message queue, checking the status of a message queue, deleting and releasing a message queue, etc. It can solve the defects of the timeout mechanism of the POSIX message queue and the System V message queue, and use the relative time after the device is started instead of the absolute time to implement the timeout mechanism. In a system requiring clock synchronization, the operator can also correctly use the timeout mechanism after performing time calibration for the network device or automatic time synchronization of the device, so that the system can run normally according to the designed process. The present application is applied in a distributed network device based on multi-threading, and uses a single linked list and a semaphore to implement the function of the message queue, and does not rely on the system POSIX message queue and the System V message queue, which solves the defects of the timeout mechanism of the prior art, has good portability, and can greatly reduce the development and maintenance of the multi-threaded system.

[0076] An embodiment of the present application provides a multi-threaded message queue implementation system, such as Figure 8 As shown, it includes: a memory and a processor; The memory is used to store a program for implementing a multi-threaded message queue; The processor is used to read the program for implementing the multi-threaded message queue and execute the multi-threaded message queue implementation method as described in any embodiment of the present application.

[0077] In summary, the multi-threaded system message queue implementation method and system of the present application realize a new multi-threaded message queue implementation scheme. On the one hand, the timeout mechanism can be implemented by using the relative time after the device is started instead of the absolute time, which solves the defects of the traditional POSIX message queue and System V message queue in the timeout mechanism; on the other hand, the thread information of sending or receiving messages is recorded by the blocked thread linked list, so that the problem can be located more conveniently when blocking occurs, reducing the maintenance work of the multi-threaded system; and the multi-threaded message queue implementation scheme of the present application has strong scalability, high efficiency, and good software and hardware reusability.

[0078] It will be appreciated by those skilled in the art that all or some of the steps, systems, and functional modules / units in the methods disclosed above may be implemented as software, firmware, hardware, and appropriate combinations thereof. In hardware implementations, the division between the functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed by several physical components in cooperation. Some or all components may be implemented as software executed by a processor, such as a digital signal processor or a microprocessor, or implemented as hardware, or implemented as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable medium, which may include a computer storage medium (or non-transitory medium) and a communication medium (or transient medium). As is known to those skilled in the art, the term "computer storage medium" includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer. In addition, it is well known to those skilled in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

[0079] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example" or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, without contradiction.

[0080] Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and cannot be understood as limitations on the present application. Ordinary technicians in this field can change, modify, replace and modify the above embodiments within the scope of the present application.

Claims

1. A multi-threaded message queue implementation method, characterized in that: include: When a message needs to be sent to a message queue or a message needs to be received from a message queue, thread information corresponding to the thread to be sent or received is recorded in a blocked thread list of the corresponding message queue, and the relative time of the system at this time is recorded in the recorded thread information as a first relative time; When a message can be sent to the message queue or a message can be received, the thread information corresponding to the message that can be sent or received is removed from the blocked thread list; or, when a timeout is determined based on the current relative time of the system and the first relative time recorded in the thread information, the thread information is removed from the blocked thread list.

2. The multi-threaded message queue implementation method according to claim 1, characterized in that: In the case where a message can be sent to the message queue or a message can be received, after removing the thread information corresponding to the message that can be sent or received from the blocked thread list of the message queue, the method further includes: Get the mutex semaphore of the corresponding message queue; Determine whether the corresponding message queue has been deleted. If the message queue has not been deleted, add the message to the corresponding message queue or receive the message from the corresponding message queue, and release the mutex semaphore after completion. When the message queue has been deleted, a message sending failure or a message receiving failure is fed back to the corresponding thread, and the mutex semaphore is released.

3. The multi-threaded message queue implementation method according to claim 2, characterized in that: The adding of the message to the corresponding message queue comprises: obtaining a node from the head of the unoccupied message linked list of the corresponding message queue; storing the message in the node, and mounting the node to the occupied message linked list; The receiving of the message from the corresponding message queue includes: obtaining a node from the head of the occupied message linked list of the corresponding message queue; reading the message stored in the node, and mounting the node to the tail of the unoccupied message linked list after the reading is completed; The node corresponds to a memory storing the message.

4. The multi-thread message queue implementation method according to claim 3, characterized in that: The step of mounting the node to the occupied message linked list includes: Determine whether the message stored in the node is an emergency message; When the message is an emergency message, the node is mounted to the head of the occupied message linked list; when the message is a non-emergency message, the node is mounted to the tail of the occupied message linked list.

5. The multi-thread message queue implementation method according to claim 2, characterized in that: After adding the message to the corresponding message queue or receiving the message from the corresponding message queue, the method further includes: The number of existing messages, the number of received message resources, and the number of sent message resources of the corresponding message queue are updated.

6. The multi-thread message queue implementation method according to claim 5, characterized in that: Determining whether a message can be sent to a message queue includes: determining whether the message queue can add a message to be sent according to the number of sending message resources of the corresponding message queue and the length of the message queue; when the number of sending message resources is less than the length of the message queue, determining that the message can be sent to the message queue; when the number of sending message resources is equal to the length of the message queue, determining that the message cannot be sent to the message queue; Determine whether a corresponding message queue has a message that can be received, including: determining whether the message queue has a message that can be received based on the number of received message resources of the corresponding message queue; when the number of received message resources is greater than 0, determine that the message queue has a message that can be received; when the number of received message resources is equal to 0, determine that the message queue has no message that can be received.

7. The multi-thread message queue implementation method according to claim 1, characterized in that: The determining of timeout according to the current relative time of the system and the first relative time recorded in the thread information includes: For each message queue, periodically determine whether a message can be sent to the message queue or whether the message queue can be received. If not, obtain the relative time of the system at this time as the second relative time; For each thread information, the time difference between the acquired second relative time and the first relative time recorded in the thread information is calculated respectively, and whether the thread information has timed out is determined based on a comparison result between the time difference and a preset timeout duration.

8. The multi-thread message queue implementation method according to claim 1, characterized in that: Each piece of thread information in the blocked thread linked list corresponds to a first identification information; the first identification information is used to identify that the corresponding thread information is a thread corresponding to a message to be sent or a message to be received.

9. The multi-thread message queue implementation method according to claim 1, characterized in that: Each message queue is identified by a message queue number; sending a message to a message queue or receiving a message from a message queue comprises: The message queue to which the message is to be sent or the message queue for receiving the message is specified according to the message queue number.

10. A multi-threaded message queue implementation system, comprising: A memory and a processor; characterized in that: The memory is used to store a program for implementing a multi-threaded message queue; The processor is used to read the program for implementing the multi-threaded message queue and execute the multi-threaded message queue implementation method as described in any one of claims 1 to 9.

Images