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_NORMAL, PTHREAD_MUTEX_ERRORCHECK and
> PTHREAD_MUTEX_RECURSIVE. I'm still trying to determine if these
> types are universally acceptable or if there will be
implementations
> 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
checking?
> 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.
Thanks,
Bill Kempf