--- jsr166/src/main/intro.html 2003/06/26 10:46:55 1.6 +++ jsr166/src/main/intro.html 2003/08/06 17:40:20 1.11 @@ -1,191 +1,102 @@ - JSR 166 Snapshot Introduction. + JSR 166 Community Review Draft Introduction. -

JSR 166 Snapshot Introduction.


JSR 166 Community Review Draft Introduction.

by Doug Lea

-To join a mailing list discussing this JSR, go to: - http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest . - +To check for updates to this draft, access a preliminary prototype +release of main functionality, or 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 - JCP 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 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. JSR166 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 with -collections. Since the target release is JDK1.5, many APIs use -generics to parameterize on types. Here are brief descriptions of the -main components. - -


- -{@link java.util.concurrent.Executor} is a simple standardized -interface for defining custom thread-like subsystems, including thread -pools, asynch-IO, and lightweight task frameworks. 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. Executors also standardize ways of calling threads that -compute functions returning results, via a {@link -java.util.concurrent.Future}. This is supported in part by defining -interface {@link java.util.concurrent.Callable}, the argument/result -analog of Runnable. - -

{@link java.util.concurrent.ExecutorService} provides a more -complete framework for executing Runnables. An ExecutorService -manages queueing and scheduling of tasks, and allows controlled -shutdown. The two primary implementations of ExecutorService are -{@link java.util.concurrent.ThreadPoolExecutor}, a highly tunable and -flexible thread pool and {@link -java.util.concurrent.ScheduledExecutor}, which adds support for -delayed and periodic task execution. These, and other Executors can -be used in conjunction with a {@link java.util.concurrent.FutureTask} -to asynchronously -start a potentially long-running computation and query the FutureTask -to determine if its execution has completed, or cancel it. - -

The {@link java.util.concurrent.Executors} class provides factory -methods for the most common kinds and styles of Executors, as well as -a few utilities methods for using them. + + Disclaimer. The prototype implementation is experimental +code developed as part of JCP JSR-166 is 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. + +

Disclaimer. This draft specification was produced +using JDK1.4 tools plus some preprocessing. The resulting javadocs do +not yet correctly render other planned JDK1.5 constructs on which +JSR-166 relies, most notably the use of generic types. We are +releasing this version now (before the availability of JDK1.5-based +tools) because, even though they are misformatted and sometimes lack +proper cross-referencing, they otherwise convey the intended +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 some 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 that minimial support for +which it makes sense 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.


A basic (nonblocking) {@link java.util.Queue} interface extending -java.util.Collection is introduced into java.util. Existing class -java.util.LinkedList is adapted to support Queue, and a new -non-thread-safe {@link java.util.PriorityQueue} is added. The -java.util.concurrent {@link -java.util.concurrent.ConcurrentLinkedQueue} class supplies an -efficient sclable thread-safe non-blocking FIFO queue, and {@link -java.util.concurrent.ConcurrentLinkedStack} provides a similar -non-blocking LIFO stack. - -

Five implementations in java.util.concurrent support the extended -{@link java.util.concurrent.BlockingQueue} interface, that defines -blocking versions of put and take: {@link -java.util.concurrent.LinkedBlockingQueue}, {@link -java.util.concurrent.ArrayBlockingQueue}, {@link -java.util.concurrent.SynchronousQueue}, {@link -java.util.concurrent.PriorityBlockingQueue}, and -{@link java.util.concurrent.DelayQueue}. - - -


- -The {@link java.util.concurrent.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 {@link -java.util.concurrent.ReentrantLock} and {@link -java.util.concurrent.FairReentrantLock}. - -

The {@link java.util.concurrent.Locks} class additionally supports -some common trylock-designs using builtin locks. - -

The {@link java.util.concurrent.ReadWriteLock} interface similarly -defines locks that may be shared among readers but are exclusive to -writers. Only a single implementation, {@link -java.util.concurrent.ReentrantReadWriteLock}, is provided, since it -covers all standard usage contexts. But programmers may create their -own implementations to cover nonstandard requirements. - -


- -The {@link java.util.concurrent.Condition} interface describes the -kinds of condition variables associated with monitors in other -concurrent languages, as well as pthreads-style condvars. Their -support reduces the need for tricky and/or inefficient solutions to -many classic concurrent problems. To avoid compatibility problems, -the names of Condition methods are different than Object versions. - -


- -The atomic subpackage includes a small library of classes, including -AtomicInteger, AtomicLong, and AtomicReference that support -compareAndSet (CAS) and related atomic operations. +{@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. + +


+ +Two 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.) Secondly, +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 {@link java.util.concurrent.TimeUnit} class provides multiple -granularities (including nanoseconds) for both accessing time and -performing time-out based operations. - -


- -Five classes aid common special-purpose synchronization idioms. -{@link java.util.concurrent.Semaphore} and {@link -java.util.concurrent.FairSemaphore} are classic concurrency tools. -{@link java.util.concurrent.CountDownLatch} is very simple yet very -common utility for blocking until a single signal, event, or condition -holds. A {@link java.util.concurrent.CyclicBarrier} is a resettable multiway -synchronization point common in some styles of parallel -programming. An {@link java.util.concurrent.Exchanger} allows two -threads to exchange objects at a rendezvous point. - -

Concurrent Collections

- -Besides Queues, this package supplies a few Collection implementations -designed for use in multithreaded contexts: {@link -java.util.concurrent.ConcurrentHashMap}, {@link -java.util.concurrent.CopyOnWriteArrayList}, and {@link -java.util.concurrent.CopyOnWriteArraySet}. - -

The "Concurrent" prefix for classes is a shorthand -indicating several differences from similar "synchronized" -classes. For example java.util.Hashtable and -Collections.synchronizedMap(new HashMap()) are -synchronized. But {@link -java.util.concurrent.ConcurrentHashMap} is "concurrent". -A concurrent collection (among other kinds of classes) is -thread-safe, but not governed by a single exclusion lock. So, in the -particular case of ConcurrentHashMap, it safely permits any number of -concurrent reads as well as a tunable number of concurrent writes. -There may still be a role for "synchronized" classes in some -multithreaded programs -- they can sometimes be useful when you need -to prevent ALL access to a collection via a single lock, at the -expense of much poor scalability. In all other cases, "concurrent" -versions are normally preferable. - -

Most concurrent Collection implementations (including most Queues) -also differ from the usual java.util conventions in that their Iterators -provide weakly consistent rather than fast-fail traversal. A -weakly consistent iterator is thread-safe, but does not necessarily -freeze the collection while iterating, so it may (or may not) reflect -any updates since the iterator was created. - -

Uncaught Exception Handlers

- -The java.lang.Thread class is 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 JSR166 make ThreadGroups even less likely -to be used in most programs. Perhaps they will eventually be -deprecated.) +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


Additionally, java.lang.ThreadLocal now supports a means to remove +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