Print this page
| Split |
Close |
| Expand all |
| Collapse all |
--- old/src/share/classes/java/util/concurrent/atomic/package-info.java
+++ new/src/share/classes/java/util/concurrent/atomic/package-info.java
1 1 /*
2 2 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
3 3 *
4 4 * This code is free software; you can redistribute it and/or modify it
5 5 * under the terms of the GNU General Public License version 2 only, as
6 6 * published by the Free Software Foundation. Oracle designates this
7 7 * particular file as subject to the "Classpath" exception as provided
8 8 * by Oracle in the LICENSE file that accompanied this code.
9 9 *
10 10 * This code is distributed in the hope that it will be useful, but WITHOUT
11 11 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
12 12 * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
13 13 * version 2 for more details (a copy is included in the LICENSE file that
14 14 * accompanied this code).
15 15 *
16 16 * You should have received a copy of the GNU General Public License version
17 17 * 2 along with this work; if not, write to the Free Software Foundation,
18 18 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
19 19 *
20 20 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
21 21 * or visit www.oracle.com if you need additional information or have any
22 22 * questions.
23 23 */
24 24
25 25 /*
26 26 * This file is available under and governed by the GNU General Public
27 27 * License version 2 only, as published by the Free Software Foundation.
28 28 * However, the following notice accompanied the original version of this
29 29 * file:
30 30 *
31 31 * Written by Doug Lea with assistance from members of JCP JSR-166
32 32 * Expert Group and released to the public domain, as explained at
33 33 * http://creativecommons.org/publicdomain/zero/1.0/
34 34 */
35 35
36 36 /**
37 37 * A small toolkit of classes that support lock-free thread-safe
38 38 * programming on single variables. In essence, the classes in this
39 39 * package extend the notion of {@code volatile} values, fields, and
40 40 * array elements to those that also provide an atomic conditional update
41 41 * operation of the form:
42 42 *
43 43 * <pre> {@code boolean compareAndSet(expectedValue, updateValue);}</pre>
44 44 *
45 45 * <p>This method (which varies in argument types across different
46 46 * classes) atomically sets a variable to the {@code updateValue} if it
47 47 * currently holds the {@code expectedValue}, reporting {@code true} on
48 48 * success. The classes in this package also contain methods to get and
49 49 * unconditionally set values, as well as a weaker conditional atomic
50 50 * update operation {@code weakCompareAndSet} described below.
51 51 *
52 52 * <p>The specifications of these methods enable implementations to
53 53 * employ efficient machine-level atomic instructions that are available
54 54 * on contemporary processors. However on some platforms, support may
55 55 * entail some form of internal locking. Thus the methods are not
56 56 * strictly guaranteed to be non-blocking --
57 57 * a thread may block transiently before performing the operation.
58 58 *
59 59 * <p>Instances of classes
60 60 * {@link java.util.concurrent.atomic.AtomicBoolean},
61 61 * {@link java.util.concurrent.atomic.AtomicInteger},
62 62 * {@link java.util.concurrent.atomic.AtomicLong}, and
63 63 * {@link java.util.concurrent.atomic.AtomicReference}
64 64 * each provide access and updates to a single variable of the
65 65 * corresponding type. Each class also provides appropriate utility
66 66 * methods for that type. For example, classes {@code AtomicLong} and
67 67 * {@code AtomicInteger} provide atomic increment methods. One
68 68 * application is to generate sequence numbers, as in:
69 69 *
70 70 * <pre> {@code
71 71 * class Sequencer {
72 72 * private final AtomicLong sequenceNumber
73 73 * = new AtomicLong(0);
74 74 * public long next() {
75 75 * return sequenceNumber.getAndIncrement();
76 76 * }
77 77 * }}</pre>
78 78 *
79 79 * <p>It is straightforward to define new utility functions that, like
80 80 * {@code getAndIncrement}, apply a function to a value atomically.
81 81 * For example, given some transformation
82 82 * <pre> {@code long transform(long input)}</pre>
83 83 *
84 84 * write your utility method as follows:
85 85 * <pre> {@code
86 86 * long getAndTransform(AtomicLong var) {
|
↓ open down ↓ |
86 lines elided |
↑ open up ↑ |
87 87 * long prev, next;
88 88 * do {
89 89 * prev = var.get();
90 90 * next = transform(prev);
91 91 * } while (!var.compareAndSet(prev, next));
92 92 * return prev; // return next; for transformAndGet
93 93 * }}</pre>
94 94 *
95 95 * <p>The memory effects for accesses and updates of atomics generally
96 96 * follow the rules for volatiles, as stated in
97 - * <a href="http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4">
97 + * <a href="https://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4">
98 98 * The Java Language Specification (17.4 Memory Model)</a>:
99 99 *
100 100 * <ul>
101 101 *
102 102 * <li> {@code get} has the memory effects of reading a
103 103 * {@code volatile} variable.
104 104 *
105 105 * <li> {@code set} has the memory effects of writing (assigning) a
106 106 * {@code volatile} variable.
107 107 *
108 108 * <li> {@code lazySet} has the memory effects of writing (assigning)
109 109 * a {@code volatile} variable except that it permits reorderings with
110 110 * subsequent (but not previous) memory actions that do not themselves
111 111 * impose reordering constraints with ordinary non-{@code volatile}
112 112 * writes. Among other usage contexts, {@code lazySet} may apply when
113 113 * nulling out, for the sake of garbage collection, a reference that is
114 114 * never accessed again.
115 115 *
116 116 * <li>{@code weakCompareAndSet} atomically reads and conditionally
117 117 * writes a variable but does <em>not</em>
118 118 * create any happens-before orderings, so provides no guarantees
119 119 * with respect to previous or subsequent reads and writes of any
120 120 * variables other than the target of the {@code weakCompareAndSet}.
121 121 *
122 122 * <li> {@code compareAndSet}
123 123 * and all other read-and-update operations such as {@code getAndIncrement}
124 124 * have the memory effects of both reading and
125 125 * writing {@code volatile} variables.
126 126 * </ul>
127 127 *
128 128 * <p>In addition to classes representing single values, this package
129 129 * contains <em>Updater</em> classes that can be used to obtain
130 130 * {@code compareAndSet} operations on any selected {@code volatile}
131 131 * field of any selected class.
132 132 *
133 133 * {@link java.util.concurrent.atomic.AtomicReferenceFieldUpdater},
134 134 * {@link java.util.concurrent.atomic.AtomicIntegerFieldUpdater}, and
135 135 * {@link java.util.concurrent.atomic.AtomicLongFieldUpdater} are
136 136 * reflection-based utilities that provide access to the associated
137 137 * field types. These are mainly of use in atomic data structures in
138 138 * which several {@code volatile} fields of the same node (for
139 139 * example, the links of a tree node) are independently subject to
140 140 * atomic updates. These classes enable greater flexibility in how
141 141 * and when to use atomic updates, at the expense of more awkward
142 142 * reflection-based setup, less convenient usage, and weaker
143 143 * guarantees.
144 144 *
145 145 * <p>The
146 146 * {@link java.util.concurrent.atomic.AtomicIntegerArray},
147 147 * {@link java.util.concurrent.atomic.AtomicLongArray}, and
148 148 * {@link java.util.concurrent.atomic.AtomicReferenceArray} classes
149 149 * further extend atomic operation support to arrays of these types.
150 150 * These classes are also notable in providing {@code volatile} access
151 151 * semantics for their array elements, which is not supported for
152 152 * ordinary arrays.
153 153 *
154 154 * <p id="weakCompareAndSet">The atomic classes also support method
155 155 * {@code weakCompareAndSet}, which has limited applicability. On some
156 156 * platforms, the weak version may be more efficient than {@code
157 157 * compareAndSet} in the normal case, but differs in that any given
158 158 * invocation of the {@code weakCompareAndSet} method may return {@code
159 159 * false} <em>spuriously</em> (that is, for no apparent reason). A
160 160 * {@code false} return means only that the operation may be retried if
161 161 * desired, relying on the guarantee that repeated invocation when the
162 162 * variable holds {@code expectedValue} and no other thread is also
163 163 * attempting to set the variable will eventually succeed. (Such
164 164 * spurious failures may for example be due to memory contention effects
165 165 * that are unrelated to whether the expected and current values are
166 166 * equal.) Additionally {@code weakCompareAndSet} does not provide
167 167 * ordering guarantees that are usually needed for synchronization
168 168 * control. However, the method may be useful for updating counters and
169 169 * statistics when such updates are unrelated to the other
170 170 * happens-before orderings of a program. When a thread sees an update
171 171 * to an atomic variable caused by a {@code weakCompareAndSet}, it does
172 172 * not necessarily see updates to any <em>other</em> variables that
173 173 * occurred before the {@code weakCompareAndSet}. This may be
174 174 * acceptable when, for example, updating performance statistics, but
175 175 * rarely otherwise.
176 176 *
177 177 * <p>The {@link java.util.concurrent.atomic.AtomicMarkableReference}
178 178 * class associates a single boolean with a reference. For example, this
179 179 * bit might be used inside a data structure to mean that the object
180 180 * being referenced has logically been deleted.
181 181 *
182 182 * The {@link java.util.concurrent.atomic.AtomicStampedReference}
183 183 * class associates an integer value with a reference. This may be
184 184 * used for example, to represent version numbers corresponding to
185 185 * series of updates.
186 186 *
187 187 * <p>Atomic classes are designed primarily as building blocks for
188 188 * implementing non-blocking data structures and related infrastructure
189 189 * classes. The {@code compareAndSet} method is not a general
190 190 * replacement for locking. It applies only when critical updates for an
191 191 * object are confined to a <em>single</em> variable.
192 192 *
193 193 * <p>Atomic classes are not general purpose replacements for
194 194 * {@code java.lang.Integer} and related classes. They do <em>not</em>
195 195 * define methods such as {@code equals}, {@code hashCode} and
196 196 * {@code compareTo}. (Because atomic variables are expected to be
197 197 * mutated, they are poor choices for hash table keys.) Additionally,
198 198 * classes are provided only for those types that are commonly useful in
199 199 * intended applications. For example, there is no atomic class for
200 200 * representing {@code byte}. In those infrequent cases where you would
201 201 * like to do so, you can use an {@code AtomicInteger} to hold
202 202 * {@code byte} values, and cast appropriately.
203 203 *
204 204 * You can also hold floats using
205 205 * {@link java.lang.Float#floatToRawIntBits} and
206 206 * {@link java.lang.Float#intBitsToFloat} conversions, and doubles using
207 207 * {@link java.lang.Double#doubleToRawLongBits} and
208 208 * {@link java.lang.Double#longBitsToDouble} conversions.
209 209 *
210 210 * @since 1.5
211 211 */
212 212 package java.util.concurrent.atomic;
|
↓ open down ↓ |
105 lines elided |
↑ open up ↑ |
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX