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

Fix #516, Use absolute timeout for timedlock calls #518

Merged

Conversation

jphickey
Copy link
Contributor

Describe the contribution
The pthread API defines the timeout parameter for the pthread_mutex_timedlock call as an absolute value based on CLOCK_REALTIME.

This introduces a wrapper function to calculate the absolute timeout for this.

Fixes #516

Testing performed
Build and execute CFE, sanity check CFE operation, and run all unit tests.
Coverage is not affected because there is no coverage test for POSIX.

Expected behavior changes
The timed lock in binary semaphores should now correctly wait for up to 2 seconds for the lock to become available before failing. The net effect of passing a relative timeout in place of an absolute one meant that the code would not wait, basically turning into a "trylock" instead.

System(s) tested on
Ubuntu 20.04

Additional context
Unfortunately this wasn't previously noticed during testing because it requires getting two tasks to operate on the same binary sem at exactly the same time, which is difficult to replicate.

Contributor Info - All information REQUIRED for consideration of pull request
Joseph Hickey, Vantage Systems, Inc.

astrogeco and others added 3 commits June 17, 2020 15:46
Fast Track for Integration Candidate 2020-06-10
The pthread API defines the timeout parameter for
the pthread_mutex_timedlock call as an absolute value
based on CLOCK_REALTIME.

This introduces a wrapper function to calculate the absolute
timeout for this.
@jphickey jphickey added the CCB:Ready Pull request is ready for discussion at the Configuration Control Board (CCB) label Jun 19, 2020
@jphickey
Copy link
Contributor Author

@skliper and @astrogeco - this might be considered for fast track or at least I'd recommend getting this into the branch for the upcoming bundle release in addition to "master" branch.

@jphickey jphickey requested a review from skliper June 19, 2020 15:42
@skliper skliper added the bug label Jun 22, 2020
@skliper skliper added this to the 5.1.0 milestone Jun 22, 2020
@astrogeco astrogeco changed the base branch from master to integration-candidate June 23, 2020 19:12
@astrogeco astrogeco merged commit 9cfdbff into nasa:integration-candidate Jun 23, 2020
@astrogeco astrogeco added CCB-20200624 and removed CCB:Ready Pull request is ready for discussion at the Configuration Control Board (CCB) labels Jun 24, 2020
@astrogeco astrogeco removed the bug label Sep 21, 2020
@jphickey jphickey deleted the fix-516-absolute-timedlock branch December 3, 2020 17:26
jphickey pushed a commit to jphickey/osal that referenced this pull request Aug 10, 2022
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.

Second parameter of pthread_mutex_timedlock should be absolute time not timeout
3 participants