[cvs] / jsr166 / intro.html Repository:
ViewVC logotype

Annotation of /jsr166/intro.html

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.2 - (view) (download) (as text)

1 : jsr166 1.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 : dl 1.2 <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 : jsr166 1.1 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 timing
37 :     and uncaught exceptions, and java.util to better integrate queues, and
38 :     to make Timers conform to new frameworks. 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> Barriers
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>
81 :     Four implementations in java.util.concurrent support the extended
82 :     BlockingQueue interface, that defines blocking versions of put and
83 :     take: LinkedBlockingQueue, ArrayBlockingQueue, SynchronousQueue, and
84 :     PriorityBlockingQueue. Additionally, java.util.concurrent.LinkedQueue
85 :     supplies an efficient thread-safe non-blocking queue.
86 :     <p>
87 :     Since the target release is JDK1.5, and generics are slated to be in
88 :     1.5, Queues should be parametrized on element type. (Also some others
89 :     below.) We are ignoring this for now.
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 java.lang.Callable, the
99 :     argument/result analog of Runnable.
100 :    
101 :     <p> While the Executor framework is intended to be extensible (so
102 :     includes for example, AbstractExecutor that simplifies construction of
103 :     new implementations), the most commonly used Executor will be
104 :     ThreadExecutor, which can be configured to act as all sorts of thread
105 :     pools, background threads, etc. The class is designed to be general
106 :     enough to suffice for the vast majority of usages, even sophisticated
107 :     ones, yet also includes methods and functionality that simplify
108 :     routine usage.
109 :    
110 :     <p>
111 :     A few methods will also be added to the java.util.Timer to support
112 :     Futures, and address other requests for enhancement.
113 :    
114 :     <h2>Locks</h2>
115 :    
116 :     The Lock interface supports locking disciplines that differ in
117 :     semantics (reentrant, semaphore-based, etc), and that can be used in
118 :     non-block-structured contexts including hand-over-hand and lock
119 :     reordering algorithms. This flexibility comes at the price of more
120 :     awkward syntax. Implementations include Semaphore, ReentrantMutex
121 :     FIFOSemaphore, and CountDownLatch.
122 :    
123 :     <p>
124 :     The Locks class additionally supports trylock-designs using builtin
125 :     locks without needing to use Lock classes. This requires adding new
126 :     capabilities to builtin locks inside JVMs.
127 :    
128 :     <p>
129 :     A ReadWriteLock interface similarly defines locks that may be shared
130 :     among readers but are exclusive to writers. For this release, only a
131 :     single implementation, ReentrantReadWriteLock, is planned, since it
132 :     covers all standard usage contexts. But programmers may create their
133 :     own implementations to cover nonstandard requirements.
134 :    
135 :     <h2>Conditions</h2>
136 :    
137 :     A Condition class provides the kinds of condition variables associated
138 :     with monitors in other cocurrent languages, as well as pthreads
139 :     condvars. Their support reduces the need for tricky and/or
140 :     inefficient solutions to many classic concurrent problems. Conditions
141 :     also address the annoying problem that Object.wait(msecs) does not
142 :     return an indication of whether the wait timed out. This leads to
143 :     error-prone code. Since this method is in class Object, the problem is
144 :     basically unfixable.
145 :     <p>
146 :     To avoid compatibility problems, the names of Condition methods need
147 :     to be different than Object versions. The downside of this is that
148 :     people can make the mistake of calling cond.notify instead of
149 :     cond.signal. However, they will get IllegalMonitorState exceptions if
150 :     they do, so they can detect the error if they ever run the code.
151 :     <p>
152 :     The implementation requires VM magic to atomically suspend and release
153 :     lock. But it is unlikely to be very challenging for JVM providers,
154 :     since most layer Java monitors on top of posix condvars or similar
155 :     low-level functionality anyway.
156 :    
157 :     <h2>Atomic variables</h2>
158 :    
159 :     Classes AtomicInteger, AtomicLong, AtomicDouble, AtomicFloat, and
160 :     AtomicReference provide simple scalar variables supporting
161 :     compareAndSwap (CAS) and related atomic operations. These are
162 :     desparately needed by those performing low-level concurrent system
163 :     programming, but much less commonly useful in higher-level frameworks.
164 :    
165 :    
166 :     <h2>Timing</h2>
167 :    
168 :     Java has always supported sub-millisecond versions of several native
169 :     time-out-based methods (such as Object.wait), but not methods to
170 :     actually perform timing in finer-grained units. We address this by
171 :     introducing java.lang.Clock, which provides multiple granularities for
172 :     both accessing time and performing time-out based operations.
173 :    
174 :    
175 :     <h2>Barriers</h2>
176 :    
177 :     Barriers (multiway synchronization points) are very common in some
178 :     styles of parallel programming, yet tricky to get right. The two most
179 :     useful flavors (CyclicBarriers and Exchangers) don't have much of an
180 :     interface in common, and only have one standard implementation each,
181 :     so these are simply defined as public classes rather than interfaces
182 :     and implementations.
183 :    
184 :    
185 :     <h2>Concurrent Collections</h2>
186 :    
187 :     There are no new interfaces, but JSR 166 will supply a few Collection
188 :     implementations designed for use in multithreaded contexts:
189 :     ConcurrentHashTable, CopyOnWriteArrayList, and CopyOnWriteArraySet.
190 :    
191 :     <h2>Uncaught Exception Handlers</h2>
192 :    
193 :     The java.lang.Thread class will be modified to allow per-thread
194 :     installation of handlers for uncaught exceptions. Ths optionally
195 :     disassociates these handlers from ThreadGroups, which has proven to be
196 :     too inflexible in many multithreaded programs. (Note that the combination
197 :     of features in JSR 166 make ThreadGroups even less likely to
198 :     be used in most programs. Perhaps they will eventually be deprecated.)
199 :     <p>
200 :     Additionally, Threads and ThreadLocals will now support a means to
201 :     clear and remove ThreadLocals, which is needed in some thread-pool and
202 :     worker-thread designs.
203 :    
204 :     <hr>
205 :     <address><A HREF="http://gee.cs.oswego.edu/dl">Doug Lea</A></address>
206 :     </body>
207 :     </html>

Doug Lea
ViewVC Help
Powered by ViewVC 1.0.8