ViewVC Help
View File | Revision Log | Show Annotations | Download File | Root Listing
root/jsr166/jsr166/src/main/java/util/concurrent/ReentrantReadWriteLock.java
(Generate patch)

Comparing jsr166/src/main/java/util/concurrent/ReentrantReadWriteLock.java (file contents):
Revision 1.2 by dl, Tue May 27 18:14:40 2003 UTC vs.
Revision 1.3 by dl, Sat Jun 7 18:20:21 2003 UTC

# Line 7 | Line 7
7   package java.util.concurrent;
8  
9   /**
10 < * This class provides the most commonly useful implementation of a
11 < * {@link ReadWriteLock}.
12 < *
10 > * An implementation of {@link ReadWriteLock} supporting similar
11 > * semantics to {@link ReentrantLock}.
12   * <p>This class has the following properties:
13   * <ul>
14   * <li><b>Acquisition order</b>
15   * <p> This class does not impose a reader or writer preference
16   * ordering for lock access. Instead, threads contend using an
17   * approximately arrival-order policy. The actual order depends on the
18 < * order in which an internal {@link ReentrantLock} is granted, but
18 > * order in which an internal {@link FairReentrantLock} is granted, but
19   * essentially when the write lock is released either the single writer
20   * at the notional head of the queue will be assigned the write lock, or
21   * the set of readers at the head of the queue will be assigned the read lock.
22   * <p>If readers are active and a writer arrives then no subsequent readers
23   * will be granted the read lock until after that writer has acquired and
24   * released the write lock.
26 – * <p><b>Note:</b> As all threads, readers and writers, must pass through an
27 – * internal lock, it is possible for the read lock <tt>tryLock</tt> methods
28 – * to return <tt>false</tt> even if the lock is logically available to the
29 – * thread.
25   *
26   * <li><b>Reentrancy</b>
27   * <p>This lock allows both readers and writers to reacquire read or
# Line 42 | Line 37 | package java.util.concurrent;
37   * <li><b>Lock downgrading</b>
38   * <p>Reentrancy also allows downgrading from the write lock to a read lock,
39   * by acquiring the write lock, then the read lock and then releasing the
40 < * write lock. Note that upgrading, from a read lock to the write lock, is
40 > * write lock. However, upgrading from a read lock to the write lock, is
41   * <b>not</b> possible.
42   *
43   * <li><b>Interruption of lock aquisition</b>
# Line 62 | Line 57 | package java.util.concurrent;
57   * <p>While not exposing a means to query the owner, the write lock does
58   * internally define an owner and so the write lock can only be released by
59   * the thread that acquired it.
60 < * <p>In contrast, the read lock has no concept of ownership, simply a count
61 < * of the number of active readers. Consequently, while not a particularly
60 > * <p>In contrast, the read lock has no concept of ownership.
61 > * Consequently, while not a particularly
62   * good practice, it is possible to acquire a read lock in one thread, and
63   * release it in another. This can occasionally be useful.
64   *

Diff Legend

– Removed lines
+ Added lines
< Changed lines
> Changed lines