Considerations for C + + multithreaded debugging and testing

In one program, these stand-alone program fragments are called " Threads"(Thread), the concept of programming using it is called" MultithreadingProcessing ". With threads, the user presses a button, and the program responds immediately, rather than having the user wait for the program to complete the current task before it starts responding.

In the Last post, I talked about the cross-platform problem of C + + multithreading , and then I didn't feel like it. Today by the way, there are some considerations for debugging and testing when developing a C + + multithreaded application. The following considerations are primarily for C + +, although some are applicable to other languages as well.

I. About setting breakpoints and stepping

Many students rely heavily on the debugger's breakpoint functionality and single-step functionality. This is fine in a single-threaded situation (but some single-threaded but GUI-related programs can be a bit cumbersome). As for the debugging of multi-thread, these two methods are simply the beginning of nightmare. The main problems caused by multithreading are mostly related to race conditions (Race Condition, detailed explanations of "here").

setting breakpoints or single-step tracking can seriously interfere with the competitive state between multiple threads. Cause what you see is an illusion. For example, there are two threads executing concurrently, there are some discordant bugs (caused by race state). Once you set a breakpoint on one thread, the thread stops at the breakpoint, leaving only the other thread running. At this point, the concurrency scenario is completely destroyed, and what you see through the debugger can be a harmonious scene.

Run a little bit, please. This is similar to the "uncertainty principle" of quantum mechanics, where the observed behavior of the observer interferes with the object being measured, causing the observer to see an interference phenomenon.

Second, about the log output

Since breakpoints and single steps are not good for you. What do you pinch? An alternative is to output the log log. It can effectively mitigate the side effects of breakpoints and single steps (for race conditions).

1. The problem of the traditional log mechanism

The traditional log output is mainly printed to the screen or output to a file. For C + +, the standard library's built-in classes and functions (such as cout, printf, fputs) can be a thread-safe issue (related to the compiler's specific implementation). In particular, the standard Flow class library (iostream) eight global objects, it is prudent to use caution. The output of the log text is mixed, and heavy causes the program to crash.

For these reasons, you should try to use the third-party line libraries built-in log mechanism to handle the log output function. For example, Ace built-in ace_log_msg.

2. Log function should be short and concise

In many cases, we will wrap a common function to implement the log output function. The Log class/function of the line libraries is then called inside the function. In order not to affect the race condition of the thread, this log function should be as simple and light as possible: do not involve too much assorted trivia, do not take time-consuming actions, try not to manipulate some global variables.

3. Log Side effects

However, even if the log function is short and short, it is still possible to influence the race condition (after all, log also has overhead and consumes CPU time).

In case the race condition is affected by log, it is tricky. I have encountered this situation before: Add log, the program is not a problem, remove the log, the program randomly crashes. This can happen in two ways: either the log function itself is problematic, or the program's race condition is very sensitive (even the cost of the log will be affected).

The only thing you can rely on is the naked eye and the human brain. First look at the relevant code and documentation carefully several times (it is best to find other experienced people with code Review), and then we all open their brains to ponder.

Third, about the debug version and release version

C + + programs often have the difference between the debug version and release version. Sometimes, this can also lead to some multithreading problems.

Because the debug version contains some debugging information, some debugging mechanisms (such as Assert macros) are enabled. So it may affect the multi-threaded competitive state. In the unfortunate time, will encounter debug version is working normally, release version program randomly crashes. To avoid this situation, consider the following two options:

1, discard the use of debug version

You can simply give up using the debug version. In this case, you need to consider replacing debug-related macros, such as Assert, with your own set of macros, which can also take effect in non-debug versions.

2, two versions of synchronization test

Using this method, the programmer can use the debug version for self-test, but the tester must be the release version for routine testing. The specific steps can be assisted with daily builds (see "Here" for an introduction to the daily build). Be sure to avoid: In peacetime only debug version of the test, wait until the release version before the launch. This practice is very dangerous!

Iv. Machines for testing (hardware)

Say a personal experience, an impressive thing.

When using ACE to develop cross-platform programs, the company's development environment and testing environment are single-CPU machines. Because at that time multicore machine is not available, multi-CPU machine is very expensive, the company is not willing to spend money to allocate.

After the software development, the testers after several rounds of regression testing, also did not find too much problem. But it runs in the environment of the customer, but it often crashes randomly. Because you can't debug in a customer environment, and your environment is no problem, several people in the development team have to give full play to the visual and human brain functions (staring at Code and design documents). After n long time, almost the head to break, finally realized that the customer's machine is multi-CPU. Then hurriedly from other departments borrowed a multi-CPU machine, loaded with software debugging, finally found that a third-party library has a problem. After this, I immediately came up with a variety of ways to apply for a number of multi-CPU machines for testers.

As a result of this precedent, I strongly recommend that if you are developing multithreaded applications, try to configure multicore/multi-CPU machines for every programmer and tester. After all, multi-core machines are already popular, even if the number of CPUs of the machine, the price is also passable. There's really no need to introduce development risk in order to save a little bit of money (not only to waste dev/tester time, but also to increase the cost of implementation and maintenance)

Considerations for C + + multithreaded debugging and testing