Boost logo

Boost :

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2004-07-13 12:48:27

On Jul 13, 2004, at 11:37 AM, Peter Dimov wrote:

> Howard Hinnant wrote:
> [...]
>> If the OS provides a mutex that is recursive without documenting that
>> fact, then that sounds like a docs bug to me. If I need a recursive
>> mutex, I will gladly use an OS-supplied one if I can find such a
>> beast. Otherwise I have to build it myself out of an OS-supplied
>> non-recursive mutex. If I find that I've ended up paying for
>> recursion overhead twice, or unnecessarily re-implemented recursive
>> mutexes for that platform, I'll send a bug report to the OS vendor.
> However in this case a recursive mutex has been provided by the OS,
> you just
> decided to not use it (in order to implement the recursive
> condition::wait).
> It seems that you have accepted the responsibility for the tradeoff.
> For
> some reason, it also seems that it's time for me to shut up.

Fwiw, imho, you're wrong on both counts. But I'll only address the
first: ;-)

Here's a little history of the Metrowerks::threads lib. For one, it is
fairly new, just released on Mac OS X last year. At that time, I
believe 10.2.x was current (can't remember for sure) and 10.2.x did
define PTHREAD_MUTEX_RECURSIVE, and I took advantage of that in
Metrowerks::recursive_mutex. I also realized at the time that there
might be some platforms on which I needed to support where
PTHREAD_MUTEX_RECURSIVE wouldn't be defined, and I punted on that (I
did not implement a recursive mutex, I downshifted to single thread
mode). This was a temporary solution, and I knew I would have to do a
better job before I really needed to ship on such a platform.

It turns out that I was wrong. Unknown to me was that 10.1.x did not
support PTHREAD_MUTEX_RECURSIVE. As I begin to receive these bug
reports, I implemented a recursive_mutex based on pthreads, and exposed
that implementation only when PTHREAD_MUTEX_RECURSIVE isn't defined.
We have not yet shipped this fix, and I'm not the right person to ask
for scheduling (I have no idea when it will ship).

It is my intention (whether I actually succeed or not is another
matter) that I use native recursive mutexes to implement
Metrowerks::recursive_mutex when they are provided. Otherwise I
implement Metrowerks::recursive_mutex using native non-recursive

With regards to native recursive mutexes, and their interaction with
condition::wait: This is a situation that has come to my attention
only with this thread, and I am grateful for that. This is one of the
reasons I participate in boost. It makes a better MSL (that's what we
call our library). I can report that for those platforms where native
recursive mutexes are not available, and thus I have emulated them, the
interaction with condition::wait works.

I hope that clarifies things. I feel I have not clearly communicated
in this thread and hope this post helps to rectify that.


Boost list run by bdawes at, gregod at, cpdaniel at, john at