This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Replace MUTEX_INITIALIZER with _LIBC_LOCK_INITIALIZER in generic code
- From: Samuel Thibault <samuel dot thibault at ens-lyon dot org>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Sat, 20 Aug 2016 19:38:16 +0200
- Subject: Re: Replace MUTEX_INITIALIZER with _LIBC_LOCK_INITIALIZER in generic code
- Authentication-results: sourceware.org; auth=none
- References: <20160820143610.GA14327@var> <86732dd1-9c82-0d07-a45d-3b94fd4e2ad6@redhat.com>
Florian Weimer, on Sat 20 Aug 2016 19:19:03 +0200, wrote:
> On 08/20/2016 04:36 PM, Samuel Thibault wrote:
> >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.
Then let's call it another way. But seeing this kind of code:
static mutex_t list_lock = _LIBC_LOCK_INITIALIZER;
looks really odd to the reader: why would I be using
_LIBC_LOCK_INITIALIZER to initialize a mutex_t? I shouldn't have to
have a look at the mutex_t definition to know why it happens to be
right.
Samuel