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

feat(threads): add mutex with priority inheritance #398

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

elenaf9
Copy link
Collaborator

@elenaf9 elenaf9 commented Sep 5, 2024

Description

Add a mutex implementation analogous to the existing Lock, with additional priority inheritance.
Unfortunately I don't think we can directly reuse Lock, because we need access to the inner ThreadList.

The PR also moves all synchronization primitives into a new sync submodule. Any objections?

Issues/PRs references

Issue: #321.

Depends on

Open Questions

Change checklist

  • I have cleaned up my commit history and squashed fixup commits.
  • I have followed the Coding Conventions.
  • I have performed a self-review of my own code.
  • I have made corresponding changes to the documentation.

@elenaf9
Copy link
Collaborator Author

elenaf9 commented Oct 2, 2024

I've rebased now, and moved the threading-mutex example into a threading-mutex test instead, analogous to the thread-lock test.

@elenaf9 elenaf9 marked this pull request as ready for review October 2, 2024 13:46
@kaspar030
Copy link
Collaborator

The PR also moves all synchronization primitives into a new sync submodule. Any objections?

No objections. How hard is it to chop that into another PR that we can merge right away?

@elenaf9 elenaf9 mentioned this pull request Oct 2, 2024
4 tasks
@elenaf9
Copy link
Collaborator Author

elenaf9 commented Oct 2, 2024

The PR also moves all synchronization primitives into a new sync submodule. Any objections?

No objections. How hard is it to chop that into another PR that we can merge right away?

Not hard at all 🙂 #452.

Copy link
Collaborator

@ROMemories ROMemories left a comment

Choose a reason for hiding this comment

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

I'll leave @kaspar030 review the rest of the implementation regarding priority inheritance; I have a couple of important questions regarding safety that I left as inline comments.

On another note, when should we use that new mutex? Should we replace our uses of embassy_sync::mutex::Mutex with it?

tests/threading-mutex/Cargo.toml Outdated Show resolved Hide resolved
src/riot-rs-threads/src/sync/mutex.rs Show resolved Hide resolved
src/riot-rs-threads/src/sync/mutex.rs Outdated Show resolved Hide resolved
src/riot-rs-threads/src/sync/mutex.rs Outdated Show resolved Hide resolved
src/riot-rs-threads/src/sync/mutex.rs Show resolved Hide resolved
src/riot-rs-threads/src/sync/mutex.rs Show resolved Hide resolved
src/riot-rs-threads/src/sync/mutex.rs Show resolved Hide resolved
src/riot-rs-threads/src/sync/mutex.rs Show resolved Hide resolved
src/riot-rs-threads/src/threadlist.rs Show resolved Hide resolved
src/riot-rs-threads/src/sync/mutex.rs Show resolved Hide resolved
@elenaf9
Copy link
Collaborator Author

elenaf9 commented Oct 3, 2024

On another note, when should we use that new mutex? Should we replace our uses of embassy_sync::mutex::Mutex with it?

Tldr: embassy_sync::mutex::Mutex is for usage inside of async tasks, riot_rs_threads::sync::Mutex for threads without an embassy executor.

embassy_sync::mutex::Mutex is the correct choice if we have (multiple) async tasks, because it only blocks the waiting task, and other tasks on the same executor can still run. The riot_rs_threads::sync::Mutex can a) only be used with a executor_thread (otherwise it'd panic when its not inside a thread context, e.g. in case of the executor-interrupt), and b) always block the whole thread and thus also all other tasks that are running on the same executor.

The riot_rs_threads::sync::Mutex is for non-async contexts. This could also be realized with the embassy Mutex + block_on, but the new Mutex has a smaller overhead and the priority inheritance feature.

@elenaf9 elenaf9 mentioned this pull request Oct 12, 2024
12 tasks
@elenaf9 elenaf9 force-pushed the threads/mutex branch 2 times, most recently from e55aa70 to 9c0776e Compare October 12, 2024 13:02
This demonstrates how multiple threads can wait for the same mutex,
get unblocked by priority, and the owning thread inherits the priority
of the highest waiting thread.
src/riot-rs-threads/src/sync/mutex.rs Outdated Show resolved Hide resolved
src/riot-rs-threads/src/sync/mutex.rs Show resolved Hide resolved
src/riot-rs-threads/src/sync/mutex.rs Show resolved Hide resolved
src/riot-rs-threads/src/sync/mutex.rs Show resolved Hide resolved
Apply suggestions from code review

Co-authored-by: ROMemories <152802150+ROMemories@users.noreply.github.com>
Co-authored-by: ROMemories <152802150+ROMemories@users.noreply.github.com>
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.

3 participants