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