DefaultClock volatile setTimeUnit

[remikey]

@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.

[acasteigts]

Both seem equally fine. Please do as you see fit.

[remikey]

In branch fix/98-defaultclock-volatile-timeunit:

• renamed delay field into timeUnit to fit its setter/getter

• turned timeUnit into volatile

  Performance tests in the DefaultClock's general usecase did not show a significant difference between the implementations with and without the volatile keyword.

[remikey]

merged into develop.