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