@xhanin has kindly brought to my attention the fact that the the current implementation of the DefaultClock (#44) is not perfect. Indeed, the delay field could benefit from the same volatile protection as it has been done for the running field (#20).
Although very unlikely, in the JBotSim use-case described thereafter, a modification made with setTimeUnit() could not be taken into account. Scenario:
- someone actually wants to modify the delay of the
DefaultClock while the clock is running; it is generally intended to be used without user interactions.
- we get very unlucky with CPU caching.
Aside from this unlikely use-case, if someone were to take the DefaultClock as an inspiration for any implementation involving threads, locks and conditions, this might result in spreading an incorrect implementation.
If not to be fixed, I think that at least adding a comment to the delay field would be nice.
@xhanin has kindly brought to my attention the fact that the the current implementation of the
DefaultClock(#44) is not perfect. Indeed, thedelayfield could benefit from the samevolatileprotection as it has been done for therunningfield (#20).Although very unlikely, in the JBotSim use-case described thereafter, a modification made with
setTimeUnit()could not be taken into account. Scenario:DefaultClockwhile the clock is running; it is generally intended to be used without user interactions.Aside from this unlikely use-case, if someone were to take the
DefaultClockas an inspiration for any implementation involving threads, locks and conditions, this might result in spreading an incorrect implementation.If not to be fixed, I think that at least adding a comment to the
delayfield would be nice.