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

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

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

revision 1.6 by dl, Thu Jun 26 10:46:55 2003 UTC revision 1.8 by dl, Mon Jul 14 16:35:59 2003 UTC
# Line 24  To join a mailing list discussing this J Line 24  To join a mailing list discussing this J
24   their inclusion in a product.   their inclusion in a product.
25  </em>  </em>
26    
27  <p> Package java.util.concurrent contains utility classes commonly  <p> JSR166 introduces package <tt>java.util.concurrent</tt> containing
28  useful in concurrent programming. Like package java.util, it includes  utility classes commonly useful in concurrent programming. Like
29  a few small standardized extensible frameworks, as well as some  package java.util, it includes a few small standardized extensible
30  classes that provide useful functionality and are otherwise tedious or  frameworks, as well as some classes that provide useful functionality
31  difficult to implement.  JSR166 also includes a few changes and  and are otherwise tedious or difficult to implement. JSR-166 focusses
32  additions in packages outside of java.util.concurrent: java.lang, to  on breadth, prviding critical functionality useful across a wide range
33  address uncaught exceptions, and java.util to better integrate with  of concurrent programming styles and applications, ranging from
34  collections.  Since the target release is JDK1.5, many APIs use  low-level atomic operations, to customizable locks and synchronization
35  generics to parameterize on types.  Here are brief descriptions of the  aids, to various concurrent data structures, to thread pools.
36  main components.  Descriptions of the main components may be found in the associated
37    package documentation.
38  <h2>Executors</h2>  
39    <p> JSR166 also includes a few changes and additions in packages
40  {@link java.util.concurrent.Executor} is a simple standardized  outside of java.util.concurrent.  Here are brief descriptions.
 interface for defining custom thread-like subsystems, including thread  
 pools, asynch-IO, and lightweight task frameworks.  Depending on which  
 concrete Executor class is being used, tasks may execute in a newly  
 created thread, an existing task-execution thread, or the thread  
 calling <tt>execute()</tt>, and may execute sequentially or  
 concurrently.  Executors also standardize ways of calling threads that  
 compute functions returning results, via a {@link  
 java.util.concurrent.Future}. This is supported in part by defining  
 interface {@link java.util.concurrent.Callable}, the argument/result  
 analog of Runnable.  
   
 <p> {@link java.util.concurrent.ExecutorService} provides a more  
 complete framework for executing Runnables.  An ExecutorService  
 manages queueing and scheduling of tasks, and allows controlled  
 shutdown.  The two primary implementations of ExecutorService are  
 {@link java.util.concurrent.ThreadPoolExecutor}, a highly tunable and  
 flexible thread pool and {@link  
 java.util.concurrent.ScheduledExecutor}, which adds support for  
 delayed and periodic task execution.  These, and other Executors can  
 be used in conjunction with a {@link java.util.concurrent.FutureTask}  
 to asynchronously  
 start a potentially long-running computation and query the FutureTask  
 to determine if its execution has completed, or cancel it.  
   
 <p> The {@link java.util.concurrent.Executors} class provides factory  
 methods for the most common kinds and styles of Executors, as well as  
 a few utilities methods for using them.  
41    
42  <h2>Queues</h2>  <h2>Queues</h2>
43    
44  A basic (nonblocking) {@link java.util.Queue} interface extending  A basic (nonblocking) {@link java.util.Queue} interface extending
45  java.util.Collection is introduced into java.util. Existing class  java.util.Collection is introduced into java.util. Existing class
46  java.util.LinkedList is adapted to support Queue, and a new  java.util.LinkedList is adapted to support Queue, and a new
47  non-thread-safe {@link java.util.PriorityQueue} is added.  The  non-thread-safe {@link java.util.PriorityQueue} is added.
 java.util.concurrent {@link  
 java.util.concurrent.ConcurrentLinkedQueue} class supplies an  
 efficient sclable thread-safe non-blocking FIFO queue, and {@link  
 java.util.concurrent.ConcurrentLinkedStack} provides a similar  
 non-blocking LIFO stack.  
   
 <p> Five implementations in java.util.concurrent support the extended  
 {@link java.util.concurrent.BlockingQueue} interface, that defines  
 blocking versions of put and take: {@link  
 java.util.concurrent.LinkedBlockingQueue}, {@link  
 java.util.concurrent.ArrayBlockingQueue}, {@link  
 java.util.concurrent.SynchronousQueue}, {@link  
 java.util.concurrent.PriorityBlockingQueue}, and  
 {@link java.util.concurrent.DelayQueue}.  
   
   
 <h2>Locks</h2>  
   
 The {@link java.util.concurrent.Lock} interface supports locking  
 disciplines that differ in semantics (reentrant, fair, etc), and that  
 can be used in non-block-structured contexts including hand-over-hand  
 and lock reordering algorithms. This flexibility comes at the price of  
 more awkward syntax.  Implementations include {@link  
 java.util.concurrent.ReentrantLock} and {@link  
 java.util.concurrent.FairReentrantLock}.  
   
 <p> The {@link java.util.concurrent.Locks} class additionally supports  
 some common trylock-designs using builtin locks.  
   
 <p> The {@link java.util.concurrent.ReadWriteLock} interface similarly  
 defines locks that may be shared among readers but are exclusive to  
 writers.  Only a single implementation, {@link  
 java.util.concurrent.ReentrantReadWriteLock}, is provided, since it  
 covers all standard usage contexts. But programmers may create their  
 own implementations to cover nonstandard requirements.  
   
 <h2>Conditions</h2>  
   
 The {@link java.util.concurrent.Condition} interface describes the  
 kinds of condition variables associated with monitors in other  
 concurrent languages, as well as pthreads-style condvars.  Their  
 support reduces the need for tricky and/or inefficient solutions to  
 many classic concurrent problems.  To avoid compatibility problems,  
 the names of Condition methods are different than Object versions.  
   
 <h2>Atomics</h2>  
   
 The atomic subpackage includes a small library of classes, including  
 AtomicInteger, AtomicLong, and AtomicReference that support  
 compareAndSet (CAS) and related atomic operations.  
   
 <h2>Timing</h2>  
   
 The {@link java.util.concurrent.TimeUnit} class provides multiple  
 granularities (including nanoseconds) for both accessing time and  
 performing time-out based operations.  
   
 <h2>Synchronizers</h2>  
   
 Five classes aid common special-purpose synchronization idioms.  
 {@link java.util.concurrent.Semaphore} and {@link  
 java.util.concurrent.FairSemaphore} are classic concurrency tools.  
 {@link java.util.concurrent.CountDownLatch} is very simple yet very  
 common utility for blocking until a single signal, event, or condition  
 holds.  A {@link java.util.concurrent.CyclicBarrier} is a resettable multiway  
 synchronization point common in some styles of parallel  
 programming. An {@link java.util.concurrent.Exchanger} allows two  
 threads to exchange objects at a rendezvous point.  
   
 <h2>Concurrent Collections</h2>  
   
 Besides Queues, this package supplies a few Collection implementations  
 designed for use in multithreaded contexts: {@link  
 java.util.concurrent.ConcurrentHashMap}, {@link  
 java.util.concurrent.CopyOnWriteArrayList}, and {@link  
 java.util.concurrent.CopyOnWriteArraySet}.  
   
 <p>The "Concurrent" prefix for classes is a shorthand  
 indicating several differences from similar "synchronized"  
 classes. For example <tt>java.util.Hashtable</tt> and  
 <tt>Collections.synchronizedMap(new HashMap())</tt> are  
 synchronized. But {@link  
 java.util.concurrent.ConcurrentHashMap} is "concurrent".  
 A concurrent collection (among other kinds of classes) is  
 thread-safe, but not governed by a single exclusion lock. So, in the  
 particular case of ConcurrentHashMap, it safely permits any number of  
 concurrent reads as well as a tunable number of concurrent writes.  
 There may still be a role for "synchronized" classes in some  
 multithreaded programs -- they can sometimes be useful when you need  
 to prevent ALL access to a collection via a single lock, at the  
 expense of much poor scalability. In all other cases, "concurrent"  
 versions are normally preferable.  
   
 <p> Most concurrent Collection implementations (including most Queues)  
 also differ from the usual java.util conventions in that their Iterators  
 provide <em>weakly consistent</em> rather than fast-fail traversal. A  
 weakly consistent iterator is thread-safe, but does not necessarily  
 freeze the collection while iterating, so it may (or may not) reflect  
 any updates since the iterator was created.  
48    
49  <h2>Uncaught Exception Handlers</h2>  <h2>Uncaught Exception Handlers</h2>
50    
# Line 182  combination of features in JSR166 make T Line 56  combination of features in JSR166 make T
56  to be used in most programs. Perhaps they will eventually be  to be used in most programs. Perhaps they will eventually be
57  deprecated.)  deprecated.)
58    
59  <p> Additionally, java.lang.ThreadLocal now supports a means to remove  <h2>High precision timing</h2>
60  a ThreadLocal, which is needed in some thread-pool and worker-thread  
61    Method <tt>nanoTime</tt> is added to <tt>java.lang.System</tt>. It
62    provides a high-precision timing facility that is distinct from
63    and uncoordinated with <tt>System.currentTimeMillis</tt>.
64    
65    <h2>Removing ThreadLocals</h2>
66    
67    The java.lang.ThreadLocal class now supports a means to remove a
68    ThreadLocal, which is needed in some thread-pool and worker-thread
69  designs.  designs.
70    
71    <hr>    <hr>
Legend:
Removed from v.1.6  
changed lines
  Added in v.1.8
dl@cs.oswego.edu
 ViewVC Help
Powered by ViewVC 1.1.27