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.
Paths
| Differential D74653
[libc] Add simple implementations of mtx_lock and mtx_unlock. ClosedPublic Authored by sivachandra on Feb 14 2020, 2:37 PM.
Details Summary These functions only support locking and unlocking of plain mutexes. Depends on D75380.
Diff Detail
Event Timelinesivachandra added inline comments.
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. abrachet added a parent revision: D74652: [libc] Add support library for use with tests..Feb 18 2020, 4:02 PM 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.
sivachandra added inline comments.
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.
sivachandra marked 2 inline comments as done. Comment Actions
sivachandra added a parent revision: D75380: [libc] Add linux implementations of thrd_create and thrd_join functions.. Comment Actions
Done now: https://reviews.llvm.org/D75379
This revision is now accepted and ready to land.Mar 5 2020, 11:38 AM Closed by commit rG550be40515df: [libc] Add simple implementations of mtx_lock and mtx_unlock. (authored by sivachandra). · Explain WhyMar 9 2020, 10:38 PM This revision was automatically updated to reflect the committed changes.
Revision Contents
Diff 245466 libc/config/linux/api.td
libc/config/public_api.td
libc/include/CMakeLists.txt
libc/include/threads.h.def
libc/lib/CMakeLists.txtlibc/spec/linux.td
libc/spec/posix.td
libc/spec/spec.td
libc/spec/stdc.td
libc/src/CMakeLists.txt
libc/src/threads/CMakeLists.txt
libc/src/threads/linux/CMakeLists.txt
libc/src/threads/linux/mtx_init.cpp
libc/src/threads/linux/mtx_lock.cpp
libc/src/threads/linux/mtx_unlock.cpp
libc/src/threads/linux/mutex.h
libc/src/threads/mtx_init.h
libc/src/threads/mtx_lock.h
libc/src/threads/mtx_unlock.h
libc/test/src/CMakeLists.txt
libc/test/src/threads/linux/CMakeLists.txt
libc/test/src/threads/linux/mtx_test.cpp
libc/utils/HdrGen/PublicAPICommand.cpp
|
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.