setField(cmd, "timeout", 3000L);
        // arrays of one lock and one unlock range
        LockingAndXRange lock = new LockingAndXRange(false);
        lock.encode(new byte[20], 0); // initialise fields by encoding to set pid etc (though not needed)
        setField(lock, "pid", 123);
        setField(lock, "byteOffset", 100L);
        setField(lock, "lengthInBytes", 200L);
        LockingAndXRange unlock = new LockingAndXRange(false);

import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.Lock;

/** Forwarding wrapper around a {@code Lock}. */
@J2ktIncompatible
@GwtIncompatible
abstract class ForwardingLock implements Lock {
  abstract Lock delegate();

  @Override
  public void lock() {
    delegate().lock();
  }

  @Override

 *   <li>It is easy for the user to ensure that listeners are never invoked while holding locks.
 * </ul>
 *
 * The last point is subtle. Often the observable object will be managing its own internal state
 * using a lock, however it is dangerous to dispatch listeners while holding a lock because they
 * might run on the {@code directExecutor()} or be otherwise re-entrant (call back into your

import java.util.List;
import java.util.Map;
import java.util.Set;
import java.util.TreeSet;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
import java.util.concurrent.locks.ReentrantReadWriteLock;

import org.apache.maven.api.SessionData;
import org.apache.maven.api.services.MavenException;
import org.apache.maven.api.services.MessageBuilderFactory;

		}()

		dm3rd.Lock(id, source)

		// fmt.Printf("3rd lock obtained after 1st & 2nd locks are released\n")
		time.Sleep(testDrwMutexRefreshCallTimeout)

		dm3rd.Unlock(t.Context())
	}()
	expect += 2*testDrwMutexAcquireTimeout + testDrwMutexRefreshCallTimeout

	go func() {
		defer wg.Done()

		dm3rd.Lock(id, source)

		// Release lock after 10 seconds
		go func() {

### Locks

We have 3 different things that we synchronize on.

#### Http2Connection

This lock guards internal state of each connection. This lock is never held for blocking operations. That means that we acquire the lock, read or write a few fields and release the lock. No I/O and no application-layer callbacks.

#### Http2Stream

 *   <li>It is easy for the user to ensure that listeners are never invoked while holding locks.
 * </ul>
 *
 * The last point is subtle. Often the observable object will be managing its own internal state
 * using a lock, however it is dangerous to dispatch listeners while holding a lock because they
 * might run on the {@code directExecutor()} or be otherwise re-entrant (call back into your

	processVirtualMemoryMaxBytes    = "virtual_memory_max_bytes"
)

var (
	processLocksReadTotalMD           = NewGaugeMD(processLocksReadTotal, "Number of current READ locks on this peer")
	processLocksWriteTotalMD          = NewGaugeMD(processLocksWriteTotal, "Number of current WRITE locks on this peer")
	processCPUTotalSecondsMD          = NewCounterMD(processCPUTotalSeconds, "Total user and system CPU time spent in seconds")

// LockArgs is minimal required values for any dsync compatible lock operation.
type LockArgs struct {
	// Unique ID of lock/unlock request.
	UID string

	// Resources contains single or multiple entries to be locked/unlocked.
	Resources []string

	// Owner represents unique ID for this instance, an owner who originally requested
	// the locked resource, useful primarily in figuring out stale locks.
	Owner string

// has reached zero, i.e when all the readers have given up their locks.
type RLockedFile struct {
	*LockedFile
	mutex sync.Mutex
	refs  int // Holds read lock refs.
}

// IsClosed - Check if the rlocked file is already closed.
func (r *RLockedFile) IsClosed() bool {
	r.mutex.Lock()
	defer r.mutex.Unlock()
	return r.refs == 0
}

// IncLockRef - is used by called to indicate lock refs.
func (r *RLockedFile) IncLockRef() {