🕰️ Use monotonic clock in Lock (and tests)

During a call to `acquire()`, if the call is `blocking` and has a
`blocking_timeout` set, it uses `time.time()` calls to determine when to
give up attempting to acquire the lock.

However, since `time.time()` is marked as "adjustable", it is possible
for it to go backwards or forwards at a rate other than 1 second per
second, meaning the spinloop may exit earlier or later than expected.

By changing the implementation to use `time.monotonic()`, which is
guaranteed to never go backwards, and not be affected by system clock
updates, this potential problem is fixed.

For the same reason, some time dependent lock tests have also been
changed to use `time.monotonic()`.

1 files changed, 4 insertions, 4 deletions

diff --git a/tests/test_lock.py b/tests/test_lock.py
index 8bb3c7e..fa76385 100644
--- a/tests/test_lock.py
+++ b/tests/test_lock.py
@@ -101,10 +101,10 @@ class TestLock:
         bt = 0.2
         sleep = 0.05
         lock2 = self.get_lock(r, 'foo', sleep=sleep, blocking_timeout=bt)
-        start = time.time()
+        start = time.monotonic()
         assert not lock2.acquire()
         # The elapsed duration should be less than the total blocking_timeout
-        assert bt > (time.time() - start) > bt - sleep
+        assert bt > (time.monotonic() - start) > bt - sleep
         lock1.release()
 
     def test_context_manager(self, r):
@@ -126,11 +126,11 @@ class TestLock:
         sleep = 60
         bt = 1
         lock2 = self.get_lock(r, 'foo', sleep=sleep, blocking_timeout=bt)
-        start = time.time()
+        start = time.monotonic()
         assert not lock2.acquire()
         # the elapsed timed is less than the blocking_timeout as the lock is
         # unattainable given the sleep/blocking_timeout configuration
-        assert bt > (time.time() - start)
+        assert bt > (time.monotonic() - start)
         lock1.release()
 
     def test_releasing_unlocked_lock_raises_error(self, r):