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

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

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.1, Fri May 16 14:13:04 2003 UTC revision 1.6, Thu Jun 26 10:46:55 2003 UTC
# Line 16  Line 16 
16  <p>  <p>
17  <em>  <em>
18   Disclaimer - This prototype is experimental code developed as part of   Disclaimer - This prototype is experimental code developed as part of
19   JSR166 and made available to the developer community for use   JCP 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   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   specification, language and implementation are subject to change as a
22   result of your feedback. Because these features have not yet been   result of your feedback. Because these features have not yet been
# Line 24  Line 24 
24   their inclusion in a product.   their inclusion in a product.
25  </em>  </em>
26    
27  <p>  <p> Package java.util.concurrent contains utility classes commonly
28  Package java.util.concurrent contains utility classes that are  useful in concurrent programming. Like package java.util, it includes
29  commonly useful in concurrent programming. Like package java.util, it  a few small standardized extensible frameworks, as well as some
30  includes a few small standardized extensible frameworks, as well as  classes that provide useful functionality and are otherwise tedious or
31  some classes that provide useful functionality and are otherwise  difficult to implement.  JSR166 also includes a few changes and
32  tedious or difficult to implement.  In this JSR, we have been  additions in packages outside of java.util.concurrent: java.lang, to
33  conservative in selecting only those APIs and implementations that are  address uncaught exceptions, and java.util to better integrate with
34  useful enough to encourage nearly all concurrent programmers to use  collections.  Since the target release is JDK1.5, many APIs use
35  routinely.  JSR 166 also includes a few changes and additions in  generics to parameterize on types.  Here are brief descriptions of the
36  packages outside of java.util.concurrent: java.lang, to address  main components.
 uncaught exceptions, and java.util to better integrate queues.  
 The API covers:  
   
   <ul>  
     <li> Queues  
     <li> Executors  
     <li> Locks  
     <li> Condition variables  
     <li> Atomic variables  
     <li> Timing  
     <li> Synchronizers  
     <li> Concurrent Collections  
     <li> Uncaught Exception Handlers  
   </ul>  
   
   
 The main rationale for JSR 166 is that threading primitives, such as  
 synchronized blocks, Object.wait and Object.notify, are insufficient  
 for many programming tasks.  Currently, developers can use only the  
 concurrency control constructs provided in the Java language  
 itself. These are too low level for some applications, and are  
 incomplete for others.  As a result, application programmers are often  
 forced to implement their own concurrency facilities, resulting in  
 enormous duplication of effort creating facilities that are  
 notoriously hard to get right and even harder to optimize.  Offering a  
 standard set of concurrency utilities will ease the task of writing a  
 wide variety of multithreaded applications and generally improve the  
 quality of the applications that use them.  
37    
38  <p>  <h2>Executors</h2>
 Here are brief descriptions and rationales of the main components.  
 For details see the javadocs at <a  
 href="http://gee.cs.oswego.edu/dl/concurrent/index.html">http://gee.cs.oswego.edu/dl/concurrent/index.html</a>  
39    
40    {@link java.util.concurrent.Executor} is a simple standardized
41    interface for defining custom thread-like subsystems, including thread
42    pools, asynch-IO, and lightweight task frameworks.  Depending on which
43    concrete Executor class is being used, tasks may execute in a newly
44    created thread, an existing task-execution thread, or the thread
45    calling <tt>execute()</tt>, and may execute sequentially or
46    concurrently.  Executors also standardize ways of calling threads that
47    compute functions returning results, via a {@link
48    java.util.concurrent.Future}. This is supported in part by defining
49    interface {@link java.util.concurrent.Callable}, the argument/result
50    analog of Runnable.
51    
52    <p> {@link java.util.concurrent.ExecutorService} provides a more
53    complete framework for executing Runnables.  An ExecutorService
54    manages queueing and scheduling of tasks, and allows controlled
55    shutdown.  The two primary implementations of ExecutorService are
56    {@link java.util.concurrent.ThreadPoolExecutor}, a highly tunable and
57    flexible thread pool and {@link
58    java.util.concurrent.ScheduledExecutor}, which adds support for
59    delayed and periodic task execution.  These, and other Executors can
60    be used in conjunction with a {@link java.util.concurrent.FutureTask}
61    to asynchronously
62    start a potentially long-running computation and query the FutureTask
63    to determine if its execution has completed, or cancel it.
64    
65    <p> The {@link java.util.concurrent.Executors} class provides factory
66    methods for the most common kinds and styles of Executors, as well as
67    a few utilities methods for using them.
68    
69  <h2>Queues</h2>  <h2>Queues</h2>
70    
71  A basic (nonblocking) Queue interface that is compatatible with  A basic (nonblocking) {@link java.util.Queue} interface extending
72  java.util.Collections will be introduced into java.util. Also,  java.util.Collection is introduced into java.util. Existing class
73  although it is at the borders of being in scope of JSR-166,  java.util.LinkedList is adapted to support Queue, and a new
74  java.util.LinkedList will be adapted to support Queue, and  non-thread-safe {@link java.util.PriorityQueue} is added.  The
75  a new non-thread-safe java.util.HeapPriorityQueue will be added.  java.util.concurrent {@link
76    java.util.concurrent.ConcurrentLinkedQueue} class supplies an
77    efficient sclable thread-safe non-blocking FIFO queue, and {@link
78    java.util.concurrent.ConcurrentLinkedStack} provides a similar
79    non-blocking LIFO stack.
80    
81  <p> Five implementations in java.util.concurrent support the extended  <p> Five implementations in java.util.concurrent support the extended
82  BlockingQueue interface, that defines blocking versions of put and  {@link java.util.concurrent.BlockingQueue} interface, that defines
83  take: LinkedBlockingQueue, ArrayBlockingQueue, SynchronousQueue,  blocking versions of put and take: {@link
84  PriorityBlockingQueue, and DelayQueue. Additionally,  java.util.concurrent.LinkedBlockingQueue}, {@link
85  java.util.concurrent.LinkedQueue supplies an efficient thread-safe  java.util.concurrent.ArrayBlockingQueue}, {@link
86  non-blocking queue.  java.util.concurrent.SynchronousQueue}, {@link
87    java.util.concurrent.PriorityBlockingQueue}, and
88  <p> Since the target release is JDK1.5, and generics are slated to be  {@link java.util.concurrent.DelayQueue}.
 in 1.5, Queues are parametrized on element type. (Also some others  
 below.)  
   
89    
 <h2>Executors</h2>  
   
 Executors provide a simple standardized interface for defining custom  
 thread-like subsystems, including thread pools, asynch-IO, and  
 lightweight task frameworks.  Executors also standardize ways of  
 calling threads that compute functions returning results, via  
 Futures. This is supported in part by defining interface Callable, the  
 argument/result analog of Runnable.  
   
 <p> While the Executor framework is intended to be extensible the most  
 commonly used Executor will be ThreadExecutor, which can be configured  
 to act as all sorts of thread pools, background threads, etc. The  
 class is designed to be general enough to suffice for the vast  
 majority of usages, even sophisticated ones, yet also includes methods  
 and functionality that simplify routine usage.  
90    
91  <h2>Locks</h2>  <h2>Locks</h2>
92    
93  The Lock interface supports locking disciplines that differ in  The {@link java.util.concurrent.Lock} interface supports locking
94  semantics (reentrant, semaphore-based, etc), and that can be used in  disciplines that differ in semantics (reentrant, fair, etc), and that
95  non-block-structured contexts including hand-over-hand and lock  can be used in non-block-structured contexts including hand-over-hand
96  reordering algorithms. This flexibility comes at the price of more  and lock reordering algorithms. This flexibility comes at the price of
97  awkward syntax.  Implementations include Semaphore, ReentrantMutex  more awkward syntax.  Implementations include {@link
98  FIFOSemaphore, and CountDownLatch.  java.util.concurrent.ReentrantLock} and {@link
99    java.util.concurrent.FairReentrantLock}.
100  <p>  
101  The Locks class additionally supports trylock-designs using builtin  <p> The {@link java.util.concurrent.Locks} class additionally supports
102  locks without needing to use Lock classes.  This requires adding new  some common trylock-designs using builtin locks.
103  capabilities to builtin locks inside JVMs.  
104    <p> The {@link java.util.concurrent.ReadWriteLock} interface similarly
105  <p>  defines locks that may be shared among readers but are exclusive to
106  A ReadWriteLock interface similarly defines locks that may be shared  writers.  Only a single implementation, {@link
107  among readers but are exclusive to writers. For this release, only a  java.util.concurrent.ReentrantReadWriteLock}, is provided, since it
 single implementation, ReentrantReadWriteLock, is planned, since it  
108  covers all standard usage contexts. But programmers may create their  covers all standard usage contexts. But programmers may create their
109  own implementations to cover nonstandard requirements.  own implementations to cover nonstandard requirements.
110    
111  <h2>Conditions</h2>  <h2>Conditions</h2>
112    
113  A Condition class provides the kinds of condition variables associated  The {@link java.util.concurrent.Condition} interface describes the
114  with monitors in other cocurrent languages, as well as pthreads  kinds of condition variables associated with monitors in other
115  condvars.  Their support reduces the need for tricky and/or  concurrent languages, as well as pthreads-style condvars.  Their
116  inefficient solutions to many classic concurrent problems.  Conditions  support reduces the need for tricky and/or inefficient solutions to
117  also address the annoying problem that Object.wait(msecs) does not  many classic concurrent problems.  To avoid compatibility problems,
118  return an indication of whether the wait timed out. This leads to  the names of Condition methods are different than Object versions.
119  error-prone code. Since this method is in class Object, the problem is  
120  basically unfixable.  <h2>Atomics</h2>
121  <p>  
122  To avoid compatibility problems, the names of Condition methods need  The atomic subpackage includes a small library of classes, including
123  to be different than Object versions. The downside of this is that  AtomicInteger, AtomicLong, and AtomicReference that support
124  people can make the mistake of calling cond.notify instead of  compareAndSet (CAS) and related atomic operations.
 cond.signal. However, they will get IllegalMonitorState exceptions if  
 they do, so they can detect the error if they ever run the code.  
 <p>  
 The implementation requires VM magic to atomically suspend and release  
 lock. But it is unlikely to be very challenging for JVM providers,  
 since most layer Java monitors on top of posix condvars or similar  
 low-level functionality anyway.  
   
 <h2>Atomic variables</h2>  
   
 Classes AtomicInteger, AtomicLong, AtomicDouble, AtomicFloat, and  
 AtomicReference provide simple scalar variables supporting  
 compareAndSwap (CAS) and related atomic operations. These are  
 desparately needed by those performing low-level concurrent system  
 programming, but much less commonly useful in higher-level frameworks.  
   
125    
126  <h2>Timing</h2>  <h2>Timing</h2>
127    
128  Java has always supported sub-millisecond versions of several native  The {@link java.util.concurrent.TimeUnit} class provides multiple
129  time-out-based methods (such as Object.wait), but not methods to  granularities (including nanoseconds) for both accessing time and
130  actually perform timing in finer-grained units. We address this by  performing time-out based operations.
 introducing class Clock, which provides multiple granularities for  
 both accessing time and performing time-out based operations.  
   
131    
132  <h2>Synchronizers</h2>  <h2>Synchronizers</h2>
133    
134  Five classes aid common special-purpose synchronization idioms.  Five classes aid common special-purpose synchronization idioms.
135  Semaphores and FifoSemaphores are classic concurrency tools.  Latches  {@link java.util.concurrent.Semaphore} and {@link
136  are very simple yet very common objects useful for blocking until a  java.util.concurrent.FairSemaphore} are classic concurrency tools.
137  single signal, event, or condition holds.  CyclicBarriers are  {@link java.util.concurrent.CountDownLatch} is very simple yet very
138  resettable multiway synchronization points very common in some styles  common utility for blocking until a single signal, event, or condition
139  of parallel programming. Exchangers allow two threads to exchange  holds.  A {@link java.util.concurrent.CyclicBarrier} is a resettable multiway
140  objects at a rendezvous point.  synchronization point common in some styles of parallel
141    programming. An {@link java.util.concurrent.Exchanger} allows two
142    threads to exchange objects at a rendezvous point.
143    
144  <h2>Concurrent Collections</h2>  <h2>Concurrent Collections</h2>
145    
146  JSR 166 will supply a few Collection implementations designed for use  Besides Queues, this package supplies a few Collection implementations
147  in multithreaded contexts: ConcurrentHashTable, CopyOnWriteArrayList,  designed for use in multithreaded contexts: {@link
148  and CopyOnWriteArraySet.  java.util.concurrent.ConcurrentHashMap}, {@link
149    java.util.concurrent.CopyOnWriteArrayList}, and {@link
150    java.util.concurrent.CopyOnWriteArraySet}.
151    
152    <p>The "Concurrent" prefix for classes is a shorthand
153    indicating several differences from similar "synchronized"
154    classes. For example <tt>java.util.Hashtable</tt> and
155    <tt>Collections.synchronizedMap(new HashMap())</tt> are
156    synchronized. But {@link
157    java.util.concurrent.ConcurrentHashMap} is "concurrent".
158    A concurrent collection (among other kinds of classes) is
159    thread-safe, but not governed by a single exclusion lock. So, in the
160    particular case of ConcurrentHashMap, it safely permits any number of
161    concurrent reads as well as a tunable number of concurrent writes.
162    There may still be a role for "synchronized" classes in some
163    multithreaded programs -- they can sometimes be useful when you need
164    to prevent ALL access to a collection via a single lock, at the
165    expense of much poor scalability. In all other cases, "concurrent"
166    versions are normally preferable.
167    
168    <p> Most concurrent Collection implementations (including most Queues)
169    also differ from the usual java.util conventions in that their Iterators
170    provide <em>weakly consistent</em> rather than fast-fail traversal. A
171    weakly consistent iterator is thread-safe, but does not necessarily
172    freeze the collection while iterating, so it may (or may not) reflect
173    any updates since the iterator was created.
174    
175  <h2>Uncaught Exception Handlers</h2>  <h2>Uncaught Exception Handlers</h2>
176    
177  The java.lang.Thread class will be modified to allow per-thread  The java.lang.Thread class is modified to allow per-thread
178  installation of handlers for uncaught exceptions. Ths optionally  installation of handlers for uncaught exceptions. Ths optionally
179  disassociates these handlers from ThreadGroups, which has proven to be  disassociates these handlers from ThreadGroups, which has proven to be
180  too inflexible in many multithreaded programs. (Note that the combination  too inflexible in many multithreaded programs. (Note that the
181  of features in JSR 166 make ThreadGroups even less likely to  combination of features in JSR166 make ThreadGroups even less likely
182  be used in most programs. Perhaps they will eventually be deprecated.)  to be used in most programs. Perhaps they will eventually be
183  <p>  deprecated.)
184  Additionally,  ThreadLocals will now support a means to  
185  remove a ThreadLocals, which is needed in some thread-pool and  <p> Additionally, java.lang.ThreadLocal now supports a means to remove
186  worker-thread designs.  a ThreadLocal, which is needed in some thread-pool and worker-thread
187    designs.
188    
189    <hr>    <hr>
190    <address><A HREF="http://gee.cs.oswego.edu/dl">Doug Lea</A></address>    <address><A HREF="http://gee.cs.oswego.edu/dl">Doug Lea</A></address>

Legend:
Removed from v.1.1  
changed lines
  Added in v.1.6

Doug Lea
ViewVC Help
Powered by ViewVC 1.0.8