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

[Jilles Tjoelker]

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

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

 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).
 
 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).
 
 -- 
 Jilles Tjoelker