ViewVC Help
View File | Revision Log | Show Annotations | Download File | Root Listing
root/jsr166/jsr166/src/main/intro.html
Revision: 1.6
Committed: Thu Jun 26 10:46:55 2003 UTC (20 years, 10 months ago) by dl
Content type: text/html
Branch: MAIN
Changes since 1.5: +25 -7 lines
Log Message: 
new Concurrent vs synchronized parag

File Contents

# Content
1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
2 <html>
3 <head>
4 <title>JSR 166 Snapshot Introduction.</title>
5 </head>
6
7 <body bgcolor="#ffffee" vlink="#0000aa" link="#cc0000">
8 <h1>JSR 166 Snapshot Introduction.</h1>
9
10 by <a href="http://gee.cs.oswego.edu/dl">Doug Lea</a>
11 <p>
12
13 To join a mailing list discussing this JSR, go to:
14 <A HREF="http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest"> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest</A> .
15
16 <p>
17 <em>
18 Disclaimer - This prototype is experimental code developed as part of
19 JCP JSR166 and made available to the developer community for use
20 as-is. It is not a supported product. Use it at your own risk. The
21 specification, language and implementation are subject to change as a
22 result of your feedback. Because these features have not yet been
23 approved for addition to the Java language, there is no schedule for
24 their inclusion in a product.
25 </em>
26
27 <p> Package java.util.concurrent contains utility classes commonly
28 useful in concurrent programming. Like package java.util, it includes
29 a few small standardized extensible frameworks, as well as some
30 classes that provide useful functionality and are otherwise tedious or
31 difficult to implement. JSR166 also includes a few changes and
32 additions in packages outside of java.util.concurrent: java.lang, to
33 address uncaught exceptions, and java.util to better integrate with
34 collections. Since the target release is JDK1.5, many APIs use
35 generics to parameterize on types. Here are brief descriptions of the
36 main components.
37
38 <h2>Executors</h2>
39
40 {@link java.util.concurrent.Executor} is a simple standardized
41 interface for defining custom thread-like subsystems, including thread
42 pools, asynch-IO, and lightweight task frameworks. Depending on which
43 concrete Executor class is being used, tasks may execute in a newly
44 created thread, an existing task-execution thread, or the thread
45 calling <tt>execute()</tt>, and may execute sequentially or
46 concurrently. Executors also standardize ways of calling threads that
47 compute functions returning results, via a {@link
48 java.util.concurrent.Future}. This is supported in part by defining
49 interface {@link java.util.concurrent.Callable}, the argument/result
50 analog of Runnable.
51
52 <p> {@link java.util.concurrent.ExecutorService} provides a more
53 complete framework for executing Runnables. An ExecutorService
54 manages queueing and scheduling of tasks, and allows controlled
55 shutdown. The two primary implementations of ExecutorService are
56 {@link java.util.concurrent.ThreadPoolExecutor}, a highly tunable and
57 flexible thread pool and {@link
58 java.util.concurrent.ScheduledExecutor}, which adds support for
59 delayed and periodic task execution. These, and other Executors can
60 be used in conjunction with a {@link java.util.concurrent.FutureTask}
61 to asynchronously
62 start a potentially long-running computation and query the FutureTask
63 to determine if its execution has completed, or cancel it.
64
65 <p> The {@link java.util.concurrent.Executors} class provides factory
66 methods for the most common kinds and styles of Executors, as well as
67 a few utilities methods for using them.
68
69 <h2>Queues</h2>
70
71 A basic (nonblocking) {@link java.util.Queue} interface extending
72 java.util.Collection is introduced into java.util. Existing class
73 java.util.LinkedList is adapted to support Queue, and a new
74 non-thread-safe {@link java.util.PriorityQueue} is added. The
75 java.util.concurrent {@link
76 java.util.concurrent.ConcurrentLinkedQueue} class supplies an
77 efficient sclable thread-safe non-blocking FIFO queue, and {@link
78 java.util.concurrent.ConcurrentLinkedStack} provides a similar
79 non-blocking LIFO stack.
80
81 <p> Five implementations in java.util.concurrent support the extended
82 {@link java.util.concurrent.BlockingQueue} interface, that defines
83 blocking versions of put and take: {@link
84 java.util.concurrent.LinkedBlockingQueue}, {@link
85 java.util.concurrent.ArrayBlockingQueue}, {@link
86 java.util.concurrent.SynchronousQueue}, {@link
87 java.util.concurrent.PriorityBlockingQueue}, and
88 {@link java.util.concurrent.DelayQueue}.
89
90
91 <h2>Locks</h2>
92
93 The {@link java.util.concurrent.Lock} interface supports locking
94 disciplines that differ in semantics (reentrant, fair, etc), and that
95 can be used in non-block-structured contexts including hand-over-hand
96 and lock reordering algorithms. This flexibility comes at the price of
97 more awkward syntax. Implementations include {@link
98 java.util.concurrent.ReentrantLock} and {@link
99 java.util.concurrent.FairReentrantLock}.
100
101 <p> The {@link java.util.concurrent.Locks} class additionally supports
102 some common trylock-designs using builtin locks.
103
104 <p> The {@link java.util.concurrent.ReadWriteLock} interface similarly
105 defines locks that may be shared among readers but are exclusive to
106 writers. Only a single implementation, {@link
107 java.util.concurrent.ReentrantReadWriteLock}, is provided, since it
108 covers all standard usage contexts. But programmers may create their
109 own implementations to cover nonstandard requirements.
110
111 <h2>Conditions</h2>
112
113 The {@link java.util.concurrent.Condition} interface describes the
114 kinds of condition variables associated with monitors in other
115 concurrent languages, as well as pthreads-style condvars. Their
116 support reduces the need for tricky and/or inefficient solutions to
117 many classic concurrent problems. To avoid compatibility problems,
118 the names of Condition methods are different than Object versions.
119
120 <h2>Atomics</h2>
121
122 The atomic subpackage includes a small library of classes, including
123 AtomicInteger, AtomicLong, and AtomicReference that support
124 compareAndSet (CAS) and related atomic operations.
125
126 <h2>Timing</h2>
127
128 The {@link java.util.concurrent.TimeUnit} class provides multiple
129 granularities (including nanoseconds) for both accessing time and
130 performing time-out based operations.
131
132 <h2>Synchronizers</h2>
133
134 Five classes aid common special-purpose synchronization idioms.
135 {@link java.util.concurrent.Semaphore} and {@link
136 java.util.concurrent.FairSemaphore} are classic concurrency tools.
137 {@link java.util.concurrent.CountDownLatch} is very simple yet very
138 common utility for blocking until a single signal, event, or condition
139 holds. A {@link java.util.concurrent.CyclicBarrier} is a resettable multiway
140 synchronization point common in some styles of parallel
141 programming. An {@link java.util.concurrent.Exchanger} allows two
142 threads to exchange objects at a rendezvous point.
143
144 <h2>Concurrent Collections</h2>
145
146 Besides Queues, this package supplies a few Collection implementations
147 designed for use in multithreaded contexts: {@link
148 java.util.concurrent.ConcurrentHashMap}, {@link
149 java.util.concurrent.CopyOnWriteArrayList}, and {@link
150 java.util.concurrent.CopyOnWriteArraySet}.
151
152 <p>The "Concurrent" prefix for classes is a shorthand
153 indicating several differences from similar "synchronized"
154 classes. For example <tt>java.util.Hashtable</tt> and
155 <tt>Collections.synchronizedMap(new HashMap())</tt> are
156 synchronized. But {@link
157 java.util.concurrent.ConcurrentHashMap} is "concurrent".
158 A concurrent collection (among other kinds of classes) is
159 thread-safe, but not governed by a single exclusion lock. So, in the
160 particular case of ConcurrentHashMap, it safely permits any number of
161 concurrent reads as well as a tunable number of concurrent writes.
162 There may still be a role for "synchronized" classes in some
163 multithreaded programs -- they can sometimes be useful when you need
164 to prevent ALL access to a collection via a single lock, at the
165 expense of much poor scalability. In all other cases, "concurrent"
166 versions are normally preferable.
167
168 <p> Most concurrent Collection implementations (including most Queues)
169 also differ from the usual java.util conventions in that their Iterators
170 provide <em>weakly consistent</em> rather than fast-fail traversal. A
171 weakly consistent iterator is thread-safe, but does not necessarily
172 freeze the collection while iterating, so it may (or may not) reflect
173 any updates since the iterator was created.
174
175 <h2>Uncaught Exception Handlers</h2>
176
177 The java.lang.Thread class is modified to allow per-thread
178 installation of handlers for uncaught exceptions. Ths optionally
179 disassociates these handlers from ThreadGroups, which has proven to be
180 too inflexible in many multithreaded programs. (Note that the
181 combination of features in JSR166 make ThreadGroups even less likely
182 to be used in most programs. Perhaps they will eventually be
183 deprecated.)
184
185 <p> Additionally, java.lang.ThreadLocal now supports a means to remove
186 a ThreadLocal, which is needed in some thread-pool and worker-thread
187 designs.
188
189 <hr>
190 <address><A HREF="http://gee.cs.oswego.edu/dl">Doug Lea</A></address>
191 </body>
192 </html>