Multi-thread Program Design Based on Message distribution, common problems, and solutions

Most commercial software development requires some underlying modules that provide services for other modules. These underlying modules implement some common functions and need to provide functions for several high-level modules at the same time. Therefore, they are generally designed as a message queue-based framework. Any high-level module that needs to access these general functions can obtain the desired service by sending messages and receiving the returned values.

This architecture is generally designed around Message Queues: first, there is a message queue, and the API for sending messages is exposed; then a thread is responsible for maintaining and scheduling the message queue. This thread is responsible for maintaining the message queue and distributing messages. Finally, it is a series of functional modules for processing specific messages. Messages are sent to the Message Queue by APIs exposed to the outer module, and received by the scheduling thread and distributed to the message processing module. Then, the processing module processes different messages, return the processing result to the high-level module, which is a complete message queue-based public module. To achieve the scalability of this module, the message processing module generally adopts a registration-based design that allows users to register message processing functions for specific messages.

In terms of structure, this architecture is very complete and the module functions are well divided. Therefore, it is widely used. However, according to my personal experience, most of the implementation of such modules will have some minor flaws in the details.CodeThe maintenance and expansion of is troublesome. I have encountered 3 problems.

1. The message definition is not "Atomic ". A single function is considered to be split into several messages. For example, in a module that provides database access services for other modules, the record set is opened, the record set is obtained, and the closed record set is divided into three messages, because these three messages have a logical order relationship, and Message Processing does not guarantee this order relationship, resulting in the acquisition of the record set, the record set has been disabled, and so on. (because the record set may be large and needs to be obtained multiple times, this design is sometimes unavoidable ).

The only way to handle this situation is to ensure the order of message processing, such as synchronous messages. The client ensures that the previous message has been processed and the result has been returned before sending the second message.

2. The main thread receives the Exit message and begins to clean up memory resources. The message processing thread is still processing the message. In this case, the software reports an invalid memory access error, which is generally a crash problem.

To handle this situation, you must ensure that all other threads in the main thread wait have exited before cleaning. It is sometimes quite difficult to achieve this. One of my personal experiences is that the message processing thread is developed by other teams in the company. They create a thread pool when creating a message queue, this thread pool automatically calls a callback function that passed in the past to process messages. The thread pool destruction is also implemented in this module. The result is that in my module, after receiving the system Exit message, it is impossible to accurately detect whether all message processing threads have been aborted, whether resource cleaning can be started.

To implement a message queue-based architecture, you must process the scheduling relationships and logical sequence of multiple threads at the initial stage of design.

3. If the message queue-based module needs to access the database, there is a more annoying situation. In some database systems (ms SQL Server), nesting between Record Sets and transaction processing can corrupt the record set. In one case, the high-level module has the following requirements:

A.) query a data table. B.) Delete two records from another table.

The first requirement can be divided into three messages: Open the table, obtain the record set, and close the table. Because it does not change the database, you do not need to use transactions.

The second requirement can be simply packaged into a message. The transaction mechanism is required because the database is changed.

Because the order of message processing is not guaranteed, if the order of the above four messages is as follows:

Open Table 1 ---- Delete two records in Table 2 ---- retrieve records in Table 1 record set ---- close table 1

The operations in step 1 and Step 2 are normal, but in step 3, some databases report errors when getting the record set in table 1. Because the second step uses transactions, the transaction will destroy the record set opened before the same database connection. For details, refer to Microsoft's documentation:

Http://support.microsoft.com/default.aspx? SCID = KB; en-US; 187942

To solve this problem, one solution is to use the client side cursor recommended by Microsoft, which greatly reduces the database access performance.

Another solution is to allow query and transaction operations to use different database connections, which must be clearly defined at the beginning of the design.