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

Improve error checking in mutex stub #3167

Open
wants to merge 3 commits into
base: devel
Choose a base branch
from

Conversation

celskeggs
Copy link
Contributor

Related Issue(s) n/a
Has Unit Tests (y/n) n
Documentation Included (y/n) n

Change Description

Replace the stub implementation of Os::Mutex with a more complete nonblocking implementation that still avoids platform dependencies.

Rationale

The default mutex stub is intended to be usable on any platform, even platforms that do not have threads and cannot block. This stub is inappropriate for applications that need to contend over mutexes. However, if inadvertently used in applications in a way that would result in mutex contention, they would silently allow incorrect and dangerous behavior. (Notably, they allowed multiple threads to enter the same critical section.)

The new implementation still works on all platforms, and never blocks. However, it ensures that only one thread enters each critical section at a time. Attempting to acquire a mutex that is already taken will result in a failure to acquire the mutex, and likely an assertion. Because this should only occur in the case of a coding defect, this is an improvement over the previous implementation.

Testing/Review Recommendations

No specific testing has been performed yet, so I am leaving this PR as a draft for the moment.

Future Work

It is possible that some existing programs work correctly by luck but happen to rely on the ability to have multiple threads acquire the same mutex. These programs could be broken by this upgrade. Therefore, this change in behavior should be documented in the release notes.

@LeStarch
Copy link
Collaborator

Is there a reason this is in draft? It looks right.

@celskeggs
Copy link
Contributor Author

As mentioned above, I have not tested this PR. I won't have the opportunity to test it until next week. Do you want to merge this without testing?

@LeStarch LeStarch added the Update Instructions Needed Need to add instructions in the release notes for updates. label Jan 30, 2025
@LeStarch
Copy link
Collaborator

I can wait for you to run your tests. I just wanted to let CI have a crack at it too. That passed!

@celskeggs
Copy link
Contributor Author

Does CI actually test the stub mutex at all? I ask because this code turns out to be completely broken: I omitted a ! by accident in the second conditional, which makes it impossible to successfully release the mutex! I'm surprised to see that CI didn't catch the issue.

@thomas-bc
Copy link
Collaborator

CI was not testing the behavior of the StubMutex because there wasn't much behavior to test in the first place (in hindsight, not the best idea).
We should probably throw our common set of mutex tests at this implementation https://github.com/nasa/fprime/blob/devel/Os/test/ut/mutex/CommonTests.cpp ?

The default mutex stub is intended to be usable on any platform,
even platforms that do not have threads and cannot block. This stub is
inappropriate for applications that need to contend over mutexes.
However, if inadvertently used in applications in a way that would
result in mutex contention, they would silently allow incorrect and
dangerous behavior. (Notably, they allowed multiple threads to enter the
same critical section.)

The new implementation still works on all platforms, and never blocks.
However, it ensures that only one thread enters each critical section at
a time. Attempting to acquire a mutex that is already taken will result
in a failure to acquire the mutex, and likely an assertion. Because this
should only occur in the case of a coding defect, this is an improvement
over the previous implementation.
When a mutex fails to be taken or released, and it causes an assertion
to trip, this change makes sure that enough information is provided to
uniquely identify which mutex was at fault.
@celskeggs celskeggs marked this pull request as ready for review February 13, 2025 21:57
@celskeggs
Copy link
Contributor Author

celskeggs commented Feb 13, 2025

@LeStarch I've performed basic testing on this PR, so it should be ready to review.

@thomas-bc I did not add tests for this mutex, because that appeared to require a bigger change. (Maybe a new platform is needed, since none of the default platforms include the stub mutex?) Do you want me to file a ticket for that?

@thomas-bc
Copy link
Collaborator

We can take care of adding those tests in this PR here if you'd like

@celskeggs
Copy link
Contributor Author

Sounds good. Please go ahead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Update Instructions Needed Need to add instructions in the release notes for updates.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants