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.11 by tim, Wed Aug 6 17:40:20 2003 UTC
# Line 1  Line 1 
2  <html>  <html>
3   <head>   <head>
4     <title>JSR 166 Snapshot Introduction.</title>     <title>JSR 166 Community Review Draft Introduction.</title>
5    </head>    </head>
7    <body bgcolor="#ffffee" vlink="#0000aa" link="#cc0000">    <body bgcolor="#ffffee" vlink="#0000aa" link="#cc0000">
8    <h1>JSR 166 Snapshot Introduction.</h1>    <h1>JSR 166 Community Review Draft Introduction.</h1>
10    by <a href="http://gee.cs.oswego.edu/dl">Doug Lea</a>    by <a href="http://gee.cs.oswego.edu/dl">Doug Lea</a>
11    <p>    <p>
13  To join a mailing list discussing this JSR, go to:  To check for updates to this draft, access a preliminary prototype
14  <A HREF="http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest"> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest</A> .  release of main functionality, or join a mailing list discussing this
15    JSR, go to: <A
16    HREF="http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest">
17    http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest</A>
18    .
19  <p>  <p>
20  <em>  
21   Disclaimer - This prototype is experimental code developed as part of  <em> <b>Disclaimer</b>. The prototype implementation is experimental
22   JCP JSR166 and made available to the developer community for use  code developed as part of JCP JSR-166 is made available to the
23   as-is. It is not a supported product. Use it at your own risk. The  developer community for use as-is. It is not a supported product. Use
24   specification, language and implementation are subject to change as a  it at your own risk. The specification, language and implementation
25   result of your feedback. Because these features have not yet been  are subject to change as a result of your feedback. Because these
26   approved for addition to the Java language, there is no schedule for  features have not yet been approved for addition to the Java language,
27   their inclusion in a product.  there is no schedule for their inclusion in a product.  </em>
28  </em>  
29    <p> <em> <b>Disclaimer</b>.  This draft specification was produced
30  <p> Package java.util.concurrent contains utility classes commonly  using JDK1.4 tools plus some preprocessing. The resulting javadocs do
31  useful in concurrent programming. Like package java.util, it includes  not yet correctly render other planned JDK1.5 constructs on which
32  a few small standardized extensible frameworks, as well as some  JSR-166 relies, most notably the use of generic types. We are
33  classes that provide useful functionality and are otherwise tedious or  releasing this version now (before the availability of JDK1.5-based
34  difficult to implement.  JSR166 also includes a few changes and  tools) because, even though they are misformatted and sometimes lack
35  additions in packages outside of java.util.concurrent: java.lang, to  proper cross-referencing, they otherwise convey the intended
36  address uncaught exceptions, and java.util to better integrate with  specifications.  </em>
37  collections.  Since the target release is JDK1.5, many APIs use  
38  generics to parameterize on types.  Here are brief descriptions of the  <p> JSR-166 introduces package <tt>java.util.concurrent</tt>
39  main components.  containing utility classes commonly useful in concurrent
40    programming. Like package <tt>java.util</tt>, it includes a few small
41  <h2>Executors</h2>  standardized extensible frameworks, as well as some classes that
42    provide useful functionality and are otherwise tedious or difficult to
43  {@link java.util.concurrent.Executor} is a simple standardized  implement.
44  interface for defining custom thread-like subsystems, including thread  
45  pools, asynch-IO, and lightweight task frameworks.  Depending on which  <p>JSR-166 focusses on breadth, providing critical functionality
46  concrete Executor class is being used, tasks may execute in a newly  useful across a wide range of concurrent programming styles and
47  created thread, an existing task-execution thread, or the thread  applications, ranging from low-level atomic operations, to
48  calling <tt>execute()</tt>, and may execute sequentially or  customizable locks and synchronization aids, to various concurrent
49  concurrently.  Executors also standardize ways of calling threads that  data structures, to high-level execution agents including thread
50  compute functions returning results, via a {@link  pools. This diversity reflects the range of contexts in which
51  java.util.concurrent.Future}. This is supported in part by defining  developers of concurrent programs have been found to require or desire
52  interface {@link java.util.concurrent.Callable}, the argument/result  support not previously available in J2SE, which also keeping the
53  analog of Runnable.  resulting package small; providing only that minimial support for
54    which it makes sense to standardize.
55  <p> {@link java.util.concurrent.ExecutorService} provides a more  
56  complete framework for executing Runnables.  An ExecutorService  <p>Descriptions and brief motivations for the main components may be
57  manages queueing and scheduling of tasks, and allows controlled  found in the associated package documentation.  JSR-166 also includes
58  shutdown.  The two primary implementations of ExecutorService are  a few changes and additions in packages outside of
59  {@link java.util.concurrent.ThreadPoolExecutor}, a highly tunable and  java.util.concurrent.  Here are brief descriptions.
 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.  
61  <h2>Queues</h2>  <h2>Queues</h2>
63  A basic (nonblocking) {@link java.util.Queue} interface extending  A basic (nonblocking) {@link java.util.Queue} interface extending
64  java.util.Collection is introduced into java.util. Existing class  {@link java.util.Collection} is introduced into
65  java.util.LinkedList is adapted to support Queue, and a new  <tt>java.util</tt>. Existing class {@link java.util.LinkedList} is
66  non-thread-safe {@link java.util.PriorityQueue} is added.  The  adapted to support Queue, and a new non-thread-safe {@link
67  java.util.concurrent {@link  java.util.PriorityQueue} is added.
68  java.util.concurrent.ConcurrentLinkedQueue} class supplies an  
69  efficient sclable thread-safe non-blocking FIFO queue, and {@link  <h2>Threads</h2>
70  java.util.concurrent.ConcurrentLinkedStack} provides a similar  
71  non-blocking LIFO stack.  Two minor changes are introduced to the {@link java.lang.Thread}
72    class: It now allows per-thread installation of handlers for uncaught
73  <p> Five implementations in java.util.concurrent support the extended  exceptions. Ths optionally disassociates handlers from ThreadGroups,
74  {@link java.util.concurrent.BlockingQueue} interface, that defines  which has proven to be too inflexible. (Note that the combination of
75  blocking versions of put and take: {@link  features in JSR-166 make ThreadGroups even less likely to be used in
76  java.util.concurrent.LinkedBlockingQueue}, {@link  most programs. Perhaps they will eventually be deprecated.) Secondly,
77  java.util.concurrent.ArrayBlockingQueue}, {@link  access checks are no longer required when a Thread interrupts
78  java.util.concurrent.SynchronousQueue}, {@link  <em>itself</em>.  The <tt>interrupt</tt> method is the only way to
79  java.util.concurrent.PriorityBlockingQueue}, and  re-assert a thread's interruption status (and in the case of
80  {@link java.util.concurrent.DelayQueue}.  self-interruption has no other effect than this).  The check here
81    previously caused unjustifiable and uncontrollable failures when
82    restricted code invoked library code that must reassert interruption
83  <h2>Locks</h2>  to correctly propagate status when encountering some
84    <tt>InterruptedExceptions</tt>.
 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  
 <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.  
 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.  
 The atomic subpackage includes a small library of classes, including  
 AtomicInteger, AtomicLong, and AtomicReference that support  
 compareAndSet (CAS) and related atomic operations.  
86  <h2>Timing</h2>  <h2>Timing</h2>
88  The {@link java.util.concurrent.TimeUnit} class provides multiple  Method <tt>nanoTime</tt> is added to {@link java.lang.System}. It
89  granularities (including nanoseconds) for both accessing time and  provides a high-precision timing facility that is distinct from and
90  performing time-out based operations.  uncoordinated with <tt>System.currentTimeMillis</tt>.
92  <h2>Synchronizers</h2>  <h2>Removing ThreadLocals</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  
 <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.  
 <h2>Uncaught Exception Handlers</h2>  
 The java.lang.Thread class is modified to allow per-thread  
 installation of handlers for uncaught exceptions. Ths optionally  
 disassociates these handlers from ThreadGroups, which has proven to be  
 too inflexible in many multithreaded programs. (Note that the  
 combination of features in JSR166 make ThreadGroups even less likely  
 to be used in most programs. Perhaps they will eventually be  
94  <p> Additionally, java.lang.ThreadLocal now supports a means to remove  The {@link java.lang.ThreadLocal} class now supports a means to remove
95  a ThreadLocal, which is needed in some thread-pool and worker-thread  a ThreadLocal, which is needed in some thread-pool and worker-thread
96  designs.  designs.
100    <hr>    <hr>
101    <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>
102   </body>   </body>

Removed from v.1.6  
changed lines
  Added in v.1.11

ViewVC Help
Powered by ViewVC 1.1.27