Pits notes for multi-threaded programs and the rules that multithreading should follow

These days, a friend in the group paid me to get his program stabilized, because it is on-site management project, need to do no duty, so even the client, also can not often down machine, because before his program had a night field view, the basic process has a general understanding, I will next.

At first, the program runs less than a morning, memory spikes, sometimes a few hours to hang, this night found, found a half-day to find a load of pictures of the Tmemorystream not released.

I didn't expect to have a lot of holes to fill.

Solve it and see how many pits there are!

First day: He told me that his connection to the database is always exceeded the number, will cause the program can not handle the task, the same night with DIOCP3 in the basequeue made a light ADO connection pool, because Basequeue did a lot of testing, So this ADO connection pool after a simple test even if OK, then a lot of heavy labor work.

Next day: After the connection pool is switched on, the connection problem is gone, but the thread pool cannot handle the task. He used to be called Uthreadpool Unit, the code is very complex. I recommend him to use Qwokers, because qwokers I have been in use, very stable, mission delivery is very simple, then a think, he is D7, no way to use such a good class library, no way, had to iocptask on. Iocptask DIOCP3 in a task Post library, is a similar qworker library, but only the task delivery and execution of the function, compared to qworker is too simple, but with iocpengine stability should also be good. After the change, I went on to write the changes to Iocptask, enhanced debugging information, it is easy to see the current status of the worker thread, and the status of the task execution.

Because he said the thread pool is a problem, I think it must be stuck in which task, then when the card is dead, I see it.

The following is the status information for the Iocptask output,

Post counter:10000001Response counter:10000001Error Counter:0active:true, worker Count:5-----------------------Woker1--------------------thread ID:9664, Response count:1719388Busying:false, Waiting:true, reserved:true request State Info:runInMainThread:False, Done:true, Time (ms):0-----------------------Woker2--------------------thread ID:6680, Response count:2010817Busying:false, Waiting:true, reserved:true request State Info:runInMainThread:False, Done:true, Time (ms):0-----------------------Woker3--------------------thread ID:4956, Response count:1965637Busying:false, Waiting:true, reserved:false request State Info:runInMainThread:False, Done:true, Time (ms):0-----------------------Woker4--------------------thread ID:8304, Response count:2641407Busying:false, Waiting:true, reserved:false request State Info:runInMainThread:False, Done:true, Time (ms):0-----------------------Woker5--------------------thread ID:9528, Response count:1662752Busying:false, Waiting:true, reserved:false request State Info:runInMainThread:False, Done:true, Time (ms):0

Because it's the project on GitHub, I used the e-text annotation and e-text information, Chinglish, all understand, a little explanation,

Post counter:10000001 // represents the number of tasks posted

Response counter: 10000001 //Number of responses

Error Counter: 0 //Delivery Failure Quantity

Here are some information about the worker threads, the thread ID, the number of tasks that are handled by the response,

The following States are more critical

The true word of busying is that the delegate is performing the task, wating is waiting, reserved is representing the resident worker thread

If busying is true, the currently executing task information is followed, and if the task is executing the maximum number of threads in such a thread pool, the new task cannot be processed. Led to what happened to his program. This can be based on the information of the task to find the corresponding process, to narrow the scope of query problems.

Request State Info: If the task has comment information, it will be displayed here

Runinmainthread: Whether the task is performed on the main thread, done: whether the task is completed, time (ms): is the duration of the task consumed.

With the Iocptask the pit was soon found.

found that the original critical use a lot, resulting in the task of deadlock ...,

It's going to be a critical pit tomorrow.

The third day: His program critical use of flooding, the current entry is not critical, causing the task hangs, but not the current critical problem, because there are other tasks into the critical no exit. So to find the front of the critical, the critical class reformed.

Can see the current information of the critical, I have also made the corresponding upgrade Iocplocker

function TIocpLocker.getDebugINfo:String; begin   Result:= Format ('%s:busycount:%d, try:%s, enter:%s', [self]. FName, Getentercount, Ftryenterinfo, Fenterinfo]); End;

You can get the critical name, enter the number of threads trying to enter the critical, try to enter the critical information and the information that has entered the critical.

With this data, you can see that the critical information that the deadlock has entered is the culprit that caused the deadlock.

The fourth day: because the line thread face the UI too much access, you can use the Iocptask thread in the UI access part of the way through the delivery task to the main thread to complete the work, which is also a labor.

Serious on his program to improve, and explain the multi-threaded programming need to pay attention to the place < later will summarize, although the following program also write Bugs. He was very happy to pay the money, said that even if the program is also worth the problem, through this pits exchange know to pay attention to a lot of places. This is the biggest affirmation of my work.

Summarize:

Through the pits and the past DIOCP group of some friends of the problem and practice, I listed the next multi-thread programming needs to follow a few points, I hope to be helpful to everyone:

1. Child threads do not access the main thread of the UI, (Memo,label), I found that this is a lot of programmers, in DIOCP often used in the Onconnected/ondisconnected event to directly manipulate the main form of memo. Causes the program to fail to exit normally, or the situation of the card-dead main interface, I think can be summed up in the access to the conflict above, with the critical also does not solve the problem. Many of the components are Windows message-driven, so he doesn't use parts to process messages, so there's no way. You only have to honestly deliver to the main thread to complete this part of the work, Qworker and Iocptask can do a good job.

2. Access shared resources between threads need to use a critical, do not have multiple threads at the same time to deal with the same variable, or list, or wait for a variety of problems.

3. The database connection should be done with the connection pool as much as possible, which can reduce the connection and avoid the use of multiple threads for the same connection.

Of course there are a lot of small problems that need to be noticed.

Pits notes for multi-threaded programs and the rules that multithreading should follow