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

Make SYST.has_wrapped() take &self #438

Open
fralalonde opened this issue May 6, 2022 · 0 comments
Open

Make SYST.has_wrapped() take &self #438

fralalonde opened this issue May 6, 2022 · 0 comments

Comments

@fralalonde
Copy link

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.

@fralalonde fralalonde changed the title Make SYST.has_wrapped() use &self instead of &mut self Make SYST.has_wrapped() take &self May 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant