Question

I have a program where I use boost::threads for multi threading. Unfortunately drd (valgrind --tool=drd ./my_program) reports lot of problems about 10000.

I am not sure if I misunderstood something of boost thread. I try to find out my error for hours but did not get much further, therefore any help would be appreciated.

I try to pipeline certain filters and want to be able to run them by calling the last filter with run. This filter should then first call all his precursor filter which he depend on and in the end call his processQueue() methode.
I want now to be able to call precursor filters in their won thread, so that I get a speed up if the graph as parallel paths. Therefore I added the threadgroup, so that each precursor filter is executed in his own thread. But unfortunately I get a lot of race conditions where I am not sure where they result from.
I hope now it is more clear what I want to achieve.

Update

I have updated the code to a even simpler code where the problem still occurs. I think the problem is somewhere related to the thread generation.

Update 2

I think the main reason for these is a very high false positive rate of valgrind. I have opened a new question about this. See here

Update 3

most of the errors could be avoided when I use valgrind 3.6.1 instead of 3.7.0 or 3.8.0.

Here one report of drd:

==29905== Conflicting load by thread 1 at 0xb0081000 size 8
==29905==    at 0x25A6C2: pthread_join (in /usr/lib/system/libsystem_c.dylib)
==29905==    by 0x2BEC0: boost::thread::join() (in /usr/local/lib/libboost_thread.dylib)
==29905==    by 0x100006641: Filter::run() (in ./playgroudThreads)
==29905==    by 0x100001013: main (in ./playgroudThreads)
==29905== Allocation context: unknown.
==29905== Other segment start (thread 2)
==29905==    at 0x2A7B68: thread_start (in /usr/lib/system/libsystem_c.dylib)
==29905== Other segment end (thread 2)
==29905==    at 0x3E667A: mach_msg_trap (in /usr/lib/system/libsystem_kernel.dylib)
==29905==    by 0x3DED38: semaphore_create (in /usr/lib/system/libsystem_kernel.dylib)
==29905==    by 0x2A50F7: new_sem_from_pool (in /usr/lib/system/libsystem_c.dylib)
==29905==    by 0x2A6199: _pthread_exit (in /usr/lib/system/libsystem_c.dylib)
==29905==    by 0x2A48C9: _pthread_start (in /usr/lib/system/libsystem_c.dylib)
==29905==    by 0x2A7B74: thread_start (in /usr/lib/system/libsystem_c.dylib)

And here my example code:

#include <iostream>
#include <vector>
#include <sys/time.h>
#include <boost/thread.hpp>
#include <boost/bind.hpp>

class Filter
{
    public:

        Filter(int n) :
                n_(n), precursor_(0)
        {
        }

        ~Filter()
        {
        }

        void connect(Filter& f)
        {
            precursor_ = &f;
        }

        void run()
        {

            if (!isCalculationDone_) {
                if (precursor_) {
                    boost::thread thread(&Filter::run, precursor_);

                    thread.join();
                }
                this->processQueue(2);
                isCalculationDone_ = true;

            }

        }

        void processQueue(unsigned N)
        {
            //do some calculations

        }

    public:
        int n_;
        Filter* precursor_;

        bool isCalculationDone_;

};

int main(int argc, char* argv[])
{

    Filter* f1 = new Filter(1);
    Filter* f2 = new Filter(2);

    f2->connect(*f1);

    f2->run();

    std::cerr << "main: done" << std::endl;
    delete f2;
    delete f1;
    return 0;

}
;

Answer 1

You’re not alone: see the thread here, which suggests the problem is a false positive “probably caused by reuse of the memory for thread-local storage from a terminated thread by a newly created thread”.