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. -- 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
