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

Annotation of /jsr166/intro.html

Parent Directory Parent Directory | Revision Log Revision Log


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

Doug Lea
ViewVC Help
Powered by ViewVC 1.0.8