This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Where does MUTEX_INITIALIZER come from on Hurd?
- From: Florian Weimer <fweimer at redhat dot com>
- To: Samuel Thibault <samuel dot thibault at ens-lyon dot org>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 4 Nov 2015 18:26:10 +0100
- Subject: Re: Where does MUTEX_INITIALIZER come from on Hurd?
- Authentication-results: sourceware.org; auth=none
- References: <563A388E dot 1090906 at redhat dot com> <20151104170713 dot GQ3036 at var dot bordeaux dot inria dot fr>
On 11/04/2015 06:07 PM, Samuel Thibault wrote:
> Florian Weimer, on Wed 04 Nov 2015 17:55:42 +0100, wrote:
>> We currently have malloc-machine.h and libc-lock.h. For NPTL targets,
>> malloc-machine.h provides MUTEX_INITIALIZER. But Hurd malloc-machine.h
>> does not provide it, and libc-lock.h references it. Where does it come
>> from?
>
> It comes from cthreads.h, outside of glibc:
>
> libthreads/cthreads.h:#define MUTEX_INITIALIZER { SPIN_LOCK_INITIALIZER, SPIN_LOCK_INITIALIZER, 0, QUEUE_INITIALIZER, }
I suspect so, thanks.
>> The libc-lock.h wrappers currently do not seem to provide *any*
>> replacement for MUTEX_INITIALIZER. Should we assume that
>> zero-initialization works for mutexes?
>
> It will happen to work with the current cthreads implementation, but
> that's not guaranteed.
The problem is that we currently reference MUTEX_INITIALIZER in generic
code. I'll change that to _LIBC_LOCK_INITIALIZER (there is already
_LIBC_LOCK_RECURSIVE_INITIALIZER) and find a way to define this macro
via libc-lock.h.
Florian