ViewVC Help
View File | Revision Log | Show Annotations | Download File | Root Listing
root/jsr166/jsr166/intro.html
Revision: 1.5
Committed: Fri May 16 14:13:04 2003 UTC (20 years, 11 months ago) by tim
Content type: text/html
Branch: MAIN
CVS Tags: HEAD
Changes since 1.4: +0 -0 lines
State: FILE REMOVED
Log Message:
Moved intro.html to root of main source.

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 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>
28 Package java.util.concurrent contains utility classes that are
29 commonly useful in concurrent programming. Like package java.util, it
30 includes a few small standardized extensible frameworks, as well as
31 some classes that provide useful functionality and are otherwise
32 tedious or difficult to implement. In this JSR, we have been
33 conservative in selecting only those APIs and implementations that are
34 useful enough to encourage nearly all concurrent programmers to use
35 routinely. JSR 166 also includes a few changes and additions in
36 packages outside of java.util.concurrent: java.lang, to address
37 uncaught exceptions, and java.util to better integrate queues.
38 The API covers:
39
40 <ul>
41 <li> Queues
42 <li> Executors
43 <li> Locks
44 <li> Condition variables
45 <li> Atomic variables
46 <li> Timing
47 <li> Synchronizers
48 <li> Concurrent Collections
49 <li> Uncaught Exception Handlers
50 </ul>
51
52
53 The main rationale for JSR 166 is that threading primitives, such as
54 synchronized blocks, Object.wait and Object.notify, are insufficient
55 for many programming tasks. Currently, developers can use only the
56 concurrency control constructs provided in the Java language
57 itself. These are too low level for some applications, and are
58 incomplete for others. As a result, application programmers are often
59 forced to implement their own concurrency facilities, resulting in
60 enormous duplication of effort creating facilities that are
61 notoriously hard to get right and even harder to optimize. Offering a
62 standard set of concurrency utilities will ease the task of writing a
63 wide variety of multithreaded applications and generally improve the
64 quality of the applications that use them.
65
66 <p>
67 Here are brief descriptions and rationales of the main components.
68 For details see the javadocs at <a
69 href="http://gee.cs.oswego.edu/dl/concurrent/index.html">http://gee.cs.oswego.edu/dl/concurrent/index.html</a>
70
71
72 <h2>Queues</h2>
73
74 A basic (nonblocking) Queue interface that is compatatible with
75 java.util.Collections will be introduced into java.util. Also,
76 although it is at the borders of being in scope of JSR-166,
77 java.util.LinkedList will be adapted to support Queue, and
78 a new non-thread-safe java.util.HeapPriorityQueue will be added.
79
80 <p> Five implementations in java.util.concurrent support the extended
81 BlockingQueue interface, that defines blocking versions of put and
82 take: LinkedBlockingQueue, ArrayBlockingQueue, SynchronousQueue,
83 PriorityBlockingQueue, and DelayQueue. Additionally,
84 java.util.concurrent.LinkedQueue supplies an efficient thread-safe
85 non-blocking queue.
86
87 <p> Since the target release is JDK1.5, and generics are slated to be
88 in 1.5, Queues are parametrized on element type. (Also some others
89 below.)
90
91
92 <h2>Executors</h2>
93
94 Executors provide a simple standardized interface for defining custom
95 thread-like subsystems, including thread pools, asynch-IO, and
96 lightweight task frameworks. Executors also standardize ways of
97 calling threads that compute functions returning results, via
98 Futures. This is supported in part by defining interface Callable, the
99 argument/result analog of Runnable.
100
101 <p> While the Executor framework is intended to be extensible the most
102 commonly used Executor will be ThreadExecutor, which can be configured
103 to act as all sorts of thread pools, background threads, etc. The
104 class is designed to be general enough to suffice for the vast
105 majority of usages, even sophisticated ones, yet also includes methods
106 and functionality that simplify routine usage.
107
108 <h2>Locks</h2>
109
110 The Lock interface supports locking disciplines that differ in
111 semantics (reentrant, semaphore-based, etc), and that can be used in
112 non-block-structured contexts including hand-over-hand and lock
113 reordering algorithms. This flexibility comes at the price of more
114 awkward syntax. Implementations include Semaphore, ReentrantMutex
115 FIFOSemaphore, and CountDownLatch.
116
117 <p>
118 The Locks class additionally supports trylock-designs using builtin
119 locks without needing to use Lock classes. This requires adding new
120 capabilities to builtin locks inside JVMs.
121
122 <p>
123 A ReadWriteLock interface similarly defines locks that may be shared
124 among readers but are exclusive to writers. For this release, only a
125 single implementation, ReentrantReadWriteLock, is planned, since it
126 covers all standard usage contexts. But programmers may create their
127 own implementations to cover nonstandard requirements.
128
129 <h2>Conditions</h2>
130
131 A Condition class provides the kinds of condition variables associated
132 with monitors in other cocurrent languages, as well as pthreads
133 condvars. Their support reduces the need for tricky and/or
134 inefficient solutions to many classic concurrent problems. Conditions
135 also address the annoying problem that Object.wait(msecs) does not
136 return an indication of whether the wait timed out. This leads to
137 error-prone code. Since this method is in class Object, the problem is
138 basically unfixable.
139 <p>
140 To avoid compatibility problems, the names of Condition methods need
141 to be different than Object versions. The downside of this is that
142 people can make the mistake of calling cond.notify instead of
143 cond.signal. However, they will get IllegalMonitorState exceptions if
144 they do, so they can detect the error if they ever run the code.
145 <p>
146 The implementation requires VM magic to atomically suspend and release
147 lock. But it is unlikely to be very challenging for JVM providers,
148 since most layer Java monitors on top of posix condvars or similar
149 low-level functionality anyway.
150
151 <h2>Atomic variables</h2>
152
153 Classes AtomicInteger, AtomicLong, AtomicDouble, AtomicFloat, and
154 AtomicReference provide simple scalar variables supporting
155 compareAndSwap (CAS) and related atomic operations. These are
156 desparately needed by those performing low-level concurrent system
157 programming, but much less commonly useful in higher-level frameworks.
158
159
160 <h2>Timing</h2>
161
162 Java has always supported sub-millisecond versions of several native
163 time-out-based methods (such as Object.wait), but not methods to
164 actually perform timing in finer-grained units. We address this by
165 introducing class Clock, which provides multiple granularities for
166 both accessing time and performing time-out based operations.
167
168
169 <h2>Synchronizers</h2>
170
171 Five classes aid common special-purpose synchronization idioms.
172 Semaphores and FifoSemaphores are classic concurrency tools. Latches
173 are very simple yet very common objects useful for blocking until a
174 single signal, event, or condition holds. CyclicBarriers are
175 resettable multiway synchronization points very common in some styles
176 of parallel programming. Exchangers allow two threads to exchange
177 objects at a rendezvous point.
178
179
180 <h2>Concurrent Collections</h2>
181
182 JSR 166 will supply a few Collection implementations designed for use
183 in multithreaded contexts: ConcurrentHashTable, CopyOnWriteArrayList,
184 and CopyOnWriteArraySet.
185
186 <h2>Uncaught Exception Handlers</h2>
187
188 The java.lang.Thread class will be modified to allow per-thread
189 installation of handlers for uncaught exceptions. Ths optionally
190 disassociates these handlers from ThreadGroups, which has proven to be
191 too inflexible in many multithreaded programs. (Note that the combination
192 of features in JSR 166 make ThreadGroups even less likely to
193 be used in most programs. Perhaps they will eventually be deprecated.)
194 <p>
195 Additionally, ThreadLocals will now support a means to
196 remove a ThreadLocals, which is needed in some thread-pool and
197 worker-thread designs.
198
199 <hr>
200 <address><A HREF="http://gee.cs.oswego.edu/dl">Doug Lea</A></address>
201 </body>
202 </html>