ViewVC Help
View File | Revision Log | Show Annotations | Download File | Root Listing
root/jsr166/jsr166/intro.html
Revision: 1.1
Committed: Sun Sep 29 19:20:58 2002 UTC (21 years, 7 months ago) by jsr166
Content type: text/html
Branch: MAIN
Branch point for: jsr166
Log Message: 
Initial revision

File Contents

# User Rev Content
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>