-
Notifications
You must be signed in to change notification settings - Fork 139
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
Comments
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
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 accessinghas_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()
backinghas_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 particularhas_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 ofhas_wrapped
the exclusivity is unwarranted.Thus I contend that
has_wrapped()
should be changed to take&self
. It could also be madeunsafe
to make one think about how it works and retain the original intention behind the current&mut
.The text was updated successfully, but these errors were encountered: