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