/[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.1 by tim, Fri May 16 14:13:04 2003 UTC revision 1.10 by tim, Wed Aug 6 16:04:58 2003 UTC
# Line 1  Line 1 
1  <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">  <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
2  <html>  <html>
3   <head>   <head>
4     <title>JSR 166 Snapshot Introduction.</title>     <title>JSR 166 Community Review Draft Introduction.</title>
5    </head>    </head>
6    
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>
9    
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>
12    
13  To join a mailing list discussing this JSR, go to:  To chack 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  <p>  HREF="http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest">
17  <em>  http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest</A>
18   Disclaimer - This prototype is experimental code developed as part of  .
19   JSR166 and made available to the developer community for use  <p>
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  <em> <b>Disclaimer</b>. The prototype implementation is experimental
22   result of your feedback. Because these features have not yet been  code developed as part of JCP JSR-166 is made available to the
23   approved for addition to the Java language, there is no schedule for  developer community for use as-is. It is not a supported product. Use
24   their inclusion in a product.  it at your own risk. The specification, language and implementation
25  </em>  are subject to change as a result of your feedback. Because these
26    features have not yet been approved for addition to the Java language,
27  <p>  there is no schedule for their inclusion in a product.  </em>
28  Package java.util.concurrent contains utility classes that are  
29  commonly useful in concurrent programming. Like package java.util, it  <p> <em> <b>Disclaimer</b>.  This draft specification was produced
30  includes a few small standardized extensible frameworks, as well as  using JDK1.4 tools plus some preprocessing. The resulting javadocs do
31  some classes that provide useful functionality and are otherwise  not yet correctly render other planned JDK1.5 constructs on which
32  tedious or difficult to implement.  In this JSR, we have been  JSR-166 relies, most notably the use of generic types. We are
33  conservative in selecting only those APIs and implementations that are  releasing this version now (before the availability of JDK1.5-based
34  useful enough to encourage nearly all concurrent programmers to use  tools) because, even though they are misformatted and sometimes lack
35  routinely.  JSR 166 also includes a few changes and additions in  proper cross-referencing, they otherwise convey the intended
36  packages outside of java.util.concurrent: java.lang, to address  specifications.  </em>
37  uncaught exceptions, and java.util to better integrate queues.  
38  The API covers:  <p> JSR-166 introduces package <tt>java.util.concurrent</tt>
39    containing utility classes commonly useful in concurrent
40    <ul>  programming. Like package <tt>java.util</tt>, it includes a few small
41      <li> Queues  standardized extensible frameworks, as well as some classes that
42      <li> Executors  provide useful functionality and are otherwise tedious or difficult to
43      <li> Locks  implement.
44      <li> Condition variables  
45      <li> Atomic variables  <p>JSR-166 focusses on breadth, providing critical functionality
46      <li> Timing  useful across a wide range of concurrent programming styles and
47      <li> Synchronizers  applications, ranging from low-level atomic operations, to
48      <li> Concurrent Collections  customizable locks and synchronization aids, to various concurrent
49      <li> Uncaught Exception Handlers  data structures, to high-level execution agents including thread
50    </ul>  pools. This diversity reflects the range of contexts in which
51    developers of concurrent programs have been found to require or desire
52    support not previously available in J2SE, which also keeping the
53  The main rationale for JSR 166 is that threading primitives, such as  resulting package small; providing only that minimial support for
54  synchronized blocks, Object.wait and Object.notify, are insufficient  which it makes sense to standardize.
55  for many programming tasks.  Currently, developers can use only the  
56  concurrency control constructs provided in the Java language  <p>Descriptions and brief motivations for the main components may be
57  itself. These are too low level for some applications, and are  found in the associated package documentation.  JSR-166 also includes
58  incomplete for others.  As a result, application programmers are often  a few changes and additions in packages outside of
59  forced to implement their own concurrency facilities, resulting in  java.util.concurrent.  Here are brief descriptions.
 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.  
   
 <p>  
 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>  
   
60    
61  <h2>Queues</h2>  <h2>Queues</h2>
62    
63  A basic (nonblocking) Queue interface that is compatatible with  A basic (nonblocking) {@link java.util.Queue} interface extending
64  java.util.Collections will be introduced into java.util. Also,  {@link java.util.Collection} is introduced into
65  although it is at the borders of being in scope of JSR-166,  <tt>java.util</tt>. Existing class {@link java.util.LinkedList} is
66  java.util.LinkedList will be adapted to support Queue, and  adapted to support Queue, and a new non-thread-safe {@link
67  a new non-thread-safe java.util.HeapPriorityQueue will be added.  java.util.PriorityQueue} is added.
68    
69  <p> Five implementations in java.util.concurrent support the extended  <h2>Threads</h2>
70  BlockingQueue interface, that defines blocking versions of put and  
71  take: LinkedBlockingQueue, ArrayBlockingQueue, SynchronousQueue,  Two minor changes are introduced to the {@link java.lang.Thread}
72  PriorityBlockingQueue, and DelayQueue. Additionally,  class: It now allows per-thread installation of handlers for uncaught
73  java.util.concurrent.LinkedQueue supplies an efficient thread-safe  exceptions. Ths optionally disassociates handlers from ThreadGroups,
74  non-blocking queue.  which has proven to be too inflexible. (Note that the combination of
75    features in JSR-166 make ThreadGroups even less likely to be used in
76  <p> Since the target release is JDK1.5, and generics are slated to be  most programs. Perhaps they will eventually be deprecated.) Secondly,
77  in 1.5, Queues are parametrized on element type. (Also some others  access checks are no longer required when a Thread interrupts
78  below.)  <em>itself</em>.  The <tt>interrupt</tt> method is the only way to
79    re-assert a thread's interruption status (and in the case of
80    self-interruption has no other effect than this).  The check here
81  <h2>Executors</h2>  previously caused unjustifiable and uncontrollable failures when
82    restricted code invoked library code that must reassert interruption
83  Executors provide a simple standardized interface for defining custom  to correctly propagate status when encountering some
84  thread-like subsystems, including thread pools, asynch-IO, and  <tt>InterruptedExceptions</tt>.
 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.  
   
 <h2>Locks</h2>  
   
 The Lock interface supports locking disciplines that differ in  
 semantics (reentrant, semaphore-based, 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 Semaphore, ReentrantMutex  
 FIFOSemaphore, and CountDownLatch.  
85    
86  <p>  <h2>Timing</h2>
 The Locks class additionally supports trylock-designs using builtin  
 locks without needing to use Lock classes.  This requires adding new  
 capabilities to builtin locks inside JVMs.  
   
 <p>  
 A ReadWriteLock interface similarly defines locks that may be shared  
 among readers but are exclusive to writers. For this release, only a  
 single implementation, ReentrantReadWriteLock, is planned, since it  
 covers all standard usage contexts. But programmers may create their  
 own implementations to cover nonstandard requirements.  
   
 <h2>Conditions</h2>  
   
 A Condition class provides the kinds of condition variables associated  
 with monitors in other cocurrent languages, as well as pthreads  
 condvars.  Their support reduces the need for tricky and/or  
 inefficient solutions to many classic concurrent problems.  Conditions  
 also address the annoying problem that Object.wait(msecs) does not  
 return an indication of whether the wait timed out. This leads to  
 error-prone code. Since this method is in class Object, the problem is  
 basically unfixable.  
 <p>  
 To avoid compatibility problems, the names of Condition methods need  
 to be different than Object versions. The downside of this is that  
 people can make the mistake of calling cond.notify instead of  
 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.  
87    
88    Method <tt>nanoTime</tt> is added to {@link java.lang.System}. It
89    provides a high-precision timing facility that is distinct from and
90    uncoordinated with <tt>System.currentTimeMillis</tt>.
91    
92    <h2>Removing ThreadLocals</h2>
93    
94    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
96    designs.
97    
 <h2>Timing</h2>  
98    
 Java has always supported sub-millisecond versions of several native  
 time-out-based methods (such as Object.wait), but not methods to  
 actually perform timing in finer-grained units. We address this by  
 introducing class Clock, which provides multiple granularities for  
 both accessing time and performing time-out based operations.  
   
   
 <h2>Synchronizers</h2>  
   
 Five classes aid common special-purpose synchronization idioms.  
 Semaphores and FifoSemaphores are classic concurrency tools.  Latches  
 are very simple yet very common objects useful for blocking until a  
 single signal, event, or condition holds.  CyclicBarriers are  
 resettable multiway synchronization points very common in some styles  
 of parallel programming. Exchangers allow two threads to exchange  
 objects at a rendezvous point.  
   
   
 <h2>Concurrent Collections</h2>  
   
 JSR 166 will supply a few Collection implementations designed for use  
 in multithreaded contexts: ConcurrentHashTable, CopyOnWriteArrayList,  
 and CopyOnWriteArraySet.  
   
 <h2>Uncaught Exception Handlers</h2>  
   
 The java.lang.Thread class will be 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 JSR 166 make ThreadGroups even less likely to  
 be used in most programs. Perhaps they will eventually be deprecated.)  
 <p>  
 Additionally,  ThreadLocals will now support a means to  
 remove a ThreadLocals, which is needed in some thread-pool and  
 worker-thread designs.  
99    
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>
Legend:
Removed from v.1.1  
changed lines
  Added in v.1.10
dl@cs.oswego.edu
 ViewVC Help
Powered by ViewVC 1.1.27