This is the mail archive of the
mailing list for the glibc project.
Re: For review: nptl(7) man page
- From: "Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>
- To: Nicholas Miell <nmiell at gmail dot com>
- Cc: mtk dot manpages at gmail dot com, linux-man at vger dot kernel dot org, libc-alpha at sourceware dot org
- Date: Sun, 26 Jul 2015 22:24:53 +0200
- Subject: Re: For review: nptl(7) man page
- Authentication-results: sourceware.org; auth=none
- References: <550ED3F4 dot 1080403 at gmail dot com> <550F363B dot 801 at gmail dot com> <55B1EFFA dot 9070608 at gmail dot com> <CAODz2cDq4o85NOzqCDg9cH8eCvqt3Tq5QXKMMJtXbik5h5bL+Q at mail dot gmail dot com>
On 07/24/2015 05:51 PM, Nicholas Miell wrote:
> PTHREAD_PROCESS_SHARED says any thread with access to the memory containing
> the mutex can operate on the mutex and POSIX basically ignores the idea
> that different processes could be running completely incompatible
> executables or whatever.
> pthread_mutex_t has a bunch of #ifdefs in the middle of it that change the
> structure size and layout between i386 and x86_64.
> Most importantly, the positions of the __nusers and __kind fields are
> swapped (this looks to be an oversight dating back to 2003 when __nusers
> was first introduced and carefully preserved when the separate i386 and
> x86_64 versions of pthreadtypes.h were merged into the single x86 version),
> which means that when the lock and unlock functions attempt to figure out
> what kind of mutex it is (recursive/adaptive/whatever), they'll look at the
> wrong field if the mutex is from the wrong architecture and then things
> will break.
> And then there's the fact that the rest of the struct is a union in the
> 32-bit version and flat in the 64-bit version, but that could have been
> worked around if you put a flag in the __kind field that tells the 64-bit
> pthread library that it is looking at a 32-bit mutex.
Thanks for the additional detail, Nicholas. So, how about a paragraph such
as the following for the manual page:
POSIX says that any thread in any process with access to the memâ
ory containing a process-shared (PTHREAD_PROCESS_SHARED) mutex
can operate on that mutex. However, on 64-bit x86 systems, the
mutex definition for x86-64 is incompatible with the mutex defiâ
nition for i386, meaning that 32-bit and 64-bit binaries can't
share mutexes on x86-64 systems.
> On Fri, Jul 24, 2015 at 12:57 AM, Michael Kerrisk (man-pages) <
> email@example.com> wrote:
>> On 03/22/2015 10:38 PM, Nicholas Miell wrote:
>>> On 03/22/2015 07:38 AM, Michael Kerrisk (man-pages) wrote:
>>>> Hello all,
>>>> I wrote a short man page documented some of the details of
>>>> NPTL that might affect application developers. Review comments
>>>> would be most welcome.
>>> POSIX specifies that process-shared pthread_mutex_t's can be manipulated
>>> by independent processes, however the AMD64 and i386 versions of the
>>> mutex structures are incompatible and cannot be shared.
>>> This might be true of the other supposedly sharable primitives, I never
>>> bothered to check the rest when I first noticed the problem with mutexes.
>> Can you provide pointers to further information on this topic?
>> Michael Kerrisk
>> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
>> Linux/UNIX System Programming Training: http://man7.org/training/
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/