ViewVC logotype

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

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1.2 - (show annotations)
Wed Jun 4 11:33:01 2003 UTC (18 years ago) by dl
Branch: MAIN
Changes since 1.1: +39 -33 lines
File MIME type: text/html
Minor documentation updates

2 <html>
3 <head>
4 <title>JSR 166 Snapshot Introduction.</title>
5 </head>
7 <body bgcolor="#ffffee" vlink="#0000aa" link="#cc0000">
8 <h1>JSR 166 Snapshot Introduction.</h1>
10 by <a href="http://gee.cs.oswego.edu/dl">Doug Lea</a>
11 <p>
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> .
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>
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:
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>
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.
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>
72 <h2>Queues</h2>
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.PriorityQueue will be added.
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.
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.)
92 <h2>Executors</h2>
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.
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.
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.
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>.
121 <h2>Locks</h2>
123 The Lock interface supports locking disciplines that differ in
124 semantics (reentrant, fair, etc), and that can be used in
125 non-block-structured contexts including hand-over-hand and lock
126 reordering algorithms. This flexibility comes at the price of more
127 awkward syntax. Implementations include ReentrantLock and
128 FairReentrantLock.
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.
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.
142 <h2>Conditions</h2>
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.
160 <h2>Atomic variables</h2>
162 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.
166 <h2>Timing</h2>
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 class TimeUnit, which provides multiple granularities for
172 both accessing time and performing time-out based operations.
175 <h2>Synchronizers</h2>
177 Five classes aid common special-purpose synchronization idioms.
178 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.
186 <h2>Concurrent Collections</h2>
188 JSR 166 will supply a few Collection implementations designed for use
189 in multithreaded contexts: ConcurrentHashMap, CopyOnWriteArrayList,
190 and CopyOnWriteArraySet.
192 <h2>Uncaught Exception Handlers</h2>
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.)
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.
205 <hr>
206 <address><A HREF="http://gee.cs.oswego.edu/dl">Doug Lea</A></address>
207 </body>
208 </html>

ViewVC Help
Powered by ViewVC 1.1.27