Package com.linkedin.venice.utils.locks
Class AutoCloseableLock
- java.lang.Object
-
- com.linkedin.venice.utils.locks.AutoCloseableLock
-
- All Implemented Interfaces:
java.lang.AutoCloseable
- Direct Known Subclasses:
AutoCloseableMultiLock
,AutoCloseableSingleLock
public abstract class AutoCloseableLock extends java.lang.Object implements java.lang.AutoCloseable
Concrete implementations are expected to lock their inner lock(s) in their own constructor.
-
-
Constructor Summary
Constructors Constructor Description AutoCloseableLock()
-
Method Summary
All Methods Static Methods Instance Methods Abstract Methods Concrete Methods Modifier and Type Method Description void
close()
N.B.static AutoCloseableLock
of(java.util.concurrent.locks.Lock lock)
static AutoCloseableLock
ofMany(java.util.concurrent.locks.Lock... locks)
protected abstract void
unlock()
Concrete implementations should do whatever work is required to unlock their inner lock(s).
-
-
-
Method Detail
-
of
public static AutoCloseableLock of(java.util.concurrent.locks.Lock lock)
-
ofMany
public static AutoCloseableLock ofMany(java.util.concurrent.locks.Lock... locks)
-
close
public void close()
N.B. Since concurrent calls toclose()
is considered to be an error, there is no point in trying to optimize concurrent access via fine-grained locking or some lock-free construct (e.g.AtomicBoolean
). The synchronized keyword on close is expected to be very cheap in the non-contended case (which, as stated above, is expected to always be true unless we have a bug). Therefore, it is more valuable to minimize the overhead of instances of this class via a primitiveclosed
boolean protected by coarse synchronization than to introduce one more object to each instance ofAutoCloseableLock
.- Specified by:
close
in interfacejava.lang.AutoCloseable
-
unlock
protected abstract void unlock()
Concrete implementations should do whatever work is required to unlock their inner lock(s).
-
-