Replace MUTEX_INITIALIZER with _LIBC_LOCK_INITIALIZER in generic code

Florian Weimer fweimer@redhat.com
Sat Aug 20 17:19:00 GMT 2016


On 08/20/2016 04:36 PM, Samuel Thibault wrote:
> Hello,
>
> In 400e12265d99964f8445bb6d717321eb73152cc5 ('Replace MUTEX_INITIALIZER
> with _LIBC_LOCK_INITIALIZER in generic code'),
>
> --- b/sysdeps/generic/malloc-machine.h
> -# define MUTEX_INITIALIZER      (0)
>
> --- a/sysdeps/nptl/malloc-machine.h
> -#define MUTEX_INITIALIZER      LLL_LOCK_INITIALIZER
>
>
> -static mutex_t list_lock = MUTEX_INITIALIZER;
> +static mutex_t list_lock = _LIBC_LOCK_INITIALIZER;
>
> ...
>
> Why not keeping MUTEX_INITIALIZER?

Because it was a special case for malloc and appears to be a Mach 
identifier, not a glibc identifier.  That shouldn't really be part of 
generic code.

> There is not only nptl and generic
> ports of glibc, other ports may not be using libc_lock to implement
> malloc's mutex...

Why would they do that?

At the time I wrote the patch, all building in-tree ports used 
libc_lock.  I try not to break out-of-tree ports and ports that need 
custom patches to build master, but mistakes do happen.

> And anyway, either malloc should be made to just use libc-lock or lll
> explicitly, or the malloc-machine.h layer should be providing a complete
> interface and users shouldn't be assuming anything about it.

I submitted a patch for switching malloc over to libc_lock.

Florian



More information about the Libc-alpha mailing list