Package com.linkedin.venice.utils.locks

Class AutoCloseableLock

java.lang.Object

com.linkedin.venice.utils.locks.AutoCloseableLock

All Implemented Interfaces:

AutoCloseable

Direct Known Subclasses:

AutoCloseableMultiLock, AutoCloseableSingleLock

public abstract class AutoCloseableLock
extends Object
implements AutoCloseable

Concrete implementations are expected to lock their inner lock(s) in their own constructor.

Constructor Summary

Constructors

Constructor	Description
AutoCloseableLock()

Method Summary

Modifier and Type	Method	Description
void	close()	N.B.
static AutoCloseableLock	of(Lock lock)
static AutoCloseableLock	ofMany(Lock... locks)
protected abstract void	unlock()	Concrete implementations should do whatever work is required to unlock their inner lock(s).

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Details

AutoCloseableLock

public AutoCloseableLock()

Method Details

of

public static AutoCloseableLock of(Lock lock)

ofMany

public static AutoCloseableLock ofMany(Lock... locks)

close

public void close()

N.B. Since concurrent calls to close() 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 primitive closed boolean protected by coarse synchronization than to introduce one more object to each instance of AutoCloseableLock.

Specified by:

close in interface AutoCloseable

unlock

protected abstract void unlock()

Concrete implementations should do whatever work is required to unlock their inner lock(s).