Skip to content

Conversation

@cfriedt
Copy link
Member

@cfriedt cfriedt commented Nov 11, 2022

4 commits

  • lib: posix: internal: use a more generic INIT mask and inlines
  • posix: pthread: take care with pthread cond resources
  • posix: cond: abstract pthread_cond_t as uint32_t
  • tests: posix: cond: test to ensure there is no resource leakage

See individual commit messages for details.

@cfriedt
Copy link
Member Author

cfriedt commented Nov 11, 2022

Compliance check failures are a false positive (pthread functions return non-negative errno values)

@cfriedt cfriedt force-pushed the use-uint32-for-pthread-cond branch from 0133f71 to ce8984d Compare November 13, 2022 23:06
jeremybettis
jeremybettis previously approved these changes Nov 14, 2022
@cfriedt cfriedt force-pushed the use-uint32-for-pthread-cond branch 2 times, most recently from cbc89eb to bf563a6 Compare November 14, 2022 23:24
@cfriedt cfriedt marked this pull request as ready for review November 14, 2022 23:49
@cfriedt cfriedt requested a review from pfalcon as a code owner November 14, 2022 23:49
@zephyrbot zephyrbot added the area: POSIX POSIX API Library label Nov 14, 2022
@cfriedt cfriedt requested a review from jeremybettis November 15, 2022 00:23
jeremybettis
jeremybettis previously approved these changes Nov 15, 2022
@cfriedt
Copy link
Member Author

cfriedt commented Nov 16, 2022

@stephanosio - are you able to take a look?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

incorrect type for cond

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed!

Comment on lines 14 to 15
Copy link
Member

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed!

Chris Friedt added 4 commits November 16, 2022 07:31
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]>
@cfriedt
Copy link
Member Author

cfriedt commented Nov 16, 2022

@stephanosio, @jeremybettis - should be ready for round 2, if you have a moment.

@cfriedt
Copy link
Member Author

cfriedt commented Nov 17, 2022

@enjiamai @KangJianX - any reviews from you?

@cfriedt
Copy link
Member Author

cfriedt commented Nov 18, 2022

@jeremybettis - IIRC you had previously approved this one. Will you re-ack?

@cfriedt
Copy link
Member Author

cfriedt commented Nov 18, 2022

@keith-packard would you maybe ack? This is blocking a few PRs still..

@stephanosio stephanosio merged commit 909185f into zephyrproject-rtos:main Nov 19, 2022
@cfriedt cfriedt deleted the use-uint32-for-pthread-cond branch November 19, 2022 22:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: POSIX POSIX API Library

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants