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.
While I understand the intention in making
SYST.has_wrapped()take&mut selfbecause 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
&mutrequirement 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.
&mutis more about enforcing exclusivity than mutability. In the case ofhas_wrappedthe exclusivity is unwarranted.Thus I contend that
has_wrapped()should be changed to take&self. It could also be madeunsafeto make one think about how it works and retain the original intention behind the current&mut.