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

[John Baldwin]

The following reply was made to PR threads/150889; it has been noted by GNATS.

From: John Baldwin <jhb at freebsd.org>
To: freebsd-threads at freebsd.org
Cc: Jilles Tjoelker <jilles at stack.nl>,
 Christopher Faylor <cgf at netapp.com>,
 freebsd-gnats-submit at freebsd.org
Subject: Re: threads/150889: PTHREAD_MUTEX_INITIALIZER + pthread_mutex_destroy() == EINVAL
Date: Thu, 23 Sep 2010 17:41:07 -0400

 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