Where does MUTEX_INITIALIZER come from on Hurd?
Florian Weimer
fweimer@redhat.com
Wed Nov 4 17:26:00 GMT 2015
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
More information about the Libc-alpha
mailing list