These functions only support locking and unlocking of plain mutexes.
They will be extended in future changes to handled recursive and timed
mutexes.
Depends on D75380.
Differential D74653
[libc] Add simple implementations of mtx_lock and mtx_unlock. sivachandra on Feb 14 2020, 2:37 PM. Authored by
Details These functions only support locking and unlocking of plain mutexes. Depends on D75380.
Diff Detail
Event Timeline
Comment Actions A mutex implementation will need congestion counts. If only a shim is needed, a bi-state mutex is sufficient. I think pthread_mutex_timedlock and pthread_mutex_unlock can be implemented first, then rebase mtx_lock and mtx_unlock on pthread. A libc eventually has to implement pthread to be usable on a POSIX platform. It can be a shim, with just the basic functionality. Even if you don't want to think of pthread initially, mtx_lock should be based on mtx_timedlock. We can assume Linux>=2.6.22 and use FUTEX_PRIVATE_FLAG. Comment Actions A tri-state mutex helps us avoid an unnecessary futext syscall.
In LLVM libc, we want to take the opposite approach of implementing pthread as an extension over standard C thread library. Agree mtx_lock could be a specialization of mtx_timedlock. As I said in the description, this patch is only a simple implementation of a plain mutex. It allows me to avoid worrying about he timespec API for now. Having a plain mutex available paves way for adding and testing other parts of the libc system.
Agreed. I was not sure, but since you also bring it up, I can go ahead with that change. I will update in the next round. Comment Actions My intuition (I've never really used <threads.h>) is that it will be more difficult than the opposite because pthread provides many more options than C11's thread library. I think this patch is good and it'll be useful to have mutex's but my guess is when we implement pthread it will become untenable to use what we currently have.
Comment Actions Would it be possible to land the enumeration support separately? These are separate changes and I think it'd be cleaner to land them as two commits.
Comment Actions
Comment Actions Done now: https://reviews.llvm.org/D75379
|
Do you plan to graduate these eventually to a common file (and layer Linux on top)? These API aren't Linux specific and we would like to provide these definitions on other platforms like Fuchsia.