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

Annotation of /jsr166/src/main/intro.html

Parent Directory Parent Directory | Revision Log Revision Log


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

1 : tim 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 :     <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 : dl 1.2 a new non-thread-safe java.util.PriorityQueue will be added.
79 : tim 1.1
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 : dl 1.2
101 :     <p> Executors provide a framework for executing Runnables. The
102 :     Executor manages queueing and scheduling of tasks, and creation and
103 :     teardown of threads. Depending on which concrete Executor class is
104 :     being used, tasks may execute in a newly created thread, an existing
105 :     task-execution thread, or the thread calling execute(), and may
106 :     execute sequentially or concurrently.
107 :    
108 :     <p> Several concrete implementations of Executor are included in
109 :     java.util.concurrent, including ThreadPoolExecutor, a flexible thread
110 :     pool and ScheduledExecutor, which adds support for delayed and
111 :     periodic task execution. Executor can be used in conjunction with
112 :     FutureTask (which implements Runnable) to asynchronously start a
113 :     potentially long-running computation and query the FutureTask to
114 :     determine if its execution has completed.
115 :    
116 :     <p> The <tt>Executors</tt> class provides factory methods for all
117 :     of the types of executors provided in
118 :     <tt>java.util.concurrent</tt>.
119 : tim 1.1
120 :    
121 :     <h2>Locks</h2>
122 :    
123 :     The Lock interface supports locking disciplines that differ in
124 : dl 1.2 semantics (reentrant, fair, etc), and that can be used in
125 : tim 1.1 non-block-structured contexts including hand-over-hand and lock
126 :     reordering algorithms. This flexibility comes at the price of more
127 : dl 1.2 awkward syntax. Implementations include ReentrantLock and
128 :     FairReentrantLock.
129 : tim 1.1
130 :     <p>
131 :     The Locks class additionally supports trylock-designs using builtin
132 :     locks without needing to use Lock classes. This requires adding new
133 :     capabilities to builtin locks inside JVMs.
134 :    
135 :     <p>
136 :     A ReadWriteLock interface similarly defines locks that may be shared
137 :     among readers but are exclusive to writers. For this release, only a
138 :     single implementation, ReentrantReadWriteLock, is planned, since it
139 :     covers all standard usage contexts. But programmers may create their
140 :     own implementations to cover nonstandard requirements.
141 :    
142 :     <h2>Conditions</h2>
143 :    
144 :     A Condition class provides the kinds of condition variables associated
145 :     with monitors in other cocurrent languages, as well as pthreads
146 :     condvars. Their support reduces the need for tricky and/or
147 :     inefficient solutions to many classic concurrent problems. Conditions
148 :     also address the annoying problem that Object.wait(msecs) does not
149 :     return an indication of whether the wait timed out. This leads to
150 :     error-prone code. Since this method is in class Object, the problem is
151 :     basically unfixable.
152 :     <p>
153 :     To avoid compatibility problems, the names of Condition methods need
154 :     to be different than Object versions. The downside of this is that
155 :     people can make the mistake of calling cond.notify instead of
156 :     cond.signal. However, they will get IllegalMonitorState exceptions if
157 :     they do, so they can detect the error if they ever run the code.
158 : dl 1.2
159 : tim 1.1
160 :     <h2>Atomic variables</h2>
161 :    
162 : dl 1.2 The atomic subpackage includes a small library of classes, including
163 :     AtomicInteger, AtomicLong, and AtomicReference that support variables
164 :     performinf compareAndSet (CAS) and related atomic operations.
165 : tim 1.1
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 : dl 1.2 introducing class TimeUnit, which provides multiple granularities for
172 : tim 1.1 both accessing time and performing time-out based operations.
173 :    
174 :    
175 :     <h2>Synchronizers</h2>
176 :    
177 :     Five classes aid common special-purpose synchronization idioms.
178 : dl 1.2 Semaphores and FairSemaphores are classic concurrency tools.
179 :     CountDownLatches are very simple yet very common objects useful for
180 :     blocking until a single signal, event, or condition holds.
181 :     CyclicBarriers are resettable multiway synchronization points very
182 :     common in some styles of parallel programming. Exchangers allow two
183 :     threads to exchange objects at a rendezvous point.
184 : tim 1.1
185 :    
186 :     <h2>Concurrent Collections</h2>
187 :    
188 :     JSR 166 will supply a few Collection implementations designed for use
189 : dl 1.2 in multithreaded contexts: ConcurrentHashMap, CopyOnWriteArrayList,
190 : tim 1.1 and CopyOnWriteArraySet.
191 :    
192 :     <h2>Uncaught Exception Handlers</h2>
193 :    
194 :     The java.lang.Thread class will be modified to allow per-thread
195 :     installation of handlers for uncaught exceptions. Ths optionally
196 :     disassociates these handlers from ThreadGroups, which has proven to be
197 :     too inflexible in many multithreaded programs. (Note that the combination
198 :     of features in JSR 166 make ThreadGroups even less likely to
199 :     be used in most programs. Perhaps they will eventually be deprecated.)
200 : dl 1.2
201 :     <p> Additionally, ThreadLocals will now support a means to remove a
202 :     ThreadLocal, which is needed in some thread-pool and worker-thread
203 :     designs.
204 : tim 1.1
205 :     <hr>
206 :     <address><A HREF="http://gee.cs.oswego.edu/dl">Doug Lea</A></address>
207 :     </body>
208 :     </html>

Doug Lea
ViewVC Help
Powered by ViewVC 1.0.8