This is the mail archive of the
mailing list for the glibc project.
Re: For review: nptl(7) man page
- From: Torvald Riegel <triegel at redhat dot com>
- To: "Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>
- Cc: Nicholas Miell <nmiell at gmail dot com>, linux-man at vger dot kernel dot org, libc-alpha at sourceware dot org, "Carlos O'Donell" <carlos at redhat dot com>
- Date: Mon, 03 Aug 2015 17:45:40 +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> <55B54215 dot 6070502 at gmail dot com>
On Sun, 2015-07-26 at 22:24 +0200, Michael Kerrisk (man-pages) wrote:
> 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.
In general, I don't think we promise that one can use share
PTHREAD_PROCESS_SHARED data structures between processes that do not use
the same glibc. A 32b glibc build and an x86_64 build will differ
(e.g., the new semaphore implemenation uses a different algorithm if 64b
atomic operations are available instead of just 32b ones). The sizes
and aligment of the data structures are ABI, but I do not believe that
the way in that glibc uses those bits is part of the ABI too.
However, I haven't checked whether POSIX makes any statements about this