threads/150889: PTHREAD_MUTEX_INITIALIZER + pthread_mutex_destroy() == EINVAL

John Baldwin jhb at freebsd.org
Thu Sep 23 21:41:12 UTC 2010


On Thursday, September 23, 2010 5:07:46 pm Jilles Tjoelker wrote:
> On Thu, Sep 23, 2010 at 03:41:51PM -0400, Christopher Faylor wrote:
> > I don't see how this represents buggy code.  It should be possible to
> > destroy a mutex which is allocated statically.  Currently, if a mutex is
> > assigned to PTHREAD_MUTEX_INITIALIZER and then used once, it can be
> > successfully destroyed.  It is only receive an EINVAL when there has
> > been no intervening call to any mutex function.  I don't think that a
> > PTHREAD_MUTEX_INITIALIZER using program should have to check for that.
> 
> One may want to destroy a mutex to help memory leak checkers and detect
> bugs, and then this is indeed a problem.
> 
> > However, regardless, this is still a bug in pthread_mutex_destroy right?
> 
> It is inconsistent at best.
> 
> It seems best to make the proposed change. This will allow
> pthread_mutex_destroy() on a destroyed mutex to succeed (which used to
> return EINVAL), but pthread_mutex_lock() already succeeded as well
> (initializing the mutex in the process).

Hmm, I think that POSIX actually require these to fail (ideally with EBUSY 
rather than EINVAL).  Presumably pthread_mutex_destroy() needs to mark mutexes 
with a value different from PTHREAD_MUTEX_INITIALIZER when it destroys them 
(similar to MTX_DEAD in the kernel).  This is actually very useful behavior 
for catching bugs and we should catch that.  We probably should make 
pthread_mutex_destroy() not fail but do whatever is sensible for a mutex 
initialized statically in that case however.

> If/when pthread_mutex_t is made a struct, this can be revisited, and
> most likely the destroyed and PTHREAD_MUTEX_INITIALIZER states will be
> different (PTHREAD_MUTEX_INITIALIZER will likely be a normal state that
> does not need special initialization to use).

I would argue that they should already be different states.  I'm surprised our 
pthread_mutex_destroy() is that broken.

-- 
John Baldwin


More information about the freebsd-threads mailing list