ViewVC Help
View File | Revision Log | Show Annotations | Download File | Root Listing
root/jsr166/jsr166/intro.html
(Generate patch)

Comparing jsr166/intro.html (file contents):
Revision 1.3 by dl, Sun Dec 8 20:28:28 2002 UTC vs.
Revision 1.4 by dl, Tue Dec 10 11:40:48 2002 UTC

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

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines