Public

Performs the given task, returning its result upon completion. If the
computation encounters an unch

invoke

Creates a ForkJoinPool with the given parameters.

<init>

Arranges for (asynchronous) execution of the given task.

execute

Tries to create and start a worker; minimally rolls back counts on failure.

addWorker

If there is a security manager, makes sure caller has permission to modify
threads.

checkPermission

Final callback from terminating worker. Removes record of worker from array, and
adjusts counts. If 

deregisterWorker

Returns the targeted parallelism level of this pool.

getParallelism

Returns the number of worker threads that have started but not yet terminated.
The result returned b

getPoolSize

If inactivating worker w has caused pool to become quiescent, check for pool
termination, and wait f

idleAwaitWork

Returns the approximate (non-atomic) number of idle threads per active thread.

idlePerActive

Returns true if all tasks have completed following shut down.

isTerminated

Blocks in accord with the given blocker. If the current thread is a
ForkJoinWorkerThread, this metho

managedBlock

Callback from ForkJoinWorkerThread constructor to assign a public name

nextWorkerName

Callback from ForkJoinWorkerThread constructor to determine its poolIndex and
record in workers arra

registerWorker

Scans for and, if found, executes one task. Scans start at a random index of
workers array, and rand

scan

signalWork

Possibly initiates and/or completes termination. The caller triggering
termination runs three passes

tryTerminate

Directly increment or decrement active count without queuing. This method is
used to transiently ass

addActiveCount

Increment or decrement quiescerCount. Needed only to prevent triggering shutdown
if a worker is tran

addQuiescerCount

Enqueues the given task in the submissionQueue. Same idea as
ForkJoinWorkerThread.pushTask except fo

addSubmission

ForkJoinPool

Running tasks concurrently on multiple threads

ObjectMapper provides functionality for reading and writing JSON, either to and
from basic POJOs (Pl

com.fasterxml.jackson.databind.ObjectMapper

Allows reading from and writing to a file in a random-access manner. This is
different from the uni-

java.io.RandomAccessFile

 Collection is the root of the collection hierarchy. It defines operations on
data collections and t

java.util.Collection

SortedSet is a Set which iterates over its elements in a sorted order. The order
is determined eithe

java.util.SortedSet

A filter is an object that performs filtering tasks on either the request to a
resource (a servlet o

javax.servlet.Filter

The org.slf4j.Logger interface is the main user entry point of SLF4J API. It is
expected that loggin

org.slf4j.Logger

getSystemService

addToBackStack

startActivity

/**
     * Returns an estimate of how many more locally queued tasks are
     * held by the current worker thread than there are other worker
     * threads that might steal them.  This value may be useful for
     * heuristic decisions about whether to fork other tasks. In many
     * usages of ForkJoinTasks, at steady state, each worker should
     * aim to maintain a small constant surplus (for example, 3) of
     * tasks, and to process computations locally if this threshold is
     * exceeded.
     *
     * <p>This method may be invoked only from within {@code
     * ForkJoinPool} computations (as may be determined using method
     * {@link #inForkJoinPool}).  Attempts to invoke in other contexts
     * result in exceptions or errors, possibly including {@code
     * ClassCastException}.
     *
     * @return the surplus number of tasks, which may be negative
     */

/*
         * The aim of this method is to return a cheap heuristic guide
         * for task partitioning when programmers, frameworks, tools,
         * or languages have little or no idea about task granularity.
         * In essence by offering this method, we ask users only about
         * tradeoffs in overhead vs expected throughput and its
         * variance, rather than how finely to partition tasks.
         *
         * In a steady state strict (tree-structured) computation,
         * each thread makes available for stealing enough tasks for
         * other threads to remain active. Inductively, if all threads
         * play by the same rules, each thread should make available
         * only a constant number of tasks.
         *
         * The minimum useful constant is just 1. But using a value of
         * 1 would require immediate replenishment upon each steal to
         * maintain enough tasks, which is infeasible.  Further,
         * partitionings/granularities of offered tasks should
         * minimize steal rates, which in general means that threads
         * nearer the top of computation tree should generate more
         * than those nearer the bottom. In perfect steady state, each
         * thread is at approximately the same level of computation
         * tree. However, producing extra tasks amortizes the
         * uncertainty of progress and diffusion assumptions.
         *
         * So, users will want to use values larger, but not much
         * larger than 1 to both smooth over transient shortages and
         * hedge against uneven progress; as traded off against the
         * cost of extra task overhead. We leave the user to pick a
         * threshold value to compare with the results of this call to
         * guide decisions, but recommend values such as 3.
         *
         * When all threads are active, it is on average OK to
         * estimate surplus strictly locally. In steady-state, if one
         * thread is maintaining say 2 surplus tasks, then so are
         * others. So we can just use estimated queue length.
         * However, this strategy alone leads to serious mis-estimates
         * in some non-steady-state conditions (ramp-up, ramp-down,
         * other stalls). We can detect many of these by further
         * considering the number of "idle" threads, that are known to
         * have zero queued tasks, so compensate by a factor of
         * (#idle/#active) threads.
         */

/**
     * Implements ForkJoinTask.getSurplusQueuedTaskCount().  Returns
     * an estimate of the number of tasks, offset by a function of
     * number of idle workers.
     *
     * This method provides a cheap heuristic guide for task
     * partitioning when programmers, frameworks, tools, or languages
     * have little or no idea about task granularity.  In essence by
     * offering this method, we ask users only about tradeoffs in
     * overhead vs expected throughput and its variance, rather than
     * how finely to partition tasks.
     *
     * In a steady state strict (tree-structured) computation, each
     * thread makes available for stealing enough tasks for other
     * threads to remain active. Inductively, if all threads play by
     * the same rules, each thread should make available only a
     * constant number of tasks.
     *
     * The minimum useful constant is just 1. But using a value of 1
     * would require immediate replenishment upon each steal to
     * maintain enough tasks, which is infeasible.  Further,
     * partitionings/granularities of offered tasks should minimize
     * steal rates, which in general means that threads nearer the top
     * of computation tree should generate more than those nearer the
     * bottom. In perfect steady state, each thread is at
     * approximately the same level of computation tree. However,
     * producing extra tasks amortizes the uncertainty of progress and
     * diffusion assumptions.
     *
     * So, users will want to use values larger, but not much larger
     * than 1 to both smooth over transient shortages and hedge
     * against uneven progress; as traded off against the cost of
     * extra task overhead. We leave the user to pick a threshold
     * value to compare with the results of this call to guide
     * decisions, but recommend values such as 3.
     *
     * When all threads are active, it is on average OK to estimate
     * surplus strictly locally. In steady-state, if one thread is
     * maintaining say 2 surplus tasks, then so are others. So we can
     * just use estimated queue length (although note that (queueTop -
     * queueBase) can be an overestimate because of stealers lagging
     * increments of queueBase).  However, this strategy alone leads
     * to serious mis-estimates in some non-steady-state conditions
     * (ramp-up, ramp-down, other stalls). We can detect many of these
     * by further considering the number of "idle" threads, that are
     * known to have zero queued tasks, so compensate by a factor of
     * (#idle/#active) threads.
     */

How to use idlePerActivemethodin jsr166y.ForkJoinPool

Best Java code snippets using jsr166y.ForkJoinPool.idlePerActive (Showing top 2 results out of 315)

How to use
idlePerActive
method
in
jsr166y.ForkJoinPool