This is the mail archive of the
mailing list for the glibc project.
Re: For review: nptl(7) man page
- From: Rich Felker <dalias at libc dot org>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: "Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>, 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, 3 Aug 2015 16:08:25 -0400
- 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> <1438616740 dot 20974 dot 81 dot camel at localhost dot localdomain>
On Mon, Aug 03, 2015 at 05:45:40PM +0200, Torvald Riegel wrote:
> 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
It doesn't directly. If you consider the models as two separate
"compilation environments"/"execution environments" of the same
implementation, then it would at least be within the scope of POSIX to
have something to say about it. On the other hand if you consider them
as completely separate implementations that just happen to run (as
foreign binaries) on the same logical/physical machine, it's well
outside the scope of POSIX whether this works.