Bug 21119 - Unify the pthread_mutex_t definitions
Summary: Unify the pthread_mutex_t definitions
Status: UNCONFIRMED
Alias: None
Product: glibc
Classification: Unclassified
Component: nptl (show other bugs)
Version: 2.23
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-02-09 14:10 UTC by Howard Chu
Modified: 2017-02-21 11:23 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Howard Chu 2017-02-09 14:10:20 UTC
Currently the size of a pthread_mutex_t structure can be one of 3 different sizes, depending on the CPU architecture and ABI. E.g., from /usr/include/pthreadtypes.h:

#ifdef __x86_64__
# if __WORDSIZE == 64

#  define __SIZEOF_PTHREAD_MUTEX_T 40

# else

#  define __SIZEOF_PTHREAD_MUTEX_T 32

# endif
#else

# define __SIZEOF_PTHREAD_MUTEX_T 24

#endif

This limits the usefulness of process-shared mutexes, as they cannot safely be used by both 32bit and 64bit processes at the same time.

It Would Be Nice if a cross-arch-compatible definition could be made. Since the guts are all behind a futex syscall anyway this shouldn't be a huge problem, should it?

Presumably this is also an issue for process-shared rwlocks.
Comment 1 Howard Chu 2017-02-09 14:16:32 UTC
For reference, this impairs cross-architecture use of LMDB on Linux/glibc, but other platforms that LMDB supports don't have this problem.

http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8582
Comment 2 Florian Weimer 2017-02-13 12:21:34 UTC
This is very difficult to fix because existing binaries have conflicting requirements for data structure layout due to compiled-in static initializers.

Maybe the way forward here is a public futex interface with extended ABI compatibility guarantees.
Comment 3 Torvald Riegel 2017-02-13 13:17:36 UTC
I don't that a exposing futexes would be the right approach.  It is too low-level an interface for many clients, I believe.  While currently, pthreads mutexes will accomplish a lot through use of futexes, this isn't necessarily going to remain that way to the same extent.

Howard, have you tried using semaphores more extensively?

Regarding 32b/64b compatibility: Maybe this can be considered for something like a semaphore; but even there this is not quite trivial.
Comment 4 Howard Chu 2017-02-20 16:14:37 UTC
(In reply to Torvald Riegel from comment #3)
> I don't that a exposing futexes would be the right approach.  It is too
> low-level an interface for many clients, I believe.  While currently,
> pthreads mutexes will accomplish a lot through use of futexes, this isn't
> necessarily going to remain that way to the same extent.
> 
> Howard, have you tried using semaphores more extensively?
> 
> Regarding 32b/64b compatibility: Maybe this can be considered for something
> like a semaphore; but even there this is not quite trivial.

We have support for semaphores but they're not the preferred solution. Mainly because there are race conditions in creating them when multiple processes open the DB at the same time. Also because they have an independent lifetime; with pshared mutexes living in the mmap'd lockfile they simply go away if a user decides to delete the files.
Comment 5 Torvald Riegel 2017-02-21 11:23:26 UTC
(In reply to Howard Chu from comment #4)
> (In reply to Torvald Riegel from comment #3)
> > I don't that a exposing futexes would be the right approach.  It is too
> > low-level an interface for many clients, I believe.  While currently,
> > pthreads mutexes will accomplish a lot through use of futexes, this isn't
> > necessarily going to remain that way to the same extent.
> > 
> > Howard, have you tried using semaphores more extensively?
> > 
> > Regarding 32b/64b compatibility: Maybe this can be considered for something
> > like a semaphore; but even there this is not quite trivial.
> 
> We have support for semaphores but they're not the preferred solution.
> Mainly because there are race conditions in creating them when multiple
> processes open the DB at the same time. Also because they have an
> independent lifetime; with pshared mutexes living in the mmap'd lockfile
> they simply go away if a user decides to delete the files.

What I was referring to is using semaphores instead of mutexes: start out with one token available, consume a token when entering a criticla section, post a token when exiting the critical section.  Same lifetime as a mutex.  But semaphores are simpler than POSIX mutexes, so perhaps it may be easier for implementations to make stronger guarantees for them.