-
Notifications
You must be signed in to change notification settings - Fork 6.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
posix: abstract pthread_cond_t as uint32_t #52173
posix: abstract pthread_cond_t as uint32_t #52173
Conversation
Compliance check failures are a false positive (pthread functions return non-negative errno values) |
0133f71
to
ce8984d
Compare
cbc89eb
to
bf563a6
Compare
@stephanosio - are you able to take a look? |
lib/posix/pthread_cond.c
Outdated
return cv - posix_cond_pool; | ||
} | ||
|
||
static inline size_t to_posix_cond_idx(pthread_mutex_t cond) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
incorrect type for cond
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed!
lib/posix/posix_internal.h
Outdated
#define PTHREAD_MUTEX_MASK_INIT 0x80000000 | ||
#define PTHREAD_COND_MASK_INIT PTHREAD_MUTEX_MASK_INIT |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it really make sense to define PTHREAD_COND_MASK_INIT
in terms of PTHREAD_MUTEX_MASK_INIT
? I understand that they have the same value, but defining it as such does not seem very logical.
Maybe it would be better to introduce something like #define PTHREAD_OBJ_INIT_MASK 0x80000000
and define both PTHREAD_MUTEX_MASK_INIT
and PTHREAD_COND_MASK_INIT
in terms of that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed!
Previously `PTHREAD_MUTEX_MASK_INIT` was used to mark a `pthread_mutex_t` as initialized. The same needs to be done for `pthread_cond_t` and likely others. Rather than copy-pasting that and a number of inlines that duplicate the same functionality, simply make it more generic. Signed-off-by: Chris Friedt <[email protected]>
Previously, `pthread_cond_init()` could not actually fail, and destroying condition variables was a no-op, and it was missing in `pthread_exit()`. However, with the change of `pthread_cond_t` to `uint32_t`, and since those are embedded inside of `struct posix_thread` for the time being, the pthread code needs to keep track that it is relinquishes used condition variables when a thread completes. Signed-off-by: Chris Friedt <[email protected]>
Consistent with the change of `pthread_t` from `struct posix_thread` to `uint32_t`, we can now also abstract `pthread_cond_t` as `uint32_t` and separate `struct posix_cond` as an implementation detail, hidden from POSIX API consumers. This change deprecates `PTHREAD_COND_DEFINE()` in favour of the (standardized) `PTHREAD_COND_INITIALIZER`. This change introduces `CONFIG_MAX_PTHREAD_COND_COUNT`. Signed-off-by: Chris Friedt <[email protected]>
Add a test to ensure that `pthread_cond_t` can be used over and over again and that there is no resource leakage with proper usage. Signed-off-by: Chris Friedt <[email protected]>
bf563a6
to
f622477
Compare
@stephanosio, @jeremybettis - should be ready for round 2, if you have a moment. |
@enjiamai @KangJianX - any reviews from you? |
@jeremybettis - IIRC you had previously approved this one. Will you re-ack? |
@keith-packard would you maybe ack? This is blocking a few PRs still.. |
4 commits
See individual commit messages for details.