Details
Details
- Reviewers
phosek
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Comment Actions
Yes, I am aware of this. Sorry for not being more descriptive about what I have in mind. My goal was to implement a self-contained mutex. As in, a mutex which can be used with any threading library. Most other libc implementations use a higher level futex locking facility (FUTEX_LOCK_PI and friends). We can take the same route here, but it has some shortcomings:
- The "fastest" implementation will tie us to a specific threading library (which for us will/should be LLVM libc's threading library) as it will use thread local storage.
- The slowest implementation can avoid using TLS but will require one additional syscall each in the lock and unlock functions.
We have two alternates:
- This patch. But, obviously it leads to the thundering herd problem.
- Use a counter to keep track of the current set of waiters. This counter has to be an atomic object so will not match the performance of #1 from above.
I am now beginning to feel that going the route of #1 from the first list is probably the right approach. FWIW, the infrastructure we build is required anyway to implement other pieces like recursive locks.