Make SYST.has_wrapped() take &self
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Refactor
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- rust
- Domain
- embedded-iot
Research direction
Start by locating SYST::has_wrapped() and the csr.read() operation it uses, then inspect its callers for assumptions about mutable access and thread safety. Evaluate whether changing the receiver to &self or making the method unsafe preserves the documented side effect, and add or update tests showing the intended behavior.
Written by the indexing model from the issue text.
Description
While I understand the intention in making SYST.has_wrapped() take &mut self because of the side effect, I believe the trouble this causes are bigger than any pain it aims to save.
For example, implementing a shared clock, because of &mut requirement one now has to use a mutex before accessing has_wrapped(). The locking operation infers a non-negligible and unwelcome CPU load especially in a time-sensitive and oft-called method.
The register operation csr.read() backing has_wrapped() being inherently atomic in it's operation guarantees that the side effect will always be observed by a single thread. Also, this side-effect is mostly non-deterministic, i.e. one does not "expect" a particular has_wrapped() return value in any situation. It's something that has to be unconditionally checked by every thread and will thus not lead to a race condition.
In a sense, this should be similar to reading an event from a lock-free queue. &mut is more about enforcing exclusivity than mutability. In the case of has_wrapped the exclusivity is unwarranted.
Thus I contend that has_wrapped() should be changed to take &self. It could also be made unsafe to make one think about how it works and retain the original intention behind the current &mut.
- Dominant language
- Rust
- Stars
- 1k
- Forks
- 201
- Avg merge
- 3d 16h
- Merged PRs (30d)
- 3
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from rust-embedded/cortex-m
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
rust-embedded/cortex-m#651 · 5 comments ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
rust-embedded/cortex-m#637 ·
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
rust-embedded/cortex-m#511 · 2 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 52/100
rust-embedded/cortex-m#694 · 1 comment ·
-
Enabling LOBOpen
Difficulty 4/5 3-5 days Newbie friendliness 52/100
rust-embedded/cortex-m#691 · 1 comment ·
All issues in rust-embedded/cortex-m
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
bmander/geomsolver#118 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
Three Windows builds are keyed on a later release than their layoutPossibly taken @ero-qt claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 2 days
-
priority:P3 type:docs
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
sebastian-software/ferroni#253 ·
Maintainers usually reply within 1 day