From owner-freebsd-threads@FreeBSD.ORG Thu Sep 23 20:10:02 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 5F5831065670; Thu, 23 Sep 2010 20:10:02 +0000 (UTC) (envelope-from Christopher.Faylor@netapp.com) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by mx1.freebsd.org (Postfix) with ESMTP id 3C9F18FC13; Thu, 23 Sep 2010 20:10:02 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.57,224,1283756400"; d="scan'208";a="456836333" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 23 Sep 2010 12:41:54 -0700 Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o8NJfrsI000104; Thu, 23 Sep 2010 12:41:54 -0700 (PDT) Received: from rtprsexc2-prd.hq.netapp.com ([10.100.161.115]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Sep 2010 12:41:54 -0700 Received: from RTPMVEXC1-PRD.hq.netapp.com ([10.100.161.112]) by rtprsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Sep 2010 15:41:52 -0400 Received: from 10.30.34.57 ([10.30.34.57]) by RTPMVEXC1-PRD.hq.netapp.com ([10.100.161.119]) with Microsoft Exchange Server HTTP-DAV ; Thu, 23 Sep 2010 19:41:51 +0000 Received: from trixie by RTPMVEXC1-PRD.hq.netapp.com; 23 Sep 2010 15:41:51 -0400 From: Christopher Faylor To: freebsd-threads@freebsd.org, freebsd-gnats-submit@freebsd.org In-Reply-To: <201009231414.50271.jhb@freebsd.org> References: <201009231733.o8NHXuao082524@www.freebsd.org> <201009231414.50271.jhb@freebsd.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Sep 2010 15:41:51 -0400 Message-ID: <1285270911.11313.30.camel@trixie.casa.cgf.cx> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 X-OriginalArrivalTime: 23 Sep 2010 19:41:52.0592 (UTC) FILETIME=[5F189500:01CB5B57] Cc: 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 20:10:02 -0000 On Thu, 2010-09-23 at 14:14 -0400, John Baldwin wrote: > I suppose that is true, but I think this is also probably buggy code if y= ou > are doing this. The use case for PTHREAD_MUTEX_INITALIZER is static > initialization of static objects to ease adding locking to C libraries wh= ere > constructors are not easy. Specifically, to avoid prefixing every > pthread_mutex_lock() with a pthread_once() call to initialize the mutex. > (See the example given in the RATIONALE section in the pthread_mutex_init= () > page at the link above where it talks about static initialization.) Such > mutexes are generally never destroyed (their lifetime is the same as the > containing executable or shared library (since presumably they could vani= sh > as part of a dlclose())). I think it is not provided so that you can > initialize dynamically allocated mutexes at runtime via: >=20 > struct foo { > ... > pthread_mutex_t m; > } >=20 > f =3D malloc(sizeof(foo); > f->m =3D PTHREAD_MUTEX_INITIALIZER; >=20 > Those sorts of locks should be initialized via pthread_mutex_init() inste= ad. >... >=20 > The one possibly valid reason I can see for pthread_mutex_destroy() to > operate on a statically initialized mutex is to let a library destroy a > mutex due to dlclose() unloading the library. However, to pull that off = the > library would need to install an atexit() hook or similar to actually inv= oke > pthread_mutex_destroy(). That requires some sort of initialization code = to > invoke atexit() at which point you might as well call pthread_mutex_init(= ) > to initialize the mutex at the same time as calling atexit(). 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. However, regardless, this is still a bug in pthread_mutex_destroy right?