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

Diff of /jsr166/intro.html

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

revision 1.2 by dl, Fri Oct 25 22:55:44 2002 UTC revision 1.4 by dl, Tue Dec 10 11:40:48 2002 UTC
# Line 33  tedious or difficult to implement.  In t Line 33  tedious or difficult to implement.  In t
33  conservative in selecting only those APIs and implementations that are  conservative in selecting only those APIs and implementations that are
34  useful enough to encourage nearly all concurrent programmers to use  useful enough to encourage nearly all concurrent programmers to use
35  routinely.  JSR 166 also includes a few changes and additions in  routinely.  JSR 166 also includes a few changes and additions in
36  packages outside of java.util.concurrent: java.lang, to address timing  packages outside of java.util.concurrent: java.lang, to address
37  and uncaught exceptions, and java.util to better integrate queues, and  uncaught exceptions, and java.util to better integrate queues.
38  to make Timers conform to new frameworks. The API covers:  The API covers:
39    
40    <ul>    <ul>
41      <li> Queues      <li> Queues
# Line 44  to make Timers conform to new frameworks Line 44  to make Timers conform to new frameworks
44      <li> Condition variables      <li> Condition variables
45      <li> Atomic variables      <li> Atomic variables
46      <li> Timing      <li> Timing
47      <li> Barriers      <li> Synchronizers
48      <li> Concurrent Collections      <li> Concurrent Collections
49      <li> Uncaught Exception Handlers      <li> Uncaught Exception Handlers
50    </ul>    </ul>
# Line 77  although it is at the borders of being i Line 77  although it is at the borders of being i
77  java.util.LinkedList will be adapted to support Queue, and  java.util.LinkedList will be adapted to support Queue, and
78  a new non-thread-safe java.util.HeapPriorityQueue will be added.  a new non-thread-safe java.util.HeapPriorityQueue will be added.
79    
80  <p>  <p> Five implementations in java.util.concurrent support the extended
 Four implementations in java.util.concurrent support the extended  
81  BlockingQueue interface, that defines blocking versions of put and  BlockingQueue interface, that defines blocking versions of put and
82  take: LinkedBlockingQueue, ArrayBlockingQueue, SynchronousQueue, and  take: LinkedBlockingQueue, ArrayBlockingQueue, SynchronousQueue,
83  PriorityBlockingQueue. Additionally, java.util.concurrent.LinkedQueue  PriorityBlockingQueue, and DelayQueue. Additionally,
84  supplies an efficient thread-safe non-blocking queue.  java.util.concurrent.LinkedQueue supplies an efficient thread-safe
85  <p>  non-blocking queue.
86  Since the target release is JDK1.5, and generics are slated to be in  
87  1.5, Queues should be parametrized on element type. (Also some others  <p> Since the target release is JDK1.5, and generics are slated to be
88  below.) We are ignoring this for now.  in 1.5, Queues are parametrized on element type. (Also some others
89    below.)
90    
91    
92  <h2>Executors</h2>  <h2>Executors</h2>
# Line 95  Executors provide a simple standardized Line 95  Executors provide a simple standardized
95  thread-like subsystems, including thread pools, asynch-IO, and  thread-like subsystems, including thread pools, asynch-IO, and
96  lightweight task frameworks.  Executors also standardize ways of  lightweight task frameworks.  Executors also standardize ways of
97  calling threads that compute functions returning results, via  calling threads that compute functions returning results, via
98  Futures. This is supported in part by defining java.lang.Callable, the  Futures. This is supported in part by defining interface Callable, the
99  argument/result analog of Runnable.  argument/result analog of Runnable.
100    
101  <p> While the Executor framework is intended to be extensible (so  <p> While the Executor framework is intended to be extensible the most
102  includes for example, AbstractExecutor that simplifies construction of  commonly used Executor will be ThreadExecutor, which can be configured
103  new implementations), the most commonly used Executor will be  to act as all sorts of thread pools, background threads, etc. The
104  ThreadExecutor, which can be configured to act as all sorts of thread  class is designed to be general enough to suffice for the vast
105  pools, background threads, etc. The class is designed to be general  majority of usages, even sophisticated ones, yet also includes methods
106  enough to suffice for the vast majority of usages, even sophisticated  and functionality that simplify routine usage.
 ones, yet also includes methods and functionality that simplify  
 routine usage.  
   
 <p>  
 A few methods will also be added to the java.util.Timer to support  
 Futures, and address other requests for enhancement.  
107    
108  <h2>Locks</h2>  <h2>Locks</h2>
109    
# Line 168  programming, but much less commonly usef Line 162  programming, but much less commonly usef
162  Java has always supported sub-millisecond versions of several native  Java has always supported sub-millisecond versions of several native
163  time-out-based methods (such as Object.wait), but not methods to  time-out-based methods (such as Object.wait), but not methods to
164  actually perform timing in finer-grained units. We address this by  actually perform timing in finer-grained units. We address this by
165  introducing java.lang.Clock, which provides multiple granularities for  introducing class Clock, which provides multiple granularities for
166  both accessing time and performing time-out based operations.  both accessing time and performing time-out based operations.
167    
168    
169  <h2>Barriers</h2>  <h2>Synchronizers</h2>
170    
171  Barriers (multiway synchronization points) are very common in some  Five classes aid common special-purpose synchronization idioms.
172  styles of parallel programming, yet tricky to get right. The two most  Semaphores and FifoSemaphores are classic concurrency tools.  Latches
173  useful flavors (CyclicBarriers and Exchangers) don't have much of an  are very simple yet very common objects useful for blocking until a
174  interface in common, and only have one standard implementation each,  single signal, event, or condition holds.  CyclicBarriers are
175  so these are simply defined as public classes rather than interfaces  resettable multiway synchronization points very common in some styles
176  and implementations.  of parallel programming. Exchangers allow two threads to exchange
177    objects at a rendezvous point.
178    
179    
180  <h2>Concurrent Collections</h2>  <h2>Concurrent Collections</h2>
181    
182  There are no new interfaces, but JSR 166 will supply a few Collection  JSR 166 will supply a few Collection implementations designed for use
183  implementations designed for use in multithreaded contexts:  in multithreaded contexts: ConcurrentHashTable, CopyOnWriteArrayList,
184  ConcurrentHashTable, CopyOnWriteArrayList, and CopyOnWriteArraySet.  and CopyOnWriteArraySet.
185    
186  <h2>Uncaught Exception Handlers</h2>  <h2>Uncaught Exception Handlers</h2>
187    
# Line 197  too inflexible in many multithreaded pro Line 192  too inflexible in many multithreaded pro
192  of features in JSR 166 make ThreadGroups even less likely to  of features in JSR 166 make ThreadGroups even less likely to
193  be used in most programs. Perhaps they will eventually be deprecated.)  be used in most programs. Perhaps they will eventually be deprecated.)
194  <p>  <p>
195  Additionally, Threads and ThreadLocals will now support a means to  Additionally,  ThreadLocals will now support a means to
196  clear and remove ThreadLocals, which is needed in some thread-pool and  remove a ThreadLocals, which is needed in some thread-pool and
197  worker-thread designs.  worker-thread designs.
198    
199    <hr>    <hr>

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

dl@cs.oswego.edu
ViewVC Help
Powered by ViewVC 1.1.27