ViewVC logotype

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

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1.1 - (hide annotations)
Fri May 16 14:13:04 2003 UTC (18 years, 6 months ago) by tim
Branch: MAIN
File MIME type: text/html
Moved intro.html to root of main source.

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.HeapPriorityQueue 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> While the Executor framework is intended to be extensible the most
102     commonly used Executor will be ThreadExecutor, which can be configured
103     to act as all sorts of thread pools, background threads, etc. The
104     class is designed to be general enough to suffice for the vast
105     majority of usages, even sophisticated ones, yet also includes methods
106     and functionality that simplify routine usage.
108     <h2>Locks</h2>
110     The Lock interface supports locking disciplines that differ in
111     semantics (reentrant, semaphore-based, etc), and that can be used in
112     non-block-structured contexts including hand-over-hand and lock
113     reordering algorithms. This flexibility comes at the price of more
114     awkward syntax. Implementations include Semaphore, ReentrantMutex
115     FIFOSemaphore, and CountDownLatch.
117     <p>
118     The Locks class additionally supports trylock-designs using builtin
119     locks without needing to use Lock classes. This requires adding new
120     capabilities to builtin locks inside JVMs.
122     <p>
123     A ReadWriteLock interface similarly defines locks that may be shared
124     among readers but are exclusive to writers. For this release, only a
125     single implementation, ReentrantReadWriteLock, is planned, since it
126     covers all standard usage contexts. But programmers may create their
127     own implementations to cover nonstandard requirements.
129     <h2>Conditions</h2>
131     A Condition class provides the kinds of condition variables associated
132     with monitors in other cocurrent languages, as well as pthreads
133     condvars. Their support reduces the need for tricky and/or
134     inefficient solutions to many classic concurrent problems. Conditions
135     also address the annoying problem that Object.wait(msecs) does not
136     return an indication of whether the wait timed out. This leads to
137     error-prone code. Since this method is in class Object, the problem is
138     basically unfixable.
139     <p>
140     To avoid compatibility problems, the names of Condition methods need
141     to be different than Object versions. The downside of this is that
142     people can make the mistake of calling cond.notify instead of
143     cond.signal. However, they will get IllegalMonitorState exceptions if
144     they do, so they can detect the error if they ever run the code.
145     <p>
146     The implementation requires VM magic to atomically suspend and release
147     lock. But it is unlikely to be very challenging for JVM providers,
148     since most layer Java monitors on top of posix condvars or similar
149     low-level functionality anyway.
151     <h2>Atomic variables</h2>
153     Classes AtomicInteger, AtomicLong, AtomicDouble, AtomicFloat, and
154     AtomicReference provide simple scalar variables supporting
155     compareAndSwap (CAS) and related atomic operations. These are
156     desparately needed by those performing low-level concurrent system
157     programming, but much less commonly useful in higher-level frameworks.
160     <h2>Timing</h2>
162     Java has always supported sub-millisecond versions of several native
163     time-out-based methods (such as Object.wait), but not methods to
164     actually perform timing in finer-grained units. We address this by
165     introducing class Clock, which provides multiple granularities for
166     both accessing time and performing time-out based operations.
169     <h2>Synchronizers</h2>
171     Five classes aid common special-purpose synchronization idioms.
172     Semaphores and FifoSemaphores are classic concurrency tools. Latches
173     are very simple yet very common objects useful for blocking until a
174     single signal, event, or condition holds. CyclicBarriers are
175     resettable multiway synchronization points very common in some styles
176     of parallel programming. Exchangers allow two threads to exchange
177     objects at a rendezvous point.
180     <h2>Concurrent Collections</h2>
182     JSR 166 will supply a few Collection implementations designed for use
183     in multithreaded contexts: ConcurrentHashTable, CopyOnWriteArrayList,
184     and CopyOnWriteArraySet.
186     <h2>Uncaught Exception Handlers</h2>
188     The java.lang.Thread class will be modified to allow per-thread
189     installation of handlers for uncaught exceptions. Ths optionally
190     disassociates these handlers from ThreadGroups, which has proven to be
191     too inflexible in many multithreaded programs. (Note that the combination
192     of features in JSR 166 make ThreadGroups even less likely to
193     be used in most programs. Perhaps they will eventually be deprecated.)
194     <p>
195     Additionally, ThreadLocals will now support a means to
196     remove a ThreadLocals, which is needed in some thread-pool and
197     worker-thread designs.
199     <hr>
200     <address><A HREF="http://gee.cs.oswego.edu/dl">Doug Lea</A></address>
201     </body>
202     </html>

ViewVC Help
Powered by ViewVC 1.1.27