hang and/or segfault when using boost::threads from matlab, not when called directly hang and/or segfault when using boost::threads from matlab, not when called directly multithreading multithreading

hang and/or segfault when using boost::threads from matlab, not when called directly


Are you sure that's the simplest case that segfaults and/or hangs? If the results from DRD do indicate a race condition just between thread construction and joining, it sounds like your code might not be at fault (especially since you don't actually use any mex-specific features, but just running under mex triggers the bug).

Maybe try just this version:

#include <boost/thread.hpp>void doNothing() { return; }void doWork() {    boost::thread t1(doNothing);    t1.join();}#ifdef NO_MEXint main() {#else#include "mex.h"void mexFunction(int nlhs, mxArray **plhs, int nrhs, const mxArray **prhs) {#endif    doWork();}

This definitely shouldn't segfault or hang either under mex or compiled directly - so if it does, it's not your bug, and if it doesn't, maybe you can progressively close the distance between your version and this one to find the bug-causing addition.


There is a point of failure in your code: When any thread is delayed by more than 2 seconds, the timed_lock call in the lock constructor can time out, the mutex is not acquired, and you access the protected structure anyway. If you use timed mutexes, you'll have to test whether the lock actually locked the mutex or merely timed out. This can be checked by calling the locks' owns_lock() method.

I don't see any motivation for the timed mutexes here, and you mention "after taking out the timed thread stuff", but I still suspect this mutex timeout bug to be at fault here. Does this bug still occur when you replace timed_mutex with plain mutex?