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