Commit 03c5291c authored by Michael Hanselmann's avatar Michael Hanselmann
Browse files

locking: Don't schedule pending acq. for short timeout



Scheduling a pending acquisition is relatively expensive and lot of code
is involved. Unless there is already one, a new pipe needs to be opened.
Data structures need to be updated as well, only to be undone shortly
after. This patch adds a small condition to return straight away if the
timeout is shorter than 1ms and the lock couldn't be acquired right
away. Blocking acquisitions are not affected, as are acquisitions with
longer timeouts.

While I tried hard, I could not find a way of writing a test
specifically for this case which wouldn't have involved making
significant other modifications. Other tests already exercise the new
code, though.
Signed-off-by: default avatarMichael Hanselmann <hansmi@google.com>
Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
parent 488a5b2e
......@@ -47,6 +47,10 @@ _DELETED_TEXT = "deleted"
_DEFAULT_PRIORITY = 0
#: Minimum timeout required to consider scheduling a pending acquisition
#: (seconds)
_LOCK_ACQUIRE_MIN_TIMEOUT = (1.0 / 1000)
def ssynchronized(mylock, shared=0):
"""Shared Synchronization decorator.
......@@ -662,6 +666,12 @@ class SharedLock(object):
self.__do_acquire(shared)
return True
# The lock couldn't be acquired right away, so if a timeout is given and is
# considered too short, return right away as scheduling a pending
# acquisition is quite expensive
if timeout is not None and timeout < _LOCK_ACQUIRE_MIN_TIMEOUT:
return False
prioqueue = self.__pending_by_prio.get(priority, None)
if shared:
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment