Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 Sep 2010 15:41:51 -0400
From:      Christopher Faylor <cgf@netapp.com>
To:        freebsd-threads@freebsd.org, freebsd-gnats-submit@freebsd.org
Subject:   Re: threads/150889: PTHREAD_MUTEX_INITIALIZER + pthread_mutex_destroy() == EINVAL
Message-ID:  <1285270911.11313.30.camel@trixie.casa.cgf.cx>
In-Reply-To: <201009231414.50271.jhb@freebsd.org>
References:  <201009231733.o8NHXuao082524@www.freebsd.org> <201009231414.50271.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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?



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1285270911.11313.30.camel>