Attempt to lock the object in given
LockMode subject to given
timeout as determined from
LockingPolicy#getTimeout.
An attempt to acquire an SH lock should return immediately(successfully)
irrespective of the number of SH locks and upto a single EX_SH lock already
taken. It should wait only when there are already max number of allowed SH
locks (implementation dependent) taken or an EX lock has been taken.
An attempt to acquire an READ_ONLY lock should return
immediately(successfully) irrespective of the number of SH/READ_ONLY locks
already taken. It should wait only when there are already max number of
allowed SH locks (implementation dependent) taken or one of EX/EX_SH lock
has been taken.
An attempt to acquire EX lock should succeed when there are no other SH,
EX_SH or EX locks already taken for this object. Else it will wait
honouring the provided timeout as determined from
LockingPolicy#getTimeout.
An attempt to acquire EX_SH lock should succeed when there are no other
EX_SH or EX locks already taken for this object. Else it will wait
honouring the provided timeout as determined from
LockingPolicy#getTimeout.
The method has best-effort semantics: The timeout bound cannot be
guaranteed to be a precise upper bound on wait time in Java.
Implementations generally can only attempt to return as soon as possible
after the specified bound. Also, timers in Java do not stop during garbage
collection, so timeouts can occur just because a GC intervened. So, timeout
should be used in a coarse-grained manner. Further, implementations cannot
always guarantee that this method will return at all without blocking
indefinitely when used in unintended ways. For example, deadlocks may be
encountered when called in an unintended context.