[Fwd: [Boost-Users] Deadlocking problems with recursive_mutex on Linux with boost 1.29.0]

From: William E. Kempf (wekempf_at_[hidden])
Date: 2002-12-05 12:06:54

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_at_[hidden]>
Date: Thu, December 5, 2002 10:02 am
To: wekempf_at_[hidden]

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_at_[hidden]>
Date:
Wed, 04 Dec 2002 17:13:15 -0700
To:
Boost-Users_at_[hidden]

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.26&content-type=text/x-cvsweb-markup&cvsroot=glibc

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