John Maddock said:
One thing that confuses me... how does this even compile on Linux? If the pthread_mutexattr_settype function is available to the compiler/linker, why on earth would it not function properly? Definately need to do some research.
Also, if you have a simple test case that reproduces the deadlock it would be beneficial for you to send it to me for addition to the test harness.
Since then everything is working quite perfectly!
But I'd like to raise some questions: * Is my assumption correct that Linux doesn't have a proper support for recursive POSIX mutexes?
This is a really dumb question, but you did compile everything with -pthread didn't you? Without that it will compile and link - but only to a thread unsafe "stub" runtime. Or at least I think that's what happens :-(
That may well be what's happening here. So there may be a third alternative to those I gave before: the documentation is incorrect, pthread_mutexattr_settype does exist and does work properly, and the boost::recursive_mutex does behave properly, and we've got a simple user error.
BTW don't the regression tests already test the recursive mutexes? (the tests are passing at the moment).
Yes, they do, and yes they are passing, but I was not discounting that the tests might not be thorough enough to catch a race condition in the implementation. That's why I asked for a test case that would reproduce his deadlock. William E. Kempf