Re: [Boost-Users] Deadlocking problems with recursive_mutex on Linux with boost 1.2 9.0

From: William E. Kempf (wekempf_at_[hidden])
Date: 2002-12-04 11:29:41

> 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