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

5 Dec 2002

      ...
...
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
...
...
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
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 
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 
Date:
Wed, 04 Dec 2002 17:13:15 -0700
To:
Boost-Users@yahoogroups.com

William E. Kempf wrote:

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.
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