Package jsr166y

Preview versions of classes targeted for Java 7.

See:
Description

Interface Summary

ForkJoinPool.ForkJoinWorkerThreadFactory	Factory for creating new ForkJoinWorkerThreads.
ForkJoinPool.ManagedBlocker	Interface for extending managed parallelism for tasks running in ForkJoinPools.
TransferQueue<E>	A BlockingQueue in which producers may wait for consumers to receive elements.

Class Summary

ConcurrentLinkedDeque<E>	An unbounded concurrent deque based on linked nodes.
CountedCompleter	A resultless ForkJoinTask with a completion action performed when triggered and there are no remaining pending actions.
ForkJoinPool	An ExecutorService for running ForkJoinTasks.
ForkJoinTask<V>	Abstract base class for tasks that run within a ForkJoinPool.
ForkJoinWorkerThread	A thread managed by a ForkJoinPool, which executes ForkJoinTasks.
LinkedTransferQueue<E>	An unbounded TransferQueue based on linked nodes.
Phaser	A reusable synchronization barrier, similar in functionality to CyclicBarrier and CountDownLatch but supporting more flexible usage.
RecursiveAction	A recursive resultless ForkJoinTask.
RecursiveTask<V>	A recursive result-bearing ForkJoinTask.
ThreadLocalRandom	A random number generator isolated to the current thread.

Package jsr166y Description

Preview versions of classes targeted for Java 7. Includes a fine-grained parallel computation framework: ForkJoinTasks and their related support classes provide a very efficient basis for obtaining platform-independent parallel speed-ups of computation-intensive operations. They are not a full substitute for the kinds of arbitrary processing supported by Executors or Threads. However, when applicable, they typically provide significantly greater performance on multiprocessor platforms.

Candidates for fork/join processing mainly include those that can be expressed using parallel divide-and-conquer techniques: To solve a problem, break it in two (or more) parts, and then solve those parts in parallel, continuing on in this way until the problem is too small to be broken up, so is solved directly. The underlying work-stealing framework makes subtasks available to other threads (normally one per CPU), that help complete the tasks. In general, the most efficient ForkJoinTasks are those that directly implement this algorithmic design pattern.