util/concurrent/Lock.java

/*
 * Written by Doug Lea with assistance from members of JCP JSR-166
 * Expert Group and released to the public domain. Use, modify, and
 * redistribute this code in any way without acknowledgement.
 */

package java.util.concurrent;

/**
 * <tt>Lock</tt> implementations provide more flexible locking operations than
 * can be obtained using <tt>synchronized</tt> methods and statements.
 *
 * <p>A lock is a tool for controlling access to a shared
 * resource by multiple threads. Commonly, a lock provides exclusive access
 * to a shared resource: only one thread at a time can acquire the
 * lock and all access to the shared resource requires that the lock be
 * acquired first. However, some locks may allow concurrent access to a shared
 * resource, such as the read lock of a {@link ReadWriteLock}.
 *
 * <p>The use of <tt>synchronized</tt> methods or statements provides 
 * access to the implicit monitor lock associated with every object, but
 * forces all lock acquisition and release to occur in a block-structured way:
 * when multiple locks are acquired they must be released in the opposite
 * order, and all locks must be released in the same lexical scope in which
 * they were acquired.
 *
 * <p>While the scoping mechanism for <tt>synchronized</tt> methods and 
 * statements makes it much easier to program with monitor locks,
 * and helps avoid many common programming errors involving locks, there are
 * rare occasions where you need to work with locks in a more flexible way. For
 * example, some advanced algorithms for traversing concurrently accessed data
 * structures require the use of what is called &quot;hand-over-hand&quot; or 
 * &quot;chain locking&quot;: you acquire the lock of node A, then node B, 
 * then release A and acquire C, then release B and acquire D and so on. 
 * Implementations of the <tt>Lock</tt> interface facilitate the use of such 
 * advanced algorithms by allowing a lock to be acquired and released in 
 * different scopes, and allowing multiple locks to be acquired and released 
 * in any order. 
 *
 * <p>With this increased flexibilty comes
 * additional responsibility as the absence of block-structured locking
 * removes the automatic release of locks that occurs with 
 * <tt>synchronized</tt> methods and statements. For the simplest usage
 * the following idiom should be used:
 * <pre><tt>     Lock l = ...; 
 *     l.lock();
 *     try {
 *         // access the resource protected by this lock
 *     } finally {
 *         l.unlock();
 *     }
 * </tt></pre>
 *
 * <p><tt>Lock</tt> implementations provide additional functionality over the 
 * use
 * of <tt>synchronized</tt> methods and statements by providing a non-blocking
 * attempt to acquire a lock ({@link #tryLock()}), an attempt to acquire the
 * lock that can be interrupted ({@link #lockInterruptibly}, and an attempt
 * to acquire the lock that can timeout ({@link #tryLock(long, TimeUnit)}).
 * This additional functionality is also extended to built-in monitor
 * locks through the methods of the {@link Locks} utility class.
 *
 * <p>A <tt>Lock</tt> class can also provide behavior and semantics that is 
 * quite different from that of the implicit monitor lock, such as guaranteed 
 * ordering,
 * non-reentrant usage, or deadlock detection. If an implementation provides
 * such specialised semantics then the implementation must document those
 * semantics.
 *
 * <p>Note that <tt>Lock</tt> instances are just normal objects and can 
 * themselves be used as the target in a <tt>synchronized</tt> statement.
 * Acquiring the
 * monitor lock of a <tt>Lock</tt> instance has no specified relationship
 * with invoking any of the {@link #lock} methods of that instance. 
 * It is recommended that to avoid confusion you never use <tt>Lock</tt>
 * instances in this way, except within their own implementation.
 *
 * <p>Except where noted, passing a <tt>null</tt> value for any parameter 
 * will result in a {@link NullPointerException} being thrown.
 *
 * <h3>Memory Synchronization</h3>
 * <p>All <tt>Lock</tt> implementations <em>must</em> enforce the same
 * memory synchronization semantics as provided by the built-in monitor lock:
 * <ul>
 * <li>A successful lock operation acts like a successful 
 * <tt>monitorEnter</tt> action
 * <li>A successful <tt>unlock</tt> operation acts like a successful
 * <tt>monitorExit</tt> action
 * </ul>
 * Note that unsuccessful locking and unlocking operations, and reentrant
 * locking/unlocking operations, do not require any memory synchronization
 * effects.
 *
 * <h3>Implementation Considerations</h3>
 * <p>It is recognised that the three forms of lock acquisition (interruptible,
 * non-interruptible, and timed) may differ in their ease of implementation
 * on some platforms and in their performance characteristics.
 * In particular, it may be difficult to provide these features and maintain 
 * specific semantics such as ordering guarantees. 
 * Further, the ability to interrupt the acquisition of a lock may not always
 * be feasible to implement on all platforms.
 * <p>Consequently, an implementation is not required to define exactly the 
 * same 
 * guarantees or semantics for all three forms of lock acquistion, nor is it 
 * required to support interruption of the actual lock acquisition.
 * An implementation is required to clearly
 * document the semantics and guarantees provided by each of the locking 
 * methods. It must also obey the interruption semantics as defined in this
 * interface, to the extent that interruption of lock acquisition is 
 * supported: which is either totally, or only on method entry.
 * <p>As interruption generally implies cancellation, and checks for 
 * interruption are often infrequent, an implementation can favor responding
 * to an interrupt over normal method return. This is true even if it can be
 * shown that the interrupt occurred after another action may have unblocked
 * the thread. An implementation should document this behaviour. 
 *
 *
 * @see ReentrantLock
 * @see Condition
 * @see ReadWriteLock
 * @see Locks
 *
 * @since 1.5
 * @spec JSR-166
 * @revised $Date: 2003/06/24 14:34:48 $
 * @editor $Author: dl $
 * @author Doug Lea
 *
 **/
public interface Lock {

    /**
     * Acquires the lock. 
     * <p>Acquires the lock if it is available and returns immediately.
     * <p>If the lock is not available then
     * the current thread becomes disabled for thread scheduling 
     * purposes and lies dormant until the lock has been acquired.
     * <p><b>Implementation Considerations</b>
     * <p>A <tt>Lock</tt> implementation may be able to detect 
     * erroneous use of the lock, such as an invocation that would cause 
     * deadlock, and may throw an (unchecked) exception in such circumstances. 
     * The circumstances and the exception type must be documented by that 
     * <tt>Lock</tt> implementation.
     *
     **/
    void lock();

    /**
     * Acquires the lock unless the current thread is  
     * {@link Thread#interrupt interrupted}. 
     * <p>Acquires the lock if it is available and returns immediately.
     * <p>If the lock is not available then
     * the current thread thread becomes disabled for thread scheduling 
     * purposes and lies dormant until one of two things happens:
     * <ul>
     * <li> The lock is acquired by the current thread; or
     * <li> Some other thread {@link Thread#interrupt interrupts} the current
     * thread, and interruption of lock acquisition is supported.
     * </ul>
     * <p>If the current thread:
     * <ul>
     * <li>has its interrupted status set on entry to this method; or 
     * <li>is {@link Thread#interrupt interrupted} while acquiring 
     * the lock, and interruption of lock acquisition is supported, 
     * </ul>
     * then {@link InterruptedException} is thrown and the current thread's 
     * interrupted status is cleared. 
     *
     * <p><b>Implementation Considerations</b>
     * <p>The ability to interrupt a lock acquisition in some implementations
     * may not be possible, and if possible could reasonably be foreseen to 
     * be an expensive operation. 
     * The programmer should be aware that this may be the case. An
     * implementation should document when this is the case.
     * <p>An implementation can favor responding to an interrupt over 
     * normal method return.
     * <p>A <tt>Lock</tt> implementation may be able to detect 
     * erroneous use of the lock, such as an invocation that would cause 
     * deadlock, and may throw an (unchecked) exception in such circumstances. 
     * The circumstances and the exception type must be documented by that
     * <tt>Lock</tt> implementation.
     *
     * @throws InterruptedException if the current thread is interrupted
     * while acquiring the lock (and interruption of lock acquisition is 
     * supported).
     *
     * @see Thread#interrupt
     *
     **/
    void lockInterruptibly() throws InterruptedException;


    /**
     * Acquires the lock only if it is free at the time of invocation.
     * <p>Acquires the lock if it is available and returns immediately
     * with the value <tt>true</tt>.
     * <p>If the lock is not available then this method will return 
     * immediately with the value <tt>false</tt>.
     * <p>A typical usage idiom for this method would be:
     * <pre>
     *      Lock lock = ...;
     *      if (lock.tryLock()) {
     *          try {
     *              // manipulate protected state
     *          } finally {
     *              lock.unlock();
     *          }
     *      } else {
     *          // perform alternative actions
     *      }
     * </pre>
     * This usage ensures that the lock is unlocked if it was acquired, and
     * doesn't try to unlock if the lock was not acquired.
     *
     * @return <tt>true</tt> if the lock was acquired and <tt>false</tt>
     * otherwise.
     **/
    boolean tryLock();

    /**
     * Acquires the lock if it is free within the given waiting time and the
     * current thread has not been {@link Thread#interrupt interrupted}.
     * <p>Acquires the lock if it is available and returns immediately
     * with the value <tt>true</tt>.
     * <p>If the lock is not available then
     * the current thread becomes disabled for thread scheduling 
     * purposes and lies dormant until one of three things happens:
     * <ul>
     * <li> The lock is acquired by the current thread; or
     * <li> Some other thread {@link Thread#interrupt interrupts} the current
     * thread, and interruption of lock acquisition is supported; or
     * <li> The specified waiting time elapses
     * </ul>
     * <p>If the lock is acquired then the value <tt>true</tt> is returned.
     * <p>If the current thread:
     * <ul>
     * <li>has its interrupted status set on entry to this method; or 
     * <li>is {@link Thread#interrupt interrupted} while acquiring 
     * the lock, and interruption of lock acquisition is supported, 
     * </ul>
     * then {@link InterruptedException} is thrown and the current thread's 
     * interrupted status is cleared. 
     * <p>If the specified waiting time elapses then the value <tt>false</tt>
     * is returned.
     * The given waiting time is a best-effort lower bound. If the time is 
     * less than or equal to zero, the method will not wait at all.
     *
     * <p><b>Implementation Considerations</b>
     * <p>The ability to interrupt a lock acquisition in some implementations
     * may not be possible, and if possible could reasonably be foreseen to 
     * be an expensive operation. 
     * The programmer should be aware that this may be the case. An
     * implementation should document when this is the case.
     * <p>An implementation can favor responding to an interrupt over normal 
     * method return, or reporting a timeout.
     * <p>A <tt>Lock</tt> implementation may be able to detect 
     * erroneous use of the lock, such as an invocation that would cause 
     * deadlock, and may throw an (unchecked) exception in such circumstances. 
     * The circumstances and the exception type must be documented by that 
     * <tt>Lock</tt> implementation.
     *
     * @param time the maximum time to wait for the lock
     * @param unit the time unit of the <tt>time</tt> argument.
     * @return <tt>true</tt> if the lock was acquired and <tt>false</tt>
     * if the waiting time elapsed before the lock was acquired.
     *
     * @throws InterruptedException if the current thread is interrupted
     * while acquiring the lock (and interruption of lock acquisition is 
     * supported).
     *
     * @see Thread#interrupt
     *
     **/
    boolean tryLock(long time, TimeUnit unit) throws InterruptedException;

    /**
     * Releases the lock.
     * <p><b>Implementation Considerations</b>
     * <p>A <tt>Lock</tt> implementation will usually impose
     * restrictions on which thread can release a lock (typically only the
     * holder of the lock can release it) and may throw
     * an (unchecked) exception if the restriction is violated.
     * Any restrictions and the exception
     * type must be documented by that <tt>Lock</tt> implementation.
     **/
    void unlock();

    /**
     * Returns a {@link Condition} instance that is bound to this <tt>Lock</tt>
     * instance.
     * <p>Conditions are primarily used with the built-in locking provided by
     * <tt>synchronized</tt> methods and statements 
     * (see {@link Locks#newConditionFor}), but in some rare circumstances it 
     * can be useful to wait for a condition when working with a data 
     * structure that is accessed using a stand-alone <tt>Lock</tt> instance 
     * (see {@link ReentrantLock}). 
     * <p>Before waiting on the condition the lock must be held by the 
     * current thread. 
     * A call to {@link Condition#await()} will atomically release the lock 
     * before waiting and re-acquire the lock before the wait returns.
     * <p><b>Implementation Considerations</b>
     * <p>The exact operation of the {@link Condition} instance depends on the
     * <tt>Lock</tt> implementation and must be documented by that
     * implementation.
     * 
     * @return A {@link Condition} instance for this <tt>Lock</tt> instance.
     * @throws UnsupportedOperationException if this <tt>Lock</tt> 
     * implementation does not support conditions.
     **/
    Condition newCondition();

}


Revision:	1.6
Committed:	Tue Jul 8 00:46:34 2003 UTC (20 years, 11 months ago) by dl
Branch:	MAIN
CVS Tags:	HEAD
Changes since 1.5:	+2 -2 lines
State:	*FILE REMOVED*
Log Message:	Locks in subpackage; fairness params added
#	User	Rev	Content
1	dl	1.2	/*
2			* Written by Doug Lea with assistance from members of JCP JSR-166
3			* Expert Group and released to the public domain. Use, modify, and
4			* redistribute this code in any way without acknowledgement.
5			*/
6
7	tim	1.1	package java.util.concurrent;
8
9			/**
10			* <tt>Lock</tt> implementations provide more flexible locking operations than
11			* can be obtained using <tt>synchronized</tt> methods and statements.
12			*
13			* <p>A lock is a tool for controlling access to a shared
14			* resource by multiple threads. Commonly, a lock provides exclusive access
15			* to a shared resource: only one thread at a time can acquire the
16			* lock and all access to the shared resource requires that the lock be
17			* acquired first. However, some locks may allow concurrent access to a shared
18			* resource, such as the read lock of a {@link ReadWriteLock}.
19			*
20			* <p>The use of <tt>synchronized</tt> methods or statements provides
21			* access to the implicit monitor lock associated with every object, but
22			* forces all lock acquisition and release to occur in a block-structured way:
23			* when multiple locks are acquired they must be released in the opposite
24			* order, and all locks must be released in the same lexical scope in which
25			* they were acquired.
26			*
27			* <p>While the scoping mechanism for <tt>synchronized</tt> methods and
28			* statements makes it much easier to program with monitor locks,
29			* and helps avoid many common programming errors involving locks, there are
30			* rare occasions where you need to work with locks in a more flexible way. For
31			* example, some advanced algorithms for traversing concurrently accessed data
32			* structures require the use of what is called "hand-over-hand" or
33			* "chain locking": you acquire the lock of node A, then node B,
34			* then release A and acquire C, then release B and acquire D and so on.
35			* Implementations of the <tt>Lock</tt> interface facilitate the use of such
36			* advanced algorithms by allowing a lock to be acquired and released in
37			* different scopes, and allowing multiple locks to be acquired and released
38			* in any order.
39			*
40			* <p>With this increased flexibilty comes
41			* additional responsibility as the absence of block-structured locking
42			* removes the automatic release of locks that occurs with
43			* <tt>synchronized</tt> methods and statements. For the simplest usage
44			* the following idiom should be used:
45			* <pre><tt> Lock l = ...;
46			* l.lock();
47			* try {
48			* // access the resource protected by this lock
49			* } finally {
50			* l.unlock();
51			* }
52			* </tt></pre>
53			*
54			* <p><tt>Lock</tt> implementations provide additional functionality over the
55			* use
56			* of <tt>synchronized</tt> methods and statements by providing a non-blocking
57			* attempt to acquire a lock ({@link #tryLock()}), an attempt to acquire the
58			* lock that can be interrupted ({@link #lockInterruptibly}, and an attempt
59			* to acquire the lock that can timeout ({@link #tryLock(long, TimeUnit)}).
60	dholmes	1.3	* This additional functionality is also extended to built-in monitor
61	tim	1.1	* locks through the methods of the {@link Locks} utility class.
62			*
63			* <p>A <tt>Lock</tt> class can also provide behavior and semantics that is
64			* quite different from that of the implicit monitor lock, such as guaranteed
65			* ordering,
66			* non-reentrant usage, or deadlock detection. If an implementation provides
67			* such specialised semantics then the implementation must document those
68			* semantics.
69			*
70			* <p>Note that <tt>Lock</tt> instances are just normal objects and can
71			* themselves be used as the target in a <tt>synchronized</tt> statement.
72			* Acquiring the
73			* monitor lock of a <tt>Lock</tt> instance has no specified relationship
74			* with invoking any of the {@link #lock} methods of that instance.
75			* It is recommended that to avoid confusion you never use <tt>Lock</tt>
76			* instances in this way, except within their own implementation.
77			*
78			* <p>Except where noted, passing a <tt>null</tt> value for any parameter
79			* will result in a {@link NullPointerException} being thrown.
80			*
81			* <h3>Memory Synchronization</h3>
82			* <p>All <tt>Lock</tt> implementations <em>must</em> enforce the same
83			* memory synchronization semantics as provided by the built-in monitor lock:
84			* <ul>
85			* <li>A successful lock operation acts like a successful
86			* <tt>monitorEnter</tt> action
87			* <li>A successful <tt>unlock</tt> operation acts like a successful
88			* <tt>monitorExit</tt> action
89			* </ul>
90			* Note that unsuccessful locking and unlocking operations, and reentrant
91			* locking/unlocking operations, do not require any memory synchronization
92			* effects.
93			*
94			* <h3>Implementation Considerations</h3>
95			* <p>It is recognised that the three forms of lock acquisition (interruptible,
96			* non-interruptible, and timed) may differ in their ease of implementation
97			* on some platforms and in their performance characteristics.
98			* In particular, it may be difficult to provide these features and maintain
99			* specific semantics such as ordering guarantees.
100			* Further, the ability to interrupt the acquisition of a lock may not always
101			* be feasible to implement on all platforms.
102			* <p>Consequently, an implementation is not required to define exactly the
103			* same
104			* guarantees or semantics for all three forms of lock acquistion, nor is it
105			* required to support interruption of the actual lock acquisition.
106			* An implementation is required to clearly
107			* document the semantics and guarantees provided by each of the locking
108			* methods. It must also obey the interruption semantics as defined in this
109			* interface, to the extent that interruption of lock acquisition is
110			* supported: which is either totally, or only on method entry.
111	dholmes	1.4	* <p>As interruption generally implies cancellation, and checks for
112			* interruption are often infrequent, an implementation can favor responding
113			* to an interrupt over normal method return. This is true even if it can be
114			* shown that the interrupt occurred after another action may have unblocked
115			* the thread. An implementation should document this behaviour.
116	tim	1.1	*
117			*
118			* @see ReentrantLock
119			* @see Condition
120			* @see ReadWriteLock
121			* @see Locks
122			*
123			* @since 1.5
124			* @spec JSR-166
125	dl	1.6	* @revised $Date: 2003/06/24 14:34:48 $
126			* @editor $Author: dl $
127	dl	1.5	* @author Doug Lea
128	tim	1.1	*
129	dl	1.2	**/
130	tim	1.1	public interface Lock {
131
132			/**
133			* Acquires the lock.
134			* <p>Acquires the lock if it is available and returns immediately.
135			* <p>If the lock is not available then
136			* the current thread becomes disabled for thread scheduling
137			* purposes and lies dormant until the lock has been acquired.
138			* <p><b>Implementation Considerations</b>
139			* <p>A <tt>Lock</tt> implementation may be able to detect
140			* erroneous use of the lock, such as an invocation that would cause
141			* deadlock, and may throw an (unchecked) exception in such circumstances.
142			* The circumstances and the exception type must be documented by that
143			* <tt>Lock</tt> implementation.
144			*
145	dl	1.2	**/
146	dl	1.5	void lock();
147	tim	1.1
148			/**
149			* Acquires the lock unless the current thread is
150			* {@link Thread#interrupt interrupted}.
151			* <p>Acquires the lock if it is available and returns immediately.
152			* <p>If the lock is not available then
153	dl	1.2	* the current thread thread becomes disabled for thread scheduling
154	tim	1.1	* purposes and lies dormant until one of two things happens:
155			* <ul>
156			* <li> The lock is acquired by the current thread; or
157			* <li> Some other thread {@link Thread#interrupt interrupts} the current
158			* thread, and interruption of lock acquisition is supported.
159			* </ul>
160			* <p>If the current thread:
161			* <ul>
162			* <li>has its interrupted status set on entry to this method; or
163	dholmes	1.4	* <li>is {@link Thread#interrupt interrupted} while acquiring
164	tim	1.1	* the lock, and interruption of lock acquisition is supported,
165			* </ul>
166			* then {@link InterruptedException} is thrown and the current thread's
167			* interrupted status is cleared.
168			*
169			* <p><b>Implementation Considerations</b>
170			* <p>The ability to interrupt a lock acquisition in some implementations
171			* may not be possible, and if possible could reasonably be foreseen to
172			* be an expensive operation.
173			* The programmer should be aware that this may be the case. An
174			* implementation should document when this is the case.
175	dholmes	1.4	* <p>An implementation can favor responding to an interrupt over
176			* normal method return.
177	tim	1.1	* <p>A <tt>Lock</tt> implementation may be able to detect
178			* erroneous use of the lock, such as an invocation that would cause
179			* deadlock, and may throw an (unchecked) exception in such circumstances.
180			* The circumstances and the exception type must be documented by that
181			* <tt>Lock</tt> implementation.
182			*
183			* @throws InterruptedException if the current thread is interrupted
184	dholmes	1.4	* while acquiring the lock (and interruption of lock acquisition is
185			* supported).
186	tim	1.1	*
187			* @see Thread#interrupt
188			*
189	dl	1.2	**/
190	dl	1.5	void lockInterruptibly() throws InterruptedException;
191	tim	1.1
192
193			/**
194			* Acquires the lock only if it is free at the time of invocation.
195			* <p>Acquires the lock if it is available and returns immediately
196			* with the value <tt>true</tt>.
197			* <p>If the lock is not available then this method will return
198			* immediately with the value <tt>false</tt>.
199			* <p>A typical usage idiom for this method would be:
200			* <pre>
201			* Lock lock = ...;
202			* if (lock.tryLock()) {
203			* try {
204			* // manipulate protected state
205			* } finally {
206			* lock.unlock();
207			* }
208			* } else {
209			* // perform alternative actions
210			* }
211			* </pre>
212			* This usage ensures that the lock is unlocked if it was acquired, and
213			* doesn't try to unlock if the lock was not acquired.
214			*
215			* @return <tt>true</tt> if the lock was acquired and <tt>false</tt>
216			* otherwise.
217	dl	1.2	**/
218	dl	1.5	boolean tryLock();
219	tim	1.1
220			/**
221			* Acquires the lock if it is free within the given waiting time and the
222			* current thread has not been {@link Thread#interrupt interrupted}.
223			* <p>Acquires the lock if it is available and returns immediately
224			* with the value <tt>true</tt>.
225			* <p>If the lock is not available then
226			* the current thread becomes disabled for thread scheduling
227			* purposes and lies dormant until one of three things happens:
228			* <ul>
229			* <li> The lock is acquired by the current thread; or
230			* <li> Some other thread {@link Thread#interrupt interrupts} the current
231			* thread, and interruption of lock acquisition is supported; or
232			* <li> The specified waiting time elapses
233			* </ul>
234			* <p>If the lock is acquired then the value <tt>true</tt> is returned.
235			* <p>If the current thread:
236			* <ul>
237			* <li>has its interrupted status set on entry to this method; or
238	dholmes	1.4	* <li>is {@link Thread#interrupt interrupted} while acquiring
239	tim	1.1	* the lock, and interruption of lock acquisition is supported,
240			* </ul>
241			* then {@link InterruptedException} is thrown and the current thread's
242			* interrupted status is cleared.
243			* <p>If the specified waiting time elapses then the value <tt>false</tt>
244			* is returned.
245			* The given waiting time is a best-effort lower bound. If the time is
246			* less than or equal to zero, the method will not wait at all.
247			*
248			* <p><b>Implementation Considerations</b>
249			* <p>The ability to interrupt a lock acquisition in some implementations
250			* may not be possible, and if possible could reasonably be foreseen to
251			* be an expensive operation.
252			* The programmer should be aware that this may be the case. An
253			* implementation should document when this is the case.
254	dholmes	1.4	* <p>An implementation can favor responding to an interrupt over normal
255			* method return, or reporting a timeout.
256	tim	1.1	* <p>A <tt>Lock</tt> implementation may be able to detect
257			* erroneous use of the lock, such as an invocation that would cause
258			* deadlock, and may throw an (unchecked) exception in such circumstances.
259			* The circumstances and the exception type must be documented by that
260			* <tt>Lock</tt> implementation.
261			*
262	dl	1.2	* @param time the maximum time to wait for the lock
263			* @param unit the time unit of the <tt>time</tt> argument.
264	tim	1.1	* @return <tt>true</tt> if the lock was acquired and <tt>false</tt>
265			* if the waiting time elapsed before the lock was acquired.
266			*
267			* @throws InterruptedException if the current thread is interrupted
268	dholmes	1.4	* while acquiring the lock (and interruption of lock acquisition is
269			* supported).
270	tim	1.1	*
271			* @see Thread#interrupt
272			*
273	dl	1.2	**/
274	dl	1.5	boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
275	tim	1.1
276			/**
277			* Releases the lock.
278			* <p><b>Implementation Considerations</b>
279			* <p>A <tt>Lock</tt> implementation will usually impose
280			* restrictions on which thread can release a lock (typically only the
281			* holder of the lock can release it) and may throw
282			* an (unchecked) exception if the restriction is violated.
283			* Any restrictions and the exception
284			* type must be documented by that <tt>Lock</tt> implementation.
285	dl	1.2	**/
286	dl	1.5	void unlock();
287	tim	1.1
288			/**
289			* Returns a {@link Condition} instance that is bound to this <tt>Lock</tt>
290			* instance.
291			* <p>Conditions are primarily used with the built-in locking provided by
292			* <tt>synchronized</tt> methods and statements
293			* (see {@link Locks#newConditionFor}), but in some rare circumstances it
294			* can be useful to wait for a condition when working with a data
295			* structure that is accessed using a stand-alone <tt>Lock</tt> instance
296			* (see {@link ReentrantLock}).
297			* <p>Before waiting on the condition the lock must be held by the
298			* current thread.
299			* A call to {@link Condition#await()} will atomically release the lock
300			* before waiting and re-acquire the lock before the wait returns.
301			* <p><b>Implementation Considerations</b>
302			* <p>The exact operation of the {@link Condition} instance depends on the
303			* <tt>Lock</tt> implementation and must be documented by that
304			* implementation.
305			*
306			* @return A {@link Condition} instance for this <tt>Lock</tt> instance.
307			* @throws UnsupportedOperationException if this <tt>Lock</tt>
308			* implementation does not support conditions.
309	dl	1.2	**/
310	dl	1.5	Condition newCondition();
311	tim	1.1
312			}
313
314
315
316
317
318
319
320
321
322
323
324