--- jsr166/intro.html 2002/09/29 19:20:58 1.1.1.1 +++ jsr166/intro.html 2003/05/16 14:13:04 1.5 @@ -14,6 +14,17 @@ To join a mailing list discussing this J 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 @@ -22,9 +33,9 @@ tedious or difficult to implement. In t 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:

@@ -66,16 +77,16 @@ although it is at the borders of being i java.util.LinkedList will be adapted to support Queue, and a new non-thread-safe java.util.HeapPriorityQueue will be added. -

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

@@ -84,21 +95,15 @@ Executors provide a simple standardized 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 (so -includes for example, AbstractExecutor that simplifies construction of -new implementations), 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. - -

-A few methods will also be added to the java.util.Timer to support -Futures, and address other requests for enhancement. +

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

@@ -157,25 +162,26 @@ programming, but much less commonly usef 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

+

Synchronizers

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

-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, +and CopyOnWriteArraySet.

Uncaught Exception Handlers

@@ -186,8 +192,8 @@ too inflexible in many multithreaded pro 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 worker-thread designs.