Skip to content
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

tests: kernel/sys_mutex: sleep a bit for private_mutex to lock #59830

Conversation

dcpleung
Copy link
Member

@dcpleung dcpleung commented Jun 28, 2023

With SMP, the private_mutex may not be locked fast enough by thread_12 after the thread creation as it might take longer for a thread to start running the entry function, resulting in test failure when the main test thread goes into locking it again. So give it a bit more delay after thread creation so thread_12 has a chance to lock the private_mutex.

@dcpleung dcpleung marked this pull request as ready for review June 28, 2023 17:51
Comment on lines 405 to 406
k_sleep(K_MSEC(1)); /* Give thread_12 a chance to lock */

Copy link
Collaborator

Choose a reason for hiding this comment

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

I may be missing something, but I am not seeing why this is needed on SMP. The ownership/lock should automatically be assigned to thread_12 before that 2nd sys_mutex_unlock() returns. If there is a race in SMP, then I would have expected it to be due to the pre-existing k_sleep(K_MSEC(1)) on line 400 being too short a time to get thread_12 into the mutex's wait queue.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good point. I have make the sleep on line 400 longer instead.

@dcpleung dcpleung force-pushed the tests/kernel/sys_mutex_private_mutex_delay_lock branch from b8941b9 to 1904bd5 Compare June 28, 2023 18:45
With SMP, the private_mutex may not be locked fast enough by
thread_12 after the thread creation as it might take longer
for a thread to start running the entry function, resulting
in test failure when the main test thread goes into locking
it again. So give it a bit more delay after thread creation
so thread_12 has a chance to lock the private_mutex.

Signed-off-by: Daniel Leung <[email protected]>
@nashif nashif merged commit fd3a8ee into zephyrproject-rtos:main Jul 21, 2023
16 checks passed
@dcpleung dcpleung deleted the tests/kernel/sys_mutex_private_mutex_delay_lock branch July 21, 2023 22:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants