Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-03-16 13:15:34

--- In boost_at_y..., williamkempf_at_h... wrote:
> --- In boost_at_y..., terekhov_at_y... wrote:
> > --- In boost_at_y..., williamkempf_at_h... wrote:
> > the checks are only needed (if at all) in debug mode.
> > POSIX threads standard (and coming SUS) does have recursive mutex.
> OK, POSIX defines three attributes that deal with this:
> PTHREAD_MUTEX_RECURSIVE. I'm still trying to determine if these
> types are universally acceptable or if there will be
> that don't support some of the options here. If they were
> universally available it might help to simplify some things.
> Unfortunately, it won't help with the boost::recursive_mutex. It
> seems that the recursive mutex is not recommended for use with
> condtion variables "because the implicit unlock performed for a
> pthread_cond_wait() or pthread_cond_timedwait() will not actually
> release the mutex (if it had been locked multiple times)." The
> Boost.Threads implementation deals with this and allows for proper
> usage.

On further thought, it would be trivial to allow the recursive_mutex
implemented with a PTHREAD_MUTEX_RECURSIVE type to work with the
condition. So the only barrier to a MUCH better implementation here
is the availability of this pthread extension. For instance, the
pthread-win32 port does not allow for these three types as far as I
can tell. If anyone knows any better about this please let me know.

I'm also curious to hear what people think about boost::mutex using
checked locking semantics. Is the overhead here worth it considering
the added safety and that there's a fast_mutex that doesn't do

> If there's a pthreads expert that wants to tackle the issue of the
> implementation here I'd be more than willing to work with them to
> resolve this.

I'm still hoping someone speaks up about this as well.

Bill Kempf

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