| Summary: | Unify the pthread_mutex_t definitions | ||
|---|---|---|---|
| Product: | glibc | Reporter: | Howard Chu <hyc> |
| Component: | nptl | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | UNCONFIRMED --- | ||
| Severity: | enhancement | CC: | drepper.fsp, fweimer |
| Priority: | P3 | Flags: | fweimer:
security-
|
| Version: | 2.23 | ||
| Target Milestone: | --- | ||
| See Also: | https://bugzilla.redhat.com/show_bug.cgi?id=1394862 | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | ||
|
Description
Howard Chu
2017-02-09 14:10:20 UTC
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. |