-
Bug
-
Resolution: Fixed
-
P3
-
6
-
b95
-
generic
-
generic
getTaskCount might possibly see a decrease if your timing is
very bad, if called just before a worker runlock is unlocked,
and then again just after. Similarly, a task that has just been
removed from the workQueue but has not yet been started by a worker
will not be counted.
Probably we should just remove the "does not ever decrease".
/**
* Returns the approximate total number of tasks that have ever been
* scheduled for execution. Because the states of tasks and
* threads may change dynamically during computation, the returned
* value is only an approximation, but one that does not ever
* decrease across successive calls.
*
* @return the number of tasks
*/
public long getTaskCount() {
very bad, if called just before a worker runlock is unlocked,
and then again just after. Similarly, a task that has just been
removed from the workQueue but has not yet been started by a worker
will not be counted.
Probably we should just remove the "does not ever decrease".
/**
* Returns the approximate total number of tasks that have ever been
* scheduled for execution. Because the states of tasks and
* threads may change dynamically during computation, the returned
* value is only an approximation, but one that does not ever
* decrease across successive calls.
*
* @return the number of tasks
*/
public long getTaskCount() {