Using The Posix Threads Api Effectively; Mutex Types - Valgrind Software Quick Start Manual

• 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
started.
• If DRD reports any errors on libraries that are part of your Linux distribution like e.g.
libstdc++.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.
DRD: a thread error detector
Getting
libc.so or
134