Walking through PThread Synchronization Utilities

Runtimes C
1

I am currently walking through existing and yet-to-be-implemented parts of synchronization utilities inside llvm-libc. I am doing this progressively and slowly, trying to cover ancient TODOs as much as I can :smiley:

I am currently on my way towards a RWLock implementation. Here is the roadmap. As Pthread is indeed a large components, I am looking forward to more auditing and contributions to those interesting but not yet planned parts. Suggestions are recommended.

  • pthread_rwlock* (WIP)

  • Performance Related Adjustments

  • Other synchronization methods

    • barrier
    • condvar
    • semaphore
    • …

Separate RawMutex from Mutex

Current Mutex implementation has the following problems:

  • It includes some extra fields (is_shared, is_robust) reserved for pthread features. However, it makes it a less suitable candidate to be used internally (e.g. in RwLock).
  • It does not support timed APIs.
  • It does not support shared memory.

To solve these problems, I will write another lock implementation more suitable for internal usage. Optionally, I may migrate current Mutex to use the internal Lock as no extra features other than plain mutex is implemented yet anyway.

Implement gettid

  • In full build mode, internal gettid should directly get the date from TCB. This also requires fork to update such data properly.
  • In overlay mode, gettid should use syscall with TLS cache, which also requires updates across fork.
2

Thanks for writing this up, this seems like a good strategy for working on the pthreads functions. I have a patch I was working on for the barrier functions based on the bionic implementation that I can send you if you’re interested. It was mostly working, but I hadn’t gotten around to writing tests yet.

3

LGTM; this is why I started implementing rwlockattr fn’s in

commit dd7963239e94 (“[libc][POSIX][pthreads] implement pthread_rwlockattr_t functions (#89322)”)

Please cc me on the patches!

4

Thinking more about this since yesterday.

To me, it’s more valuable to finish our pthread implementation than to focus too much on optimizations. I would prefer that we flush out the rest of the API and test it, at which point I’m happy to refactor it once we can benchmark the initial implementation.

Another thing I thought of; I was reading the libc sources from illumos the other day. They appeared to have really nice dead lock detection in their pthreads implementation. That would be cool to have.

1 Like
5

In terms of getting libc++ to be able to build and link against llvm-libc (a goal that’s close in reach), we need:

  • pthreads rwlocks for libunwind
  • pthreads condvars for libc++abi and libc++
  • pthread Mutex trylock for libc++ (gh issue)

So those should be higher priority over:

  • pthread_barrier
  • pthread_spinlock
  • sys V or POSIX semaphores

I plan to use [libc][__support] move CndVar to __support by nickdesaulniers · Pull Request #89329 · llvm/llvm-project · GitHub towards implementing pthread condvars support.

1 Like