--- jsr166/src/main/intro.html 2003/05/16 14:13:04 1.1
+++ jsr166/src/main/intro.html 2004/10/17 11:45:00 1.18
@@ -1,202 +1,95 @@
- JSR 166 Snapshot Introduction.
+ JSR 166 Introduction.
- JSR 166 Snapshot Introduction.
+ JSR 166 Introduction.
by Doug Lea
-To join a mailing list discussing this JSR, go to:
- http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest .
-
-
-
- Disclaimer - This prototype is experimental code developed as part of
- JSR166 and made available to the developer community for use
- as-is. It is not a supported product. Use it at your own risk. The
- specification, language and implementation are subject to change as a
- result of your feedback. Because these features have not yet been
- approved for addition to the Java language, there is no schedule for
- their inclusion in a product.
-
-
-
-Package java.util.concurrent contains utility classes that are
-commonly useful in concurrent programming. Like package java.util, it
-includes a few small standardized extensible frameworks, as well as
-some classes that provide useful functionality and are otherwise
-tedious or difficult to implement. In this JSR, we have been
-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
-uncaught exceptions, and java.util to better integrate queues.
-The API covers:
-
-
- - Queues
-
- Executors
-
- Locks
-
- Condition variables
-
- Atomic variables
-
- Timing
-
- Synchronizers
-
- Concurrent Collections
-
- Uncaught Exception Handlers
-
-
-
-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.
-
-
-Here are brief descriptions and rationales of the main components.
-For details see the javadocs at http://gee.cs.oswego.edu/dl/concurrent/index.html
-
+This is the updated JSR166 specification. For further information, go
+to:
+http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest.
+
+
Note: The javadocs here includes some existing java.util
+Collection interfaces and classes that are not part of the JSR-166
+spec, but are included because JSR-166 methods implement or inherit
+from their specifications.
+
+
JSR-166 introduces package java.util.concurrent
+containing utility classes commonly useful in concurrent
+programming. Like package java.util, it includes a few small
+standardized extensible frameworks, as well as other classes that
+provide useful functionality and are otherwise tedious or difficult to
+implement.
+
+
JSR-166 focusses on breadth, providing critical functionality
+useful across a wide range of concurrent programming styles and
+applications, ranging from low-level atomic operations, to
+customizable locks and synchronization aids, to various concurrent
+data structures, to high-level execution agents including thread
+pools. This diversity reflects the range of contexts in which
+developers of concurrent programs have been found to require or desire
+support not previously available in J2SE, which also keeping the
+resulting package small; providing only functionality that has been
+found to be worthwhile to standardize.
+
+
Descriptions and brief motivations for the main components may be
+found in the associated package documentation. JSR-166 also includes
+a few changes and additions in packages outside of
+java.util.concurrent. Here are brief descriptions.
Queues
-A basic (nonblocking) Queue interface that is compatatible with
-java.util.Collections will be introduced into java.util. Also,
-although it is at the borders of being in scope of JSR-166,
-java.util.LinkedList will be adapted to support Queue, and
-a new non-thread-safe java.util.HeapPriorityQueue will be added.
-
- 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.
-
-
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.)
-
-
-
Executors
-
-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.
-
- 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.
-
-
Locks
-
-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.
-
-
-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.
-
-
-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.
-
-
Conditions
-
-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.
-
-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.
-
-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.
-
-
Atomic variables
-
-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.
-
+A basic (nonblocking) {@link java.util.Queue} interface extending
+{@link java.util.Collection} is introduced into
+java.util. Existing class {@link java.util.LinkedList} is
+adapted to support Queue, and a new non-thread-safe {@link
+java.util.PriorityQueue} is added.
+
+Threads
+
+Three minor changes are introduced to the {@link java.lang.Thread}
+class:
+
+ - It now allows per-thread installation of handlers for uncaught
+ exceptions. Ths optionally disassociates handlers from ThreadGroups,
+ which has proven to be too inflexible. (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.)
+
+
- Access checks are no longer required when a Thread interrupts
+ itself. The interrupt method is the only way to
+ re-assert a thread's interruption status (and in the case of
+ self-interruption has no other effect than this). The check here
+ previously caused unjustifiable and uncontrollable failures when
+ restricted code invoked library code that must reassert interruption
+ to correctly propagate status when encountering some
+ InterruptedExceptions.
+
- The destroy method, which has never been implemented,
+ has finally been deprecated. This is just a spec change, reflecting
+ the fact that that the reason it has never been implemented is that
+ it was undesirable and unworkable.
+
Timing
-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.
-
-
-Synchronizers
-
-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.
-
-
-Concurrent Collections
-
-JSR 166 will supply a few Collection implementations designed for use
-in multithreaded contexts: ConcurrentHashTable, CopyOnWriteArrayList,
-and CopyOnWriteArraySet.
-
-Uncaught Exception Handlers
-
-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.)
-
-Additionally, ThreadLocals will now support a means to
-remove a ThreadLocals, which is needed in some thread-pool and
-worker-thread designs.
+Method nanoTime is added to {@link java.lang.System}. It
+provides a high-precision timing facility that is distinct from and
+uncoordinated with System.currentTimeMillis.
+
+
Removing ThreadLocals
+
+The {@link java.lang.ThreadLocal} class now supports a means to remove
+a ThreadLocal, which is needed in some thread-pool and worker-thread
+designs.
+
+
- Doug Lea