Deadlocking problems with recursive_mutex on Linux with boost 1.2 9.0
Hi I experienced a lot of deadlocking situations when I used recursive_mutex on SuSE Linux 8.1. When I analysed this mutex code I found out, that the implementation of recursive_mutex on Linux is based on recursive POSIX mutexes (set with pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE)). Things were getting interesting when I didn't find a man page for this function and I started to suspect Linux not having implemented this mutex type. The next thing I had done was to disable recursive POSIX mutexes by commenting out the line "#define BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE" in the file boost_1_29_0/boost/config/posix_features.hpp" forcing boost to implement recursive_mutex by itself. 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? * Can I expect that this problem will be solved in a future release of boost? Regards Beat
Hi
I experienced a lot of deadlocking situations when I used recursive_mutex on SuSE Linux 8.1. When I analysed this mutex code I found out, that the implementation of recursive_mutex on Linux is based on recursive POSIX mutexes (set with pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE)). Things were getting interesting when I didn't find a man page for this function and I started to suspect Linux not having implemented this mutex type.
The next thing I had done was to disable recursive POSIX mutexes by commenting out the line "#define BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE" in the file boost_1_29_0/boost/config/posix_features.hpp" forcing boost to implement recursive_mutex by itself.
Interestingly enough, the manpages indicate that Linux has a pthread_mutexattr_setkind_np that does the same thing as pthread_mutexattr_settype. I'm not a POSIX programmer, so I'm feeling my way around blindly with some of these more esoteric optional and/or new features. I'm not sure how to correctly detect the availability here, and to configure accordingly. I'll have to research this particular case for a fix. If anyone knows how to fix the configuration here, please speak up. 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?
It has support, evidently, possibly just not "proper" support. (Or maybe it does have proper support that's just not documented and we have an implementation problem on my end?)
* Can I expect that this problem will be solved in a future release of boost?
Definately. As soon as I determine how best to address the problem, it will be fixed in CVS. William E. Kempf
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 :-( BTW don't the regression tests already test the recursive mutexes? (the tests are passing at the moment). John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm
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
participants (1)
-
beat.schaer＠ruag.com -
John Maddock -
William E. Kempf