[concurrency-interest] ScheduledThreadPoolExecutor threadtimeout

Martin Buchholz martinrb at google.com
Thu Feb 6 13:55:32 EST 2014


In fact, the current implementation ensures that we never have the queue
non-empty and no threads to service the task when its time comes.

A higher-quality implementation might ensure that a new thread is created
(up to core size) not only when a task is submitted to the pool, but also
when the scheduled time arrives.  Which might mean not just keeping at
least one thread around, but keeping one idle "manager" thread around that
spawns new threads to service the ones in the queue.

But the ThreadPoolExecutor code is brittle and we're afraid to touch it.


On Mon, Feb 3, 2014 at 12:13 PM, Dr Heinz M. Kabutz <
heinz at javaspecialists.eu> wrote:

>  Zhong Yu wrote:
>
> On Mon, Feb 3, 2014 at 12:22 PM, Dr Heinz M. Kabutz<heinz at javaspecialists.eu> <heinz at javaspecialists.eu> wrote:
>
>
>  it is almost never a good idea to set corePoolSize to zero or
>
>
> use allowCoreThreadTimeOut because this may leave the pool
> without threads to handle tasks once they become eligible to run.
>
> is the current implementation more robust than that?
>
>
> I think it is in the sense that if there is a task waiting to become
> eligible to run then there is a worker thread that is waiting for that time
> to arrive. But the details are complex and there may be circumstances where
> tasks are not executed as expected.
>
>
> It looks like setting the core size to zero might result in additional
> threads being constructed if we finish all the tasks in the queue and wait a
> little bit.  But as far as I could tell, that's the worst case scenario,
> which is better than leaking threads.  Am I missing anything?
>
>
> import java.util.concurrent.*;
>
> public class ForeverYoung {
>   public static void main(String[] args) throws InterruptedException {
>     ThreadPoolExecutor tpe = new ThreadPoolExecutor(
>         0, Integer.MAX_VALUE, 0, TimeUnit.NANOSECONDS,
>         new LinkedBlockingQueue<>()
>     );
>     tpe.submit(() -> System.out.println("tpe1 by " +
> Thread.currentThread()));
>     tpe.submit(() -> System.out.println("tpe2 by " +
> Thread.currentThread()));
>     tpe.submit(() -> System.out.println("tpe3 by " +
> Thread.currentThread()));
>
>
>     ScheduledThreadPoolExecutor exec =
>         new ScheduledThreadPoolExecutor(0);
>     exec.schedule(() -> {
>       System.out.println("task 1 by " + Thread.currentThread());
>     },
>         ThreadLocalRandom.current().nextInt(5) + 1,
>         TimeUnit.SECONDS
>     );
>     exec.schedule(() -> {
>       System.out.println("task 2 by " + Thread.currentThread());
>     },
>         ThreadLocalRandom.current().nextInt(5) + 1,
>         TimeUnit.SECONDS
>     );
>     exec.schedule(() -> {
>       System.out.println("task 3 by " + Thread.currentThread());
>     },
>         ThreadLocalRandom.current().nextInt(5) + 1,
>         TimeUnit.SECONDS
>     );
>     Thread.sleep(6000);
>     exec.schedule(() -> {
>       System.out.println("task 4 by " + Thread.currentThread());
>     },
>         1,
>         TimeUnit.SECONDS
>     );
>
>   }
> }
>
>
> Output:
>
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build 1.8.0-b126)
> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b67, mixed mode)
>
> tpe1 by Thread[pool-1-thread-1,5,main]
> tpe2 by Thread[pool-1-thread-1,5,main]
> tpe3 by Thread[pool-1-thread-2,5,main]
> task 1 by Thread[pool-2-thread-1,5,main]
> task 3 by Thread[pool-2-thread-1,5,main]
> task 2 by Thread[pool-2-thread-1,5,main]
> task 4 by Thread[pool-2-thread-2,5,main]
>
> As we can see, task 4 is executed by a new thread.  But so what?
>
>
>  I have no problem with that, but I wonder if it is safe to do so,
> i.e., all submitted tasks will be executed even if core threads may
> time out, against the advice of the javadoc.
>
>
>  In my test case, the core thread did time out and the world did not end.
> Another thread was started when a new job was submitted.  But I already got
> into trouble once this week for ignoring a JavaDoc comment, so I won't say
> that this necessarily wil always work ;-)
>
> Heinz
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140206/e835854e/attachment.html>


More information about the Concurrency-interest mailing list