Re: Boost.Threads draft library submission

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