Date: Thu, 23 Sep 2010 21:50:02 GMT From: John Baldwin <jhb@freebsd.org> To: freebsd-threads@FreeBSD.org Subject: Re: threads/150889: PTHREAD_MUTEX_INITIALIZER + pthread_mutex_destroy() == EINVAL Message-ID: <201009232150.o8NLo2f5079384@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR threads/150889; it has been noted by GNATS. From: John Baldwin <jhb@freebsd.org> To: freebsd-threads@freebsd.org Cc: Jilles Tjoelker <jilles@stack.nl>, Christopher Faylor <cgf@netapp.com>, freebsd-gnats-submit@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201009232150.o8NLo2f5079384>