[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.2, Wed Jun 4 11:33:01 2003 UTC revision 1.19, Sun Nov 21 01:40:32 2004 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 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 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:  This is maintenance repository of JSR166 specifications.  For further
14  <A HREF="http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest"> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest</A> .  information, go to: <A
15    HREF="http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest">
16  <p>  http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest</A>.
17  <em>  
18   Disclaimer - This prototype is experimental code developed as part of  <p><em>Note: The javadocs here do <em>not</em> include pre-existing
19   JSR166 and made available to the developer community for use  java classes (for example <tt>java.lang.Thread</tt>) that were changed
20   as-is. It is not a supported product. Use it at your own risk. The  as part of the JSR166 spec.  On the other hand, the javadocs here so
21   specification, language and implementation are subject to change as a  include some existing java.util Collection interfaces and classes that
22   result of your feedback. Because these features have not yet been  are not part of the spec, but are included because some new methods
23   approved for addition to the Java language, there is no schedule for  implement or inherit from their specifications.
  their inclusion in a product.  
24  </em>  </em>
25    
26  <p>  <p> JSR-166 introduces package <tt>java.util.concurrent</tt>
27  Package java.util.concurrent contains utility classes that are  containing utility classes commonly useful in concurrent
28  commonly useful in concurrent programming. Like package java.util, it  programming. Like package <tt>java.util</tt>, it includes a few small
29  includes a few small standardized extensible frameworks, as well as  standardized extensible frameworks, as well as other classes that
30  some classes that provide useful functionality and are otherwise  provide useful functionality and are otherwise tedious or difficult to
31  tedious or difficult to implement.  In this JSR, we have been  implement.
32  conservative in selecting only those APIs and implementations that are  
33  useful enough to encourage nearly all concurrent programmers to use  <p>JSR-166 focusses on breadth, providing critical functionality
34  routinely.  JSR 166 also includes a few changes and additions in  useful across a wide range of concurrent programming styles and
35  packages outside of java.util.concurrent: java.lang, to address  applications, ranging from low-level atomic operations, to
36  uncaught exceptions, and java.util to better integrate queues.  customizable locks and synchronization aids, to various concurrent
37  The API covers:  data structures, to high-level execution agents including thread
38    pools. This diversity reflects the range of contexts in which
39    <ul>  developers of concurrent programs have been found to require or desire
40      <li> Queues  support not previously available in J2SE, which also keeping the
41      <li> Executors  resulting package small; providing only functionality that has been
42      <li> Locks  found to be worthwhile to standardize.
43      <li> Condition variables  
44      <li> Atomic variables  <p>Descriptions and brief motivations for the main components may be
45      <li> Timing  found in the associated package documentation.  JSR-166 also includes
46      <li> Synchronizers  a few changes and additions in packages outside of
47      <li> Concurrent Collections  java.util.concurrent.  Here are brief descriptions.
     <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.  
   
 <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>  
   
48    
49  <h2>Queues</h2>  <h2>Queues</h2>
50    
51  A basic (nonblocking) Queue interface that is compatatible with  A basic (nonblocking) {@link java.util.Queue} interface extending
52  java.util.Collections will be introduced into java.util. Also,  {@link java.util.Collection} is introduced into
53  although it is at the borders of being in scope of JSR-166,  <tt>java.util</tt>. Existing class {@link java.util.LinkedList} is
54  java.util.LinkedList will be adapted to support Queue, and  adapted to support Queue, and a new non-thread-safe {@link
55  a new non-thread-safe java.util.PriorityQueue will be added.  java.util.PriorityQueue} is added.
   
 <p> Five implementations in java.util.concurrent support the extended  
 BlockingQueue interface, that defines blocking versions of put and  
 take: LinkedBlockingQueue, ArrayBlockingQueue, SynchronousQueue,  
 PriorityBlockingQueue, and DelayQueue. Additionally,  
 java.util.concurrent.LinkedQueue supplies an efficient thread-safe  
 non-blocking queue.  
   
 <p> Since the target release is JDK1.5, and generics are slated to be  
 in 1.5, Queues are parametrized on element type. (Also some others  
 below.)  
   
   
 <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> Executors provide a framework for executing Runnables.  The  
 Executor manages queueing and scheduling of tasks, and creation and  
 teardown of threads.  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 execute(), and may  
 execute sequentially or concurrently.  
   
 <p> Several concrete implementations of Executor are included in  
 java.util.concurrent, including ThreadPoolExecutor, a flexible thread  
 pool and ScheduledExecutor, which adds support for delayed and  
 periodic task execution.  Executor can be used in conjunction with  
 FutureTask (which implements Runnable) to asynchronously start a  
 potentially long-running computation and query the FutureTask to  
 determine if its execution has completed.  
   
 <p> The <tt>Executors</tt> class provides factory methods for all  
 of the types of executors provided in  
 <tt>java.util.concurrent</tt>.  
   
   
 <h2>Locks</h2>  
   
 The 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 ReentrantLock and  
 FairReentrantLock.  
56    
57  <p>  <h2>Threads</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.  
58    
59  <p>  Three minor changes are introduced to the {@link java.lang.Thread}
60  A ReadWriteLock interface similarly defines locks that may be shared  class:
61  among readers but are exclusive to writers. For this release, only a  <ul>
62  single implementation, ReentrantReadWriteLock, is planned, since it    <li> It now allows per-thread installation of handlers for uncaught
63  covers all standard usage contexts. But programmers may create their    exceptions. Ths optionally disassociates handlers from ThreadGroups,
64  own implementations to cover nonstandard requirements.    which has proven to be too inflexible. (Note that the combination of
65      features in JSR-166 make ThreadGroups even less likely to be used in
66  <h2>Conditions</h2>    most programs. Perhaps they will eventually be deprecated.)
67    
68  A Condition class provides the kinds of condition variables associated    <li> Access checks are no longer required when a Thread interrupts
69  with monitors in other cocurrent languages, as well as pthreads    <em>itself</em>.  The <tt>interrupt</tt> method is the only way to
70  condvars.  Their support reduces the need for tricky and/or    re-assert a thread's interruption status (and in the case of
71  inefficient solutions to many classic concurrent problems.  Conditions    self-interruption has no other effect than this).  The check here
72  also address the annoying problem that Object.wait(msecs) does not    previously caused unjustifiable and uncontrollable failures when
73  return an indication of whether the wait timed out. This leads to    restricted code invoked library code that must reassert interruption
74  error-prone code. Since this method is in class Object, the problem is    to correctly propagate status when encountering some
75  basically unfixable.    <tt>InterruptedExceptions</tt>.
76  <p>    <li> The <tt>destroy</tt> method, which has never been implemented,
77  To avoid compatibility problems, the names of Condition methods need    has finally been deprecated. This is just a spec change, reflecting
78  to be different than Object versions. The downside of this is that    the fact that that the reason it has never been implemented is that
79  people can make the mistake of calling cond.notify instead of    it was undesirable and unworkable.
80  cond.signal. However, they will get IllegalMonitorState exceptions if  </ul>
 they do, so they can detect the error if they ever run the code.  
   
   
 <h2>Atomic variables</h2>  
   
 The atomic subpackage includes a small library of classes, including  
 AtomicInteger, AtomicLong, and AtomicReference that support variables  
 performinf compareAndSet (CAS) and related atomic operations.  
81    
82  <h2>Timing</h2>  <h2>Timing</h2>
83    
84  Java has always supported sub-millisecond versions of several native  Method <tt>nanoTime</tt> is added to {@link java.lang.System}. It
85  time-out-based methods (such as Object.wait), but not methods to  provides a high-precision timing facility that is distinct from and
86  actually perform timing in finer-grained units. We address this by  uncoordinated with <tt>System.currentTimeMillis</tt>.
 introducing class TimeUnit, which provides multiple granularities for  
 both accessing time and performing time-out based operations.  
   
87    
88  <h2>Synchronizers</h2>  <h2>Removing ThreadLocals</h2>
89    
90  Five classes aid common special-purpose synchronization idioms.  The {@link java.lang.ThreadLocal} class now supports a means to remove
91  Semaphores and FairSemaphores are classic concurrency tools.  a ThreadLocal, which is needed in some thread-pool and worker-thread
92  CountDownLatches are very simple yet very common objects useful for  designs.
 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: ConcurrentHashMap, CopyOnWriteArrayList,  
 and CopyOnWriteArraySet.  
   
 <h2>Uncaught Exception Handlers</h2>  
93    
 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.)  
94    
 <p> Additionally, ThreadLocals will now support a means to remove a  
 ThreadLocal, which is needed in some thread-pool and worker-thread  
 designs.  
95    
96    <hr>    <hr>
   <address><A HREF="http://gee.cs.oswego.edu/dl">Doug Lea</A></address>  
97   </body>   </body>
98  </html>  </html>

Legend:
Removed from v.1.2  
changed lines
  Added in v.1.19

Doug Lea
ViewVC Help
Powered by ViewVC 1.0.8