--- jsr166/src/main/intro.html 2003/05/16 14:13:04 1.1 +++ jsr166/src/main/intro.html 2003/06/24 14:33:52 1.4 @@ -16,7 +16,7 @@

Disclaimer - This prototype is experimental code developed as part of - JSR166 and made available to the developer community for use + 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 @@ -24,177 +24,147 @@ 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: - -

- - -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. +

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. -

-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 +

Executors

+{@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 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.

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. +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.concurrent.java.util.PriorityQueue} +is added. The java.util.concurrent {@link +java.util.concurrent.LinkedQueue} class supplies an efficient +thread-safe non-blocking queue.

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.) - +{@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 DelayQueue}. -

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 +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.

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. - +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. + +

Atomics

+ +The atomic subpackage includes a small library of classes, including +AtomicInteger, AtomicLong, and AtomicReference that support +compareAndSet (CAS) and related atomic operations.

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. - +The {@link java.util.concurrent.TimeUnit} class provides multiple +granularities (including nanoseconds) 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. - +{@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 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

-JSR 166 will supply a few Collection implementations designed for use -in multithreaded contexts: ConcurrentHashTable, CopyOnWriteArrayList, -and CopyOnWriteArraySet. +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}. + +

Most concurrent Collection implementations (including most Queues) +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 will be modified to allow per-thread +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 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. +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.) + +

Additionally, java.lang.ThreadLocal now supports a means to remove +a ThreadLocal, which is needed in some thread-pool and worker-thread +designs.


Doug Lea