From owner-freebsd-threads@FreeBSD.ORG Thu Sep 23 21:07:47 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 96692106564A; Thu, 23 Sep 2010 21:07:47 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 5A4948FC1A; Thu, 23 Sep 2010 21:07:47 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 5C8281DD415; Thu, 23 Sep 2010 23:07:46 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id 46A6D172E5; Thu, 23 Sep 2010 23:07:46 +0200 (CEST) Date: Thu, 23 Sep 2010 23:07:46 +0200 From: Jilles Tjoelker To: Christopher Faylor Message-ID: <20100923210746.GA44173@stack.nl> References: <201009231733.o8NHXuao082524@www.freebsd.org> <201009231414.50271.jhb@freebsd.org> <1285270911.11313.30.camel@trixie.casa.cgf.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1285270911.11313.30.camel@trixie.casa.cgf.cx> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-gnats-submit@freebsd.org, freebsd-threads@freebsd.org 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:07:47 -0000 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