History

My first initial commit with all of mine experimental changes.

Dmitry Kabak (userdima committed 13 years ago

Commit d37b88d1 parent 3f5b46618352 files · +2598093 −-8690Browse files

Showing the changes to java/pkg/java/util/concurrent/atomic/package-info.java (1 of 18352 files). Show all

Unified · Split

java/pkg/java/util/concurrent/atomic/package-info.java+199−0
@@ -0,0 +1,199 @@
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/publicdomain/zero/1.0/
34+ */
35+
36+/**
37+ * A small toolkit of classes that support lock-free thread-safe
38+ * programming on single variables. In essence, the classes in this
39+ * package extend the notion of {@code volatile} values, fields, and
40+ * array elements to those that also provide an atomic conditional update
41+ * operation of the form:
42+ *
43+ * <pre>
44+ * boolean compareAndSet(expectedValue, updateValue);
45+ * </pre>
46+ *
47+ * <p>This method (which varies in argument types across different
48+ * classes) atomically sets a variable to the {@code updateValue} if it
49+ * currently holds the {@code expectedValue}, reporting {@code true} on
50+ * success. The classes in this package also contain methods to get and
51+ * unconditionally set values, as well as a weaker conditional atomic
52+ * update operation {@code weakCompareAndSet} described below.
53+ *
54+ * <p>The specifications of these methods enable implementations to
55+ * employ efficient machine-level atomic instructions that are available
56+ * on contemporary processors. However on some platforms, support may
57+ * entail some form of internal locking. Thus the methods are not
58+ * strictly guaranteed to be non-blocking --
59+ * a thread may block transiently before performing the operation.
60+ *
61+ * <p>Instances of classes
62+ * {@link java.util.concurrent.atomic.AtomicBoolean},
63+ * {@link java.util.concurrent.atomic.AtomicInteger},
64+ * {@link java.util.concurrent.atomic.AtomicLong}, and
65+ * {@link java.util.concurrent.atomic.AtomicReference}
66+ * each provide access and updates to a single variable of the
67+ * corresponding type. Each class also provides appropriate utility
68+ * methods for that type. For example, classes {@code AtomicLong} and
69+ * {@code AtomicInteger} provide atomic increment methods. One
70+ * application is to generate sequence numbers, as in:
71+ *
72+ * <pre>
73+ * class Sequencer {
74+ * private final AtomicLong sequenceNumber
75+ * = new AtomicLong(0);
76+ * public long next() {
77+ * return sequenceNumber.getAndIncrement();
78+ * }
79+ * }
80+ * </pre>
81+ *
82+ * <p>The memory effects for accesses and updates of atomics generally
83+ * follow the rules for volatiles, as stated in section 17.4 of
84+ * <cite>The Java&trade; Language Specification</cite>.
85+ *
86+ * <ul>
87+ *
88+ * <li> {@code get} has the memory effects of reading a
89+ * {@code volatile} variable.
90+ *
91+ * <li> {@code set} has the memory effects of writing (assigning) a
92+ * {@code volatile} variable.
93+ *
94+ * <li> {@code lazySet} has the memory effects of writing (assigning)
95+ * a {@code volatile} variable except that it permits reorderings with
96+ * subsequent (but not previous) memory actions that do not themselves
97+ * impose reordering constraints with ordinary non-{@code volatile}
98+ * writes. Among other usage contexts, {@code lazySet} may apply when
99+ * nulling out, for the sake of garbage collection, a reference that is
100+ * never accessed again.
101+ *
102+ * <li>{@code weakCompareAndSet} atomically reads and conditionally
103+ * writes a variable but does <em>not</em>
104+ * create any happens-before orderings, so provides no guarantees
105+ * with respect to previous or subsequent reads and writes of any
106+ * variables other than the target of the {@code weakCompareAndSet}.
107+ *
108+ * <li> {@code compareAndSet}
109+ * and all other read-and-update operations such as {@code getAndIncrement}
110+ * have the memory effects of both reading and
111+ * writing {@code volatile} variables.
112+ * </ul>
113+ *
114+ * <p>In addition to classes representing single values, this package
115+ * contains <em>Updater</em> classes that can be used to obtain
116+ * {@code compareAndSet} operations on any selected {@code volatile}
117+ * field of any selected class.
118+ *
119+ * {@link java.util.concurrent.atomic.AtomicReferenceFieldUpdater},
120+ * {@link java.util.concurrent.atomic.AtomicIntegerFieldUpdater}, and
121+ * {@link java.util.concurrent.atomic.AtomicLongFieldUpdater} are
122+ * reflection-based utilities that provide access to the associated
123+ * field types. These are mainly of use in atomic data structures in
124+ * which several {@code volatile} fields of the same node (for
125+ * example, the links of a tree node) are independently subject to
126+ * atomic updates. These classes enable greater flexibility in how
127+ * and when to use atomic updates, at the expense of more awkward
128+ * reflection-based setup, less convenient usage, and weaker
129+ * guarantees.
130+ *
131+ * <p>The
132+ * {@link java.util.concurrent.atomic.AtomicIntegerArray},
133+ * {@link java.util.concurrent.atomic.AtomicLongArray}, and
134+ * {@link java.util.concurrent.atomic.AtomicReferenceArray} classes
135+ * further extend atomic operation support to arrays of these types.
136+ * These classes are also notable in providing {@code volatile} access
137+ * semantics for their array elements, which is not supported for
138+ * ordinary arrays.
139+ *
140+ * <a name="Spurious">
141+ * <p>The atomic classes also support method {@code weakCompareAndSet},
142+ * which has limited applicability. On some platforms, the weak version
143+ * may be more efficient than {@code compareAndSet} in the normal case,
144+ * but differs in that any given invocation of the
145+ * {@code weakCompareAndSet} method may return {@code false}
146+ * <em>spuriously</em> (that is, for no apparent reason)</a>. A
147+ * {@code false} return means only that the operation may be retried if
148+ * desired, relying on the guarantee that repeated invocation when the
149+ * variable holds {@code expectedValue} and no other thread is also
150+ * attempting to set the variable will eventually succeed. (Such
151+ * spurious failures may for example be due to memory contention effects
152+ * that are unrelated to whether the expected and current values are
153+ * equal.) Additionally {@code weakCompareAndSet} does not provide
154+ * ordering guarantees that are usually needed for synchronization
155+ * control. However, the method may be useful for updating counters and
156+ * statistics when such updates are unrelated to the other
157+ * happens-before orderings of a program. When a thread sees an update
158+ * to an atomic variable caused by a {@code weakCompareAndSet}, it does
159+ * not necessarily see updates to any <em>other</em> variables that
160+ * occurred before the {@code weakCompareAndSet}. This may be
161+ * acceptable when, for example, updating performance statistics, but
162+ * rarely otherwise.
163+ *
164+ * <p>The {@link java.util.concurrent.atomic.AtomicMarkableReference}
165+ * class associates a single boolean with a reference. For example, this
166+ * bit might be used inside a data structure to mean that the object
167+ * being referenced has logically been deleted.
168+ *
169+ * The {@link java.util.concurrent.atomic.AtomicStampedReference}
170+ * class associates an integer value with a reference. This may be
171+ * used for example, to represent version numbers corresponding to
172+ * series of updates.
173+ *
174+ * <p>Atomic classes are designed primarily as building blocks for
175+ * implementing non-blocking data structures and related infrastructure
176+ * classes. The {@code compareAndSet} method is not a general
177+ * replacement for locking. It applies only when critical updates for an
178+ * object are confined to a <em>single</em> variable.
179+ *
180+ * <p>Atomic classes are not general purpose replacements for
181+ * {@code java.lang.Integer} and related classes. They do <em>not</em>
182+ * define methods such as {@code hashCode} and
183+ * {@code compareTo}. (Because atomic variables are expected to be
184+ * mutated, they are poor choices for hash table keys.) Additionally,
185+ * classes are provided only for those types that are commonly useful in
186+ * intended applications. For example, there is no atomic class for
187+ * representing {@code byte}. In those infrequent cases where you would
188+ * like to do so, you can use an {@code AtomicInteger} to hold
189+ * {@code byte} values, and cast appropriately.
190+ *
191+ * You can also hold floats using
192+ * {@link java.lang.Float#floatToIntBits} and
193+ * {@link java.lang.Float#intBitsToFloat} conversions, and doubles using
194+ * {@link java.lang.Double#doubleToLongBits} and
195+ * {@link java.lang.Double#longBitsToDouble} conversions.
196+ *
197+ * @since 1.5
198+ */
199+package java.util.concurrent.atomic;