Valgrind BBV, Быстрый старт

Страница: 146 / 319

DRD: a thread error detector
• Compile with option
-O1
instead of
-O0
. This will reduce the amount of generated code, may reduce the amount
of debug info and will speed up DRD’s processing of the client program. For more information, see also Getting
started .
• If DRD reports any errors on libraries that are part of your Linux distribution like e.g. libc.so or
+.so
, installing the debug packages for these libraries will make the output of DRD a lot more
detailed.
• When using C++, do not send output from more than one thread to
std::cout
. Doing so would not only generate
multiple data race reports, it could also result in output from several threads getting mixed up. Either use
printf
or do the following:
1. Derive a class from
std::ostreambuf
and let that class send output line by line to
stdout
. This will avoid
that individual lines of text produced by different threads get mixed up.
2. Create one instance of
std::ostream
for each thread. This makes stream formatting settings thread-local.
Pass a per-thread instance of the class derived from
std::ostreambuf
to the constructor of each instance.
3. Let each thread send its output to its own instance of std::ostream instead of std::cout .
8.3. Using the POSIX Threads API Effectively
8.3.1. Mutex types
The Single UNIX Specification version two defines the following four mutex types (see also the documentation of
pthread_mutexattr_settype
):
• normal , which means that no error checking is performed, and that the mutex is non-recursive.
• error checking , which means that the mutex is non-recursive and that error checking is performed.
• recursive , which means that a mutex may be locked recursively.
• default , which means that error checking behavior is undefined, and that the behavior for recursive locking is also
undefined. Or: portable code must neither trigger error conditions through the Pthreads API nor attempt to lock a
mutex of default type recursively.
134