You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
fralalonde
changed the title
Make SYST.has_wrapped() use &self instead of &mut self
Make SYST.has_wrapped() take &self
May 6, 2022
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: