From owner-freebsd-threads@FreeBSD.ORG Thu Sep 23 21:41:12 2010 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32170106564A; Thu, 23 Sep 2010 21:41:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 016218FC18; Thu, 23 Sep 2010 21:41:12 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id B0DB246B09; Thu, 23 Sep 2010 17:41:11 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E38148A03C; Thu, 23 Sep 2010 17:41:09 -0400 (EDT) From: John Baldwin To: freebsd-threads@freebsd.org Date: Thu, 23 Sep 2010 17:41:07 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201009231733.o8NHXuao082524@www.freebsd.org> <1285270911.11313.30.camel@trixie.casa.cgf.cx> <20100923210746.GA44173@stack.nl> In-Reply-To: <20100923210746.GA44173@stack.nl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009231741.07962.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 23 Sep 2010 17:41:09 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-gnats-submit@freebsd.org, Christopher Faylor Subject: Re: threads/150889: PTHREAD_MUTEX_INITIALIZER + pthread_mutex_destroy() == EINVAL X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2010 21:41:12 -0000 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