This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Question about the usage of pthread_mutex_t's __data.__lock
- From: Martin Galvan <martin dot galvan at tallertechnologies dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Daniel Gutson <daniel dot gutson at tallertechnologies dot com>, libc-alpha at sourceware dot org, Torvald Riegel <triegel at redhat dot com>
- Date: Sat, 28 Feb 2015 16:50:31 -0300
- Subject: Re: Question about the usage of pthread_mutex_t's __data.__lock
- Authentication-results: sourceware.org; auth=none
- References: <CAOKbPbZr1oGug7y_=OGSq2P9jLMk8zOqu6+eShrQV1rRqkyrsw at mail dot gmail dot com> <54F0E1D9 dot 5060007 at redhat dot com>
Thanks a lot for your answer. Just out of curiosity: looking at the
code in __pthread_mutex_lock_full, it says:
"The PI support requires the Linux futex system call. If that's not
available, pthread_mutex_init should never have allowed the type to be
set. So it will get the default case for an invalid type".
This sounds like there's a way to block threads without having the
__NR_futex syscall. However, I followed the code all the way from the
LLL_MUTEX_LOCK macro in nptl/pthread_mutex_lock.c to the part where a
thread will block on a mutex and I saw we always end up using the
futex syscall. From what I saw, it's always something like:
LLL_MUTEX_LOCK -> lll_lock (may be arch-dependant) -> __lll_lock_wait
-> lll_futex_wait -> INTERNAL_SYSCALL
INTERNAL_SYSCALL seems to be an arch-dependant macro which ends up
calling __NR_futex. There may be a couple of intermediate steps in
some archs (such as x86), but it seems to me that we'll always need
the syscall to block threads. Am I missing something?