ViewVC logotype

Contents of /jsr166/intro.html

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1.1 - (show annotations)
Sun Sep 29 19:20:58 2002 UTC (18 years, 5 months ago) by jsr166
Branch: MAIN
Branch point for: jsr166
File MIME type: text/html
Initial revision

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 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:
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>
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.
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>
61 <h2>Queues</h2>
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.
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.
81 <h2>Executors</h2>
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.
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.
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.
103 <h2>Locks</h2>
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.
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.
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.
124 <h2>Conditions</h2>
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.
146 <h2>Atomic variables</h2>
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.
155 <h2>Timing</h2>
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.
164 <h2>Barriers</h2>
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.
174 <h2>Concurrent Collections</h2>
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.
180 <h2>Uncaught Exception Handlers</h2>
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.
193 <hr>
194 <address><A HREF="http://gee.cs.oswego.edu/dl">Doug Lea</A></address>
195 </body>
196 </html>

ViewVC Help
Powered by ViewVC 1.1.27