In the Simulations tick code, a semaphore is acquired and then the tick() method is called.
There was a deadlock if the pause() method was called from another thread after the semaphore
was acquired but before the tick() method is called. This was due to the fact that tick()
as well as pause() are synchronized, so tick() waits for pause() to finish, but pause()
tries to acquire the semaphore as well (in order to cancel the TimerTask -- the `TimerTask,
once run for the next time, finds out that it can't lock the semaphore and terminates itself).
NOTE: With this fix, we don't use the synchronization property of the mentioned semaphore. It's
now just used as a mutable Boolean which, once false (i.e. it can't be acquired anymore) causes
the TimerTask to terminate itself. We could therefore replace it by something else in the
future, avoiding the synchronization overhead.
In the
Simulations tick code, a semaphore is acquired and then thetick()method is called. There was a deadlock if thepause()method was called from another thread after the semaphore was acquired but before thetick()method is called. This was due to the fact thattick()as well aspause()are synchronized, sotick()waits forpause()to finish, butpause()tries to acquire the semaphore as well (in order to cancel theTimerTask-- the `TimerTask, once run for the next time, finds out that it can't lock the semaphore and terminates itself).NOTE: With this fix, we don't use the synchronization property of the mentioned semaphore. It's now just used as a mutable Boolean which, once false (i.e. it can't be acquired anymore) causes the
TimerTaskto terminate itself. We could therefore replace it by something else in the future, avoiding the synchronization overhead.