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 > situation. 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. Rich -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
