Server design-Message Queuing

The simplest message queue we can think of may be implemented using the STL list, which is to maintain a list and a mutex inside the message queue, putmessage a message to the end of the queue, and getmessage a message back from the queue header. Both GetMessage and Putmessage are required to acquire the lock resource first.

Although the implementation is simple, but the function is absolutely satisfied with the requirements, but the performance may be slightly less than satisfactory. Its biggest problem is in the frequent lock competition.

For the optimization of how to reduce the number of lock competitions, Ghost Cheng proposed a. Provides a queue container with multiple queues, each fixed to hold a certain number of messages. When a network IO thread posts a message to a logical thread, it takes an empty queue from the queue container to be used until the queue is filled and then put back into the container for another empty queue. When the logical thread fetches the message, it fetches a message queue from the queue container, empties the queue and puts it back into the container after processing.

This allows locking only when operations are performed on the queue container, and the IO thread and logical threads do not need to be locked when manipulating the queue they are currently using, so the chances of lock contention are greatly reduced.

The maximum number of messages is set for each queue, which seems to be intended to be placed back into the container for another queue only if the IO thread is fully queued. That sometimes happens. IO threads are not filled with a queue, and logical threads have no data to handle, especially when the amount of data is small. Ghost Cheng doesn't talk about how to solve this problem in his description, but we can take a look at another scenario first.

This scenario is basically similar to the previous scenario, except that the queue container is no longer available because only thetwo queues, Arthur described the implementation of the scheme and some of its code in one of his e-mails.two queues, one for logical threads to read, one for IO threads to write, when the logical thread reads the queue, it swaps its own queue with the queue of the IO thread. Therefore, this scheme to lock more times, the IO thread each write queue to lock, logical threads in the Exchange queue also need to lock, but logical threads in the read queue does not need to lock.

Although it seems that the number of locks is much more than the previous one, the fact that most lock calls do not cause blocking is that only the moment the logical thread swaps the queue can cause a thread to block. In addition, for the lock call process itself, its overhead is completely negligible, we can not stand only because of the lock call caused by blocking.

Server design-Message Queuing