I'm not sure if _XOPEN_SOURCE or _GNU_SOURCE are defined by the configuration headers or not. It does sound to me, however, like things may well be working on Linux properly and we might just have a user error. Again, can I get a test case for this in order to verify precisely what's wrong? Bill Kempf -------- Original Message -------- Subject: [Boost-Users] Deadlocking problems with recursive_mutex on Linux with boost 1.29.0 From: Dan Nuffer <dnuffer@sco.com> Date: Thu, December 5, 2002 10:02 am To: wekempf@cox.net Hmm, seems yahoogroups won't let me send an e-mail to boost-users, I guess I subscribed with a different e-mail addr, so I'll just send this directly to you. Subject: Re: [Boost-Users] Deadlocking problems with recursive_mutex on Linux with boost 1.2 9.0 From: Dan Nuffer <dnuffer@sco.com> Date: Wed, 04 Dec 2002 17:13:15 -0700 To: Boost-Users@yahoogroups.com William E. Kempf wrote:
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.
Linux definitely has the required functions/functionality. See http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/linuxthreads/mutex.c?rev=1... However, in the pthread.h header, the stuff is inside of: #ifdef __USE_UNIX98 To activate it, you should #define _XOPEN_SOURCE 500 or #define _GNU_SOURCE before you actually include anything (best to use -D cmd line arg).
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?)
Linux's implementation looks okay to me. However, it not documented in the man pages. If you have any other questions or anything I can help you out with wrt Linux, just let me know. --Dan William E. Kempf Booster (http://www.boost.org) Boost.Threads author