--- intro.html 2002/12/08 20:28:28 1.3
+++ intro.html 2002/12/10 11:40:48 1.4
@@ -33,9 +33,9 @@
conservative in selecting only those APIs and implementations that are
useful enough to encourage nearly all concurrent programmers to use
routinely. JSR 166 also includes a few changes and additions in
-packages outside of java.util.concurrent: java.lang, to address timing
-and uncaught exceptions, and java.util to better integrate queues, and
-to make Timers conform to new frameworks. The API covers:
+packages outside of java.util.concurrent: java.lang, to address
+uncaught exceptions, and java.util to better integrate queues.
+The API covers:
@@ -77,16 +77,16 @@
java.util.LinkedList will be adapted to support Queue, and
a new non-thread-safe java.util.HeapPriorityQueue will be added.
@@ -44,7 +44,7 @@
- Condition variables
- Atomic variables
- Concurrent Collections
- Uncaught Exception Handlers
-Four implementations in java.util.concurrent support the extended
Five implementations in java.util.concurrent support the extended
BlockingQueue interface, that defines blocking versions of put and
-take: LinkedBlockingQueue, ArrayBlockingQueue, SynchronousQueue, and
-PriorityBlockingQueue. Additionally, java.util.concurrent.LinkedQueue
-supplies an efficient thread-safe non-blocking queue.
-Since the target release is JDK1.5, and generics are slated to be in
-1.5, Queues should be parametrized on element type. (Also some others
-below.) We are ignoring this for now.
+take: LinkedBlockingQueue, ArrayBlockingQueue, SynchronousQueue,
+PriorityBlockingQueue, and DelayQueue. Additionally,
+java.util.concurrent.LinkedQueue supplies an efficient thread-safe
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
@@ -95,7 +95,7 @@
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 java.lang.Callable, the
+Futures. This is supported in part by defining interface Callable, the
argument/result analog of Runnable.
While the Executor framework is intended to be extensible the most
@@ -105,10 +105,6 @@
majority of usages, even sophisticated ones, yet also includes methods
and functionality that simplify routine usage.
-A few methods will also be added to the java.util.Timer to support
-Futures, and address other requests for enhancement.
The Lock interface supports locking disciplines that differ in
@@ -166,25 +162,26 @@
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 java.lang.Clock, which provides multiple granularities for
+introducing class Clock, which provides multiple granularities for
both accessing time and performing time-out based operations.
-Barriers (multiway synchronization points) are very common in some
-styles of parallel programming, yet tricky to get right. The two most
-useful flavors (CyclicBarriers and Exchangers) don't have much of an
-interface in common, and only have one standard implementation each,
-so these are simply defined as public classes rather than interfaces
+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.
-There are no new interfaces, but JSR 166 will supply a few Collection
-implementations designed for use in multithreaded contexts:
-ConcurrentHashTable, CopyOnWriteArrayList, and CopyOnWriteArraySet.
+JSR 166 will supply a few Collection implementations designed for use
+in multithreaded contexts: ConcurrentHashTable, CopyOnWriteArrayList,
Uncaught Exception Handlers
@@ -195,8 +192,8 @@
of features in JSR 166 make ThreadGroups even less likely to
be used in most programs. Perhaps they will eventually be deprecated.)
-Additionally, Threads and ThreadLocals will now support a means to
-clear and remove ThreadLocals, which is needed in some thread-pool and
+Additionally, ThreadLocals will now support a means to
+remove a ThreadLocals, which is needed in some thread-pool and