Shulou(Shulou.com)06/02 Report--

This article mainly explains "what are the matters needing attention in C++ multithreaded debugging and testing". The content in the article is simple and clear, and it is easy to learn and understand. Now please follow the editor's train of thought slowly and deeply. Let's study and learn what matters needing attention in multithreading debugging and testing of C++!

I. about setting breakpoints and stepping through

Many students rely heavily on the breakpoint function and single-step function of the debugger. This is fine in the single-threaded case (although some single-threaded programs that involve GUI can also be a bit of a hassle). As for the debugging of multithreaded programs, these two methods are the beginning of a nightmare. The main problems caused by multithreading are mostly related to race conditions (Race Condition, see "here" for a detailed explanation).

Setting breakpoints or single-step tracing can seriously interfere with the state of competition between multithreads. What you see is an illusion. For example, there are two threads executing concurrently, and there are some discordant Bug (caused by race). Once you set a breakpoint on a thread, the thread stops at the breakpoint, leaving only another thread running. At this point, the concurrency scenario has been completely destroyed, and what you see through the debugger may be a harmonious scene.

Digress a little bit. This is very similar to the "uncertainty principle" of quantum mechanics, in which the observation behavior of the observer interferes with the measured object, causing the observer to see a phenomenon after interference.

II. About Log output

Since breakpoints and single steps don't work. What are we going to do? One alternative is to output log logs. It can effectively reduce the side effects caused by breakpoints and single steps.

1. The problem of traditional Log mechanism

Traditional log output is mainly printed to the screen or output to a file. For C++, the classes and functions built into the standard library (such as cout, printf, fputs) may have thread safety issues (related to the specific implementation of the compiler). In particular, the eight global objects in the Standard flow Class Library (iostream) should be used with caution. If the output is light, the log text is mixed, and if it is too heavy, it will cause the program to crash.

For the above reasons, you should try to use the log mechanism built into the third-party thread library to handle the log output function. Such as ACE built-in ACE_Log_Msg and so on.

2. Log functions should be short and concise.

In many cases, we wrap a common function to implement the log output function. Then the log class / function of the thread library is called inside the function. In order not to affect the race condition of the thread, the log function should be as simple and portable as possible: don't involve too much trivia, don't do time-consuming operations, and try not to manipulate some global variables.

3. Side effects of Log

However, no matter how short the log function is, it is still possible to affect race conditions (after all, log also has overhead and consumes CPU time).

If the race condition is affected by log, it will be tricky. I have encountered this situation before: with log added, there is no problem with the program; without log, the program crashes randomly. There are generally two possibilities for this situation: either there is something wrong with the log function itself, or the program's race condition is very sensitive (even the cost of log can affect it).

At this time, all you can rely on is the naked eye and the human brain. First take a close look at the relevant code and documentation several times (* * and then find other experienced people to Code Review together), and then use your brains to think hard.

III. About Debug version and Release version

C++ programs often differ between the Debug version and the Release version. Sometimes, this can lead to multithreading problems.

Because the Debug version contains some debugging information and enables some debugging mechanisms (such as assert macros). So it may affect the competitive state of multithreading. In bad luck, the Debug version will work properly and the Release version of the program will crash randomly. To avoid this situation, consider the following two ways:

1. Abandon the use of Debug version

You can simply give up using the Debug version. In this case, you need to consider replacing debugging-related macros such as assert with your own set of macros that work in non-Debug versions.

2. Synchronous testing of the two versions

Using this method, programmers can test themselves with the Debug version, but testers must test the Release version on a daily basis. Specific steps can be assisted by daily builds (see "here" for an introduction to daily builds). Be sure to avoid: only test the Debug version at ordinary times, and wait until the eve of the release to make the Release version. This kind of practice is very dangerous!

About the testing machine (hardware)

Say something that you have experienced and impressed.

When developing cross-platform programs with ACE, the development environment and test environment in the company were single CPU machines. Because the multi-core machine was not available at that time, and the multi-CPU machine was very expensive, the company was not willing to spend money on configuration.

After the software development, the testers did not find much problem after several rounds of regression testing. But when running in a customer's environment, it often collapses randomly. Because they can't Debug in the customer environment, and their own environment is fine, several people on the development team have to give full play to the functions of the naked eye and human brain (staring at code and design documents). After a long time, I almost broke my head, and then I realized how CPU the customer's machine was. Then quickly borrowed a multi-CPU machine from other departments, installed software debugging, * found that there was a problem with a third-party library. After this, I immediately came up with various ways to apply for several multi-CPU machines for testers to use.

Because of the above lessons, I strongly recommend that if you are developing multithreaded applications, try to configure every programmer and tester with a multi-core / multi-CPU machine. After all, multi-core machines are very popular now, and even multi-CPU machines are affordable. There is really no need to introduce development risk to save that little money (not only will it waste the developer / tester's time, but may also increase the cost of implementation and maintenance).

Thank you for your reading. The above is the content of "what are the matters needing attention in C++ multithreaded debugging and testing?" after the study of this article, I believe you have a deeper understanding of the matters needing attention in C++ multithreaded debugging and testing, and the specific use still needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.