Currently the size of a pthread_mutex_t structure can be one of 3 different sizes, depending on the CPU architecture and ABI. E.g., from /usr/include/pthreadtypes.h: #ifdef __x86_64__ # if __WORDSIZE == 64 # define __SIZEOF_PTHREAD_MUTEX_T 40 # else # define __SIZEOF_PTHREAD_MUTEX_T 32 # endif #else # define __SIZEOF_PTHREAD_MUTEX_T 24 #endif This limits the usefulness of process-shared mutexes, as they cannot safely be used by both 32bit and 64bit processes at the same time. It Would Be Nice if a cross-arch-compatible definition could be made. Since the guts are all behind a futex syscall anyway this shouldn't be a huge problem, should it? Presumably this is also an issue for process-shared rwlocks.
For reference, this impairs cross-architecture use of LMDB on Linux/glibc, but other platforms that LMDB supports don't have this problem. http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8582
This is very difficult to fix because existing binaries have conflicting requirements for data structure layout due to compiled-in static initializers. Maybe the way forward here is a public futex interface with extended ABI compatibility guarantees.
I don't that a exposing futexes would be the right approach. It is too low-level an interface for many clients, I believe. While currently, pthreads mutexes will accomplish a lot through use of futexes, this isn't necessarily going to remain that way to the same extent. Howard, have you tried using semaphores more extensively? Regarding 32b/64b compatibility: Maybe this can be considered for something like a semaphore; but even there this is not quite trivial.
(In reply to Torvald Riegel from comment #3) > I don't that a exposing futexes would be the right approach. It is too > low-level an interface for many clients, I believe. While currently, > pthreads mutexes will accomplish a lot through use of futexes, this isn't > necessarily going to remain that way to the same extent. > > Howard, have you tried using semaphores more extensively? > > Regarding 32b/64b compatibility: Maybe this can be considered for something > like a semaphore; but even there this is not quite trivial. We have support for semaphores but they're not the preferred solution. Mainly because there are race conditions in creating them when multiple processes open the DB at the same time. Also because they have an independent lifetime; with pshared mutexes living in the mmap'd lockfile they simply go away if a user decides to delete the files.
(In reply to Howard Chu from comment #4) > (In reply to Torvald Riegel from comment #3) > > I don't that a exposing futexes would be the right approach. It is too > > low-level an interface for many clients, I believe. While currently, > > pthreads mutexes will accomplish a lot through use of futexes, this isn't > > necessarily going to remain that way to the same extent. > > > > Howard, have you tried using semaphores more extensively? > > > > Regarding 32b/64b compatibility: Maybe this can be considered for something > > like a semaphore; but even there this is not quite trivial. > > We have support for semaphores but they're not the preferred solution. > Mainly because there are race conditions in creating them when multiple > processes open the DB at the same time. Also because they have an > independent lifetime; with pshared mutexes living in the mmap'd lockfile > they simply go away if a user decides to delete the files. What I was referring to is using semaphores instead of mutexes: start out with one token available, consume a token when entering a criticla section, post a token when exiting the critical section. Same lifetime as a mutex. But semaphores are simpler than POSIX mutexes, so perhaps it may be easier for implementations to make stronger guarantees for them.