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

Annotation of /jsr166/intro.html

Parent Directory Parent Directory | Revision Log Revision Log


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

Doug Lea
ViewVC Help
Powered by ViewVC 1.0.8