Skip to content

Commit 6ab398e

Browse files
BobHansonBobHanson
committed
adding java.util.concurrent.locks
empty classes only
1 parent edacf79 commit 6ab398e

File tree

8 files changed

+4410
-0
lines changed

8 files changed

+4410
-0
lines changed

‎sources/net.sf.j2s.java.core/dist/SwingJS-site.zip‎

5.43 KB
Binary file not shown.

‎sources/net.sf.j2s.java.core/src/java/lang/Runtime.java‎

Lines changed: 920 additions & 0 deletions
Large diffs are not rendered by default.

‎sources/net.sf.j2s.java.core/src/java/util/concurrent/locks/Condition.java‎

Lines changed: 464 additions & 0 deletions
Large diffs are not rendered by default.

‎sources/net.sf.j2s.java.core/src/java/util/concurrent/locks/Lock.java‎

Lines changed: 356 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,356 @@
1+
/*
2+
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
3+
*
4+
* This code is free software; you can redistribute it and/or modify it
5+
* under the terms of the GNU General Public License version 2 only, as
6+
* published by the Free Software Foundation. Oracle designates this
7+
* particular file as subject to the "Classpath" exception as provided
8+
* by Oracle in the LICENSE file that accompanied this code.
9+
*
10+
* This code is distributed in the hope that it will be useful, but WITHOUT
11+
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
12+
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
13+
* version 2 for more details (a copy is included in the LICENSE file that
14+
* accompanied this code).
15+
*
16+
* You should have received a copy of the GNU General Public License version
17+
* 2 along with this work; if not, write to the Free Software Foundation,
18+
* Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
19+
*
20+
* Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
21+
* or visit www.oracle.com if you need additional information or have any
22+
* questions.
23+
*/
24+
25+
/*
26+
* This file is available under and governed by the GNU General Public
27+
* License version 2 only, as published by the Free Software Foundation.
28+
* However, the following notice accompanied the original version of this
29+
* file:
30+
*
31+
* Written by Doug Lea with assistance from members of JCP JSR-166
32+
* Expert Group and released to the public domain, as explained at
33+
* http://creativecommons.org/licenses/publicdomain
34+
*/
35+
36+
package java.util.concurrent.locks;
37+
import java.util.concurrent.TimeUnit;
38+
39+
/**
40+
* {@code Lock} implementations provide more extensive locking
41+
* operations than can be obtained using {@code synchronized} methods
42+
* and statements. They allow more flexible structuring, may have
43+
* quite different properties, and may support multiple associated
44+
* {@link Condition} objects.
45+
*
46+
* <p>A lock is a tool for controlling access to a shared resource by
47+
* multiple threads. Commonly, a lock provides exclusive access to a
48+
* shared resource: only one thread at a time can acquire the lock and
49+
* all access to the shared resource requires that the lock be
50+
* acquired first. However, some locks may allow concurrent access to
51+
* a shared resource, such as the read lock of a {@link ReadWriteLock}.
52+
*
53+
* <p>The use of {@code synchronized} methods or statements provides
54+
* access to the implicit monitor lock associated with every object, but
55+
* forces all lock acquisition and release to occur in a block-structured way:
56+
* when multiple locks are acquired they must be released in the opposite
57+
* order, and all locks must be released in the same lexical scope in which
58+
* they were acquired.
59+
*
60+
* <p>While the scoping mechanism for {@code synchronized} methods
61+
* and statements makes it much easier to program with monitor locks,
62+
* and helps avoid many common programming errors involving locks,
63+
* there are occasions where you need to work with locks in a more
64+
* flexible way. For example, some algorithms for traversing
65+
* concurrently accessed data structures require the use of
66+
* &quot;hand-over-hand&quot; or &quot;chain locking&quot;: you
67+
* acquire the lock of node A, then node B, then release A and acquire
68+
* C, then release B and acquire D and so on. Implementations of the
69+
* {@code Lock} interface enable the use of such techniques by
70+
* allowing a lock to be acquired and released in different scopes,
71+
* and allowing multiple locks to be acquired and released in any
72+
* order.
73+
*
74+
* <p>With this increased flexibility comes additional
75+
* responsibility. The absence of block-structured locking removes the
76+
* automatic release of locks that occurs with {@code synchronized}
77+
* methods and statements. In most cases, the following idiom
78+
* should be used:
79+
*
80+
* <pre><tt> Lock l = ...;
81+
* l.lock();
82+
* try {
83+
* // access the resource protected by this lock
84+
* } finally {
85+
* l.unlock();
86+
* }
87+
* </tt></pre>
88+
*
89+
* When locking and unlocking occur in different scopes, care must be
90+
* taken to ensure that all code that is executed while the lock is
91+
* held is protected by try-finally or try-catch to ensure that the
92+
* lock is released when necessary.
93+
*
94+
* <p>{@code Lock} implementations provide additional functionality
95+
* over the use of {@code synchronized} methods and statements by
96+
* providing a non-blocking attempt to acquire a lock ({@link
97+
* #tryLock()}), an attempt to acquire the lock that can be
98+
* interrupted ({@link #lockInterruptibly}, and an attempt to acquire
99+
* the lock that can timeout ({@link #tryLock(long, TimeUnit)}).
100+
*
101+
* <p>A {@code Lock} class can also provide behavior and semantics
102+
* that is quite different from that of the implicit monitor lock,
103+
* such as guaranteed ordering, non-reentrant usage, or deadlock
104+
* detection. If an implementation provides such specialized semantics
105+
* then the implementation must document those semantics.
106+
*
107+
* <p>Note that {@code Lock} instances are just normal objects and can
108+
* themselves be used as the target in a {@code synchronized} statement.
109+
* Acquiring the
110+
* monitor lock of a {@code Lock} instance has no specified relationship
111+
* with invoking any of the {@link #lock} methods of that instance.
112+
* It is recommended that to avoid confusion you never use {@code Lock}
113+
* instances in this way, except within their own implementation.
114+
*
115+
* <p>Except where noted, passing a {@code null} value for any
116+
* parameter will result in a {@link NullPointerException} being
117+
* thrown.
118+
*
119+
* <h3>Memory Synchronization</h3>
120+
*
121+
* <p>All {@code Lock} implementations <em>must</em> enforce the same
122+
* memory synchronization semantics as provided by the built-in monitor
123+
* lock, as described in <a href="http://java.sun.com/docs/books/jls/">
124+
* The Java Language Specification, Third Edition (17.4 Memory Model)</a>:
125+
* <ul>
126+
* <li>A successful {@code lock} operation has the same memory
127+
* synchronization effects as a successful <em>Lock</em> action.
128+
* <li>A successful {@code unlock} operation has the same
129+
* memory synchronization effects as a successful <em>Unlock</em> action.
130+
* </ul>
131+
*
132+
* Unsuccessful locking and unlocking operations, and reentrant
133+
* locking/unlocking operations, do not require any memory
134+
* synchronization effects.
135+
*
136+
* <h3>Implementation Considerations</h3>
137+
*
138+
* <p> The three forms of lock acquisition (interruptible,
139+
* non-interruptible, and timed) may differ in their performance
140+
* characteristics, ordering guarantees, or other implementation
141+
* qualities. Further, the ability to interrupt the <em>ongoing</em>
142+
* acquisition of a lock may not be available in a given {@code Lock}
143+
* class. Consequently, an implementation is not required to define
144+
* exactly the same guarantees or semantics for all three forms of
145+
* lock acquisition, nor is it required to support interruption of an
146+
* ongoing lock acquisition. An implementation is required to clearly
147+
* document the semantics and guarantees provided by each of the
148+
* locking methods. It must also obey the interruption semantics as
149+
* defined in this interface, to the extent that interruption of lock
150+
* acquisition is supported: which is either totally, or only on
151+
* method entry.
152+
*
153+
* <p>As interruption generally implies cancellation, and checks for
154+
* interruption are often infrequent, an implementation can favor responding
155+
* to an interrupt over normal method return. This is true even if it can be
156+
* shown that the interrupt occurred after another action may have unblocked
157+
* the thread. An implementation should document this behavior.
158+
*
159+
* @see ReentrantLock
160+
* @see Condition
161+
* @see ReadWriteLock
162+
*
163+
* @since 1.5
164+
* @author Doug Lea
165+
*/
166+
public interface Lock {
167+
168+
/**
169+
* Acquires the lock.
170+
*
171+
* <p>If the lock is not available then the current thread becomes
172+
* disabled for thread scheduling purposes and lies dormant until the
173+
* lock has been acquired.
174+
*
175+
* <p><b>Implementation Considerations</b>
176+
*
177+
* <p>A {@code Lock} implementation may be able to detect erroneous use
178+
* of the lock, such as an invocation that would cause deadlock, and
179+
* may throw an (unchecked) exception in such circumstances. The
180+
* circumstances and the exception type must be documented by that
181+
* {@code Lock} implementation.
182+
*/
183+
void lock();
184+
185+
/**
186+
* Acquires the lock unless the current thread is
187+
* {@linkplain Thread#interrupt interrupted}.
188+
*
189+
* <p>Acquires the lock if it is available and returns immediately.
190+
*
191+
* <p>If the lock is not available then the current thread becomes
192+
* disabled for thread scheduling purposes and lies dormant until
193+
* one of two things happens:
194+
*
195+
* <ul>
196+
* <li>The lock is acquired by the current thread; or
197+
* <li>Some other thread {@linkplain Thread#interrupt interrupts} the
198+
* current thread, and interruption of lock acquisition is supported.
199+
* </ul>
200+
*
201+
* <p>If the current thread:
202+
* <ul>
203+
* <li>has its interrupted status set on entry to this method; or
204+
* <li>is {@linkplain Thread#interrupt interrupted} while acquiring the
205+
* lock, and interruption of lock acquisition is supported,
206+
* </ul>
207+
* then {@link InterruptedException} is thrown and the current thread's
208+
* interrupted status is cleared.
209+
*
210+
* <p><b>Implementation Considerations</b>
211+
*
212+
* <p>The ability to interrupt a lock acquisition in some
213+
* implementations may not be possible, and if possible may be an
214+
* expensive operation. The programmer should be aware that this
215+
* may be the case. An implementation should document when this is
216+
* the case.
217+
*
218+
* <p>An implementation can favor responding to an interrupt over
219+
* normal method return.
220+
*
221+
* <p>A {@code Lock} implementation may be able to detect
222+
* erroneous use of the lock, such as an invocation that would
223+
* cause deadlock, and may throw an (unchecked) exception in such
224+
* circumstances. The circumstances and the exception type must
225+
* be documented by that {@code Lock} implementation.
226+
*
227+
* @throws InterruptedException if the current thread is
228+
* interrupted while acquiring the lock (and interruption
229+
* of lock acquisition is supported).
230+
*/
231+
void lockInterruptibly() throws InterruptedException;
232+
233+
/**
234+
* Acquires the lock only if it is free at the time of invocation.
235+
*
236+
* <p>Acquires the lock if it is available and returns immediately
237+
* with the value {@code true}.
238+
* If the lock is not available then this method will return
239+
* immediately with the value {@code false}.
240+
*
241+
* <p>A typical usage idiom for this method would be:
242+
* <pre>
243+
* Lock lock = ...;
244+
* if (lock.tryLock()) {
245+
* try {
246+
* // manipulate protected state
247+
* } finally {
248+
* lock.unlock();
249+
* }
250+
* } else {
251+
* // perform alternative actions
252+
* }
253+
* </pre>
254+
* This usage ensures that the lock is unlocked if it was acquired, and
255+
* doesn't try to unlock if the lock was not acquired.
256+
*
257+
* @return {@code true} if the lock was acquired and
258+
* {@code false} otherwise
259+
*/
260+
boolean tryLock();
261+
262+
/**
263+
* Acquires the lock if it is free within the given waiting time and the
264+
* current thread has not been {@linkplain Thread#interrupt interrupted}.
265+
*
266+
* <p>If the lock is available this method returns immediately
267+
* with the value {@code true}.
268+
* If the lock is not available then
269+
* the current thread becomes disabled for thread scheduling
270+
* purposes and lies dormant until one of three things happens:
271+
* <ul>
272+
* <li>The lock is acquired by the current thread; or
273+
* <li>Some other thread {@linkplain Thread#interrupt interrupts} the
274+
* current thread, and interruption of lock acquisition is supported; or
275+
* <li>The specified waiting time elapses
276+
* </ul>
277+
*
278+
* <p>If the lock is acquired then the value {@code true} is returned.
279+
*
280+
* <p>If the current thread:
281+
* <ul>
282+
* <li>has its interrupted status set on entry to this method; or
283+
* <li>is {@linkplain Thread#interrupt interrupted} while acquiring
284+
* the lock, and interruption of lock acquisition is supported,
285+
* </ul>
286+
* then {@link InterruptedException} is thrown and the current thread's
287+
* interrupted status is cleared.
288+
*
289+
* <p>If the specified waiting time elapses then the value {@code false}
290+
* is returned.
291+
* If the time is
292+
* less than or equal to zero, the method will not wait at all.
293+
*
294+
* <p><b>Implementation Considerations</b>
295+
*
296+
* <p>The ability to interrupt a lock acquisition in some implementations
297+
* may not be possible, and if possible may
298+
* be an expensive operation.
299+
* The programmer should be aware that this may be the case. An
300+
* implementation should document when this is the case.
301+
*
302+
* <p>An implementation can favor responding to an interrupt over normal
303+
* method return, or reporting a timeout.
304+
*
305+
* <p>A {@code Lock} implementation may be able to detect
306+
* erroneous use of the lock, such as an invocation that would cause
307+
* deadlock, and may throw an (unchecked) exception in such circumstances.
308+
* The circumstances and the exception type must be documented by that
309+
* {@code Lock} implementation.
310+
*
311+
* @param time the maximum time to wait for the lock
312+
* @param unit the time unit of the {@code time} argument
313+
* @return {@code true} if the lock was acquired and {@code false}
314+
* if the waiting time elapsed before the lock was acquired
315+
*
316+
* @throws InterruptedException if the current thread is interrupted
317+
* while acquiring the lock (and interruption of lock
318+
* acquisition is supported)
319+
*/
320+
boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
321+
322+
/**
323+
* Releases the lock.
324+
*
325+
* <p><b>Implementation Considerations</b>
326+
*
327+
* <p>A {@code Lock} implementation will usually impose
328+
* restrictions on which thread can release a lock (typically only the
329+
* holder of the lock can release it) and may throw
330+
* an (unchecked) exception if the restriction is violated.
331+
* Any restrictions and the exception
332+
* type must be documented by that {@code Lock} implementation.
333+
*/
334+
void unlock();
335+
336+
/**
337+
* Returns a new {@link Condition} instance that is bound to this
338+
* {@code Lock} instance.
339+
*
340+
* <p>Before waiting on the condition the lock must be held by the
341+
* current thread.
342+
* A call to {@link Condition#await()} will atomically release the lock
343+
* before waiting and re-acquire the lock before the wait returns.
344+
*
345+
* <p><b>Implementation Considerations</b>
346+
*
347+
* <p>The exact operation of the {@link Condition} instance depends on
348+
* the {@code Lock} implementation and must be documented by that
349+
* implementation.
350+
*
351+
* @return A new {@link Condition} instance for this {@code Lock} instance
352+
* @throws UnsupportedOperationException if this {@code Lock}
353+
* implementation does not support conditions
354+
*/
355+
Condition newCondition();
356+
}

0 commit comments

Comments
 (0)